v0.10.0
Pre-release
Big changes around security this week, full support for Hyperledger Fabric configurations with multiple organisations, and the ability to drive queries from the Composer REST server ✨
We have introduced system level access control so that you can control who in your business network is allowed to perform "system" level tasks such as accessing registries, creating new registries, and managing identities within a business network! 🔒
We have also reworked the management of identities within a business network so that public key signatures are used for authentication rather than certificate common names, all identity operations are recorded in the transaction registry, and you can now bind existing identities to a participant. 🛂
We have started work on splitting the deployment of a business network into two commands, to better fit with the "install and instantiate" work that went into Hyperledger Fabric v1.0. Use composer runtime install to install the Composer runtime (Fabric install), and use composer network start to start a business network (Fabric instantiate). 💻
Finally, the Composer REST server now automatically creates REST APIs for all of the queries defined in a Composer query file. Each query has a GET method, and any parameters (_$paramName) can be specified using the query string. ❓
Breaking changes
v0.11.0). Information regarding this can be found in issue #1535
System level access control #722 adds access control enforcement to all data within a deployed business network, including registries and identity management. Access control rules must be defined for the new system types have been added into the org.hyperledger.composer.system namespace. In order to restore the "old behaviour", you can grant all access to everybody on these types:
rule SystemACL {
description: "System ACL to permit all access"
participant: "org.hyperledger.composer.system.Participant"
operation: ALL
resource: "org.hyperledger.composer.system.**"
action: ALLOW
}
However we strongly recommend that you define proper access control rules around the system types 😉
The composer identity revoke command now takes a unique identity identifier rather than the enrolment ID due to the changes in #1291.
Known issues
The LIMIT and SKIP clauses with parameters (LIMIT _$inputLimit or SKIP _$inputSkip) do not work in queries when using Hyperledger Fabric v1.0 due to a bug in Hyperledger Fabric that is being tracked in FAB-5369. The bug is not present in the embedded or web runtimes, and LIMIT and SKIP clauses with hardcoded values (LIMIT 5 or SKIP 10) work correctly.
The documentation for #1290 is not in place yet; you can bind identities using the composer identity bind command. The certificate provided must be in PEM format and must contain the lines ----BEGIN CERTIFICATE---- and ----END CERTIFICATE----.
Invalid SELECT expressions in Composer query files are not detected when editing Composer query filesi n the Composer Playground or VSCode, or when packaging Composer query files into a business network archive (BNA) file. Errors will only be reported when the business network archive is deployed.
Features
As a business network developer, I can enforce system level access control #722
As a user, identities are mapped to participants using public key signatures #1291
As a user, I can bind an existing identity to a participant #1290
As a user, I can view, issue, and revoke identities for participants in a business network #817
Rest server CLI should have a -v --version option #1576
As a network manager, I can install the Composer runtime on my Blockchain nodes #1292
As a network starter, I can start a business network in a consortium #1293
As a user, I want to perform complex queries when using the REST APIs #921
Bug fixes
Ensure Composer module version is consistent for releases #1559
prereqs-ubuntu.sh has been deleted, docs still refer to it #1587
Fix incorrectly compiled queries with dynamic limit/skip clauses #1597
Shoutouts to new contributors!
None this week!