-
Notifications
You must be signed in to change notification settings - Fork 8.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Updates for release v2.0.1 including release notes and version reference updates. Signed-off-by: David Enyeart <enyeart@us.ibm.com>
- Loading branch information
Showing
7 changed files
with
139 additions
and
9 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,97 @@ | ||
| v2.0.1 Release Notes - February 26, 2020 | ||
| ======================================== | ||
|
|
||
| Fixes | ||
| ----- | ||
|
|
||
| **FAB-17458: Rolling upgrade: Different endorsement results on v1.4.x and v2.0.0 peers** | ||
|
|
||
| In a rolling upgrade scenario where V2_0 channel application capability is not yet set, | ||
| and proposals are sent to v1.4.x peers and v2.0.0 peers, | ||
| the endorsed read sets did not exactly match in the proposal response between | ||
| the v1.4.x peers and v2.0.0 peers. A client would therefore have to get | ||
| endorsements from only v1.4.x peers, or only from v2.0.0 peers, making it difficult | ||
| to get sufficient number of matching endorsements to meet the endorsement policy. | ||
| If a transaction is submitted with insufficient matching endorsements, the | ||
| transaction will be invalidated at commit time with error message | ||
| "marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]". | ||
| The proposal response is fixed in v2.0.1 so that the read sets will exactly | ||
| match read sets on v1.4.x peers, enabling transactions to be endorsed across | ||
| peers of different versions. | ||
|
|
||
| **FAB-17479: Migrated Kafka cluster can be safely expanded later** | ||
|
|
||
| When a new ordering service node was added to a migrated Kafka cluster, | ||
| but was not added to all channels, the ordering service node would crash. | ||
| The fix ensures that new ordering nodes can be added to a subset of channels. | ||
|
|
||
| **FAB-17453: 'peer lifecycle chaincode package' required an MSP configured** | ||
|
|
||
| 'peer lifecycle chaincode package' is for local packaging of chaincode only, | ||
| and therefore no longer requires a MSP to be configured. | ||
|
|
||
| **FAB-17059: Change collection membership eligibility checks to only compare mspID** | ||
|
|
||
| When a new CA root cert was added to an organization in the channel configuration, | ||
| new peers with an identity from the new CA would not receive private data for | ||
| blocks prior to the channel configuration change. This is because the peer didn't | ||
| realize it was a member of the private data collection, even though it was | ||
| based on the collection's mspid. The fix ensures that the peer evaluates | ||
| private data collection membership based on its mspid. The fix is important | ||
| when rotating CA root or intermediate certs, for example in a side-by-side | ||
| migration scenario that uses new CA certs and new peers. | ||
|
|
||
| **FAB-17519: Improve Discovery endorsement policy performance** | ||
|
|
||
| Fix peer CPU spikes during evaluation of endorsement policy | ||
| combinations, due to expensive reflection. | ||
|
|
||
| **FAB-17523: Endorsing peer was not honoring private data RequiredPeerCount** | ||
|
|
||
| If there were not enough known eligible peers to meet the private data collection RequiredPeerCount | ||
| dissemination requirement, endorsement was succeeding rather than returning an error. | ||
|
|
||
| **[FAB-17491] Do not disseminate private data for other organization's implicit collection** | ||
|
|
||
| When using the new implicit private data collections in v2.0.0, in some use cases | ||
| private data needs to be written to each of multiple organization's implicit | ||
| private data collections in the same transaction. In these cases the endorsing peers were | ||
| disseminating the private data to each of the respective organization's peers. | ||
| Although not a security problem (each organization is authorized to receive its | ||
| own implicit collection private data), dissemination should be managed by the endorsing | ||
| peers of the implicit collection organization only. This fix ensures that only peers | ||
| of the implicit collection organization disseminate the private data to their own | ||
| organization's other peers. | ||
|
|
||
| **[FAB-17515] Support configuring BlockValidation policy for orderer group** | ||
|
|
||
| Prior to the fix, a configured BlockValidation policy (e.g. defined in configtx.yaml) | ||
| would be ignored. The policy is now applied in the channel creation transaction, and | ||
| must be specified. | ||
|
|
||
|
|
||
| Known Issues and Workarounds | ||
| ---------------------------- | ||
| **FAB-12134: Same chaincode source receiving fingerprint mismatch error** | ||
|
|
||
| When using the legacy chaincode lifecycle, chaincode installed in different | ||
| ways may result in "chaincode fingerprint mismatch data mismatch" error | ||
| upon instantiation. This may happen when installing chaincode by using | ||
| different SDKs. To workaround the problem, package the chaincode prior to | ||
| installation and instantiation, by using the "peer chaincode package" command. | ||
|
|
||
|
|
||
| Known Vulnerabilities | ||
| --------------------- | ||
| **FAB-8664: Peer should detect and react when its org has been removed** | ||
|
|
||
| This is a relatively low severity problem, because it requires a significant | ||
| conspiracy of network admins, but it will be addressed in a future release. | ||
|
|
||
|
|
||
| Resolved Vulnerabilities | ||
| ------------------------ | ||
| None. | ||
|
|
||
| For the full list of changes, refer to the release change log: | ||
| https://github.com/hyperledger/fabric/blob/release-2.0/CHANGELOG.md#v201 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters