|
| 1 | +v2.0.1 Release Notes - February 26, 2020 |
| 2 | +======================================== |
| 3 | + |
| 4 | +Fixes |
| 5 | +----- |
| 6 | + |
| 7 | +**FAB-17458: Rolling upgrade: Different endorsement results on v1.4.x and v2.0.0 peers** |
| 8 | + |
| 9 | +In a rolling upgrade scenario where V2_0 channel application capability is not yet set, |
| 10 | +and proposals are sent to v1.4.x peers and v2.0.0 peers, |
| 11 | +the endorsed read sets did not exactly match in the proposal response between |
| 12 | +the v1.4.x peers and v2.0.0 peers. A client would therefore have to get |
| 13 | +endorsements from only v1.4.x peers, or only from v2.0.0 peers, making it difficult |
| 14 | +to get sufficient number of matching endorsements to meet the endorsement policy. |
| 15 | +If a transaction is submitted with insufficient matching endorsements, the |
| 16 | +transaction will be invalidated at commit time with error message |
| 17 | +"marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]". |
| 18 | +The proposal response is fixed in v2.0.1 so that the read sets will exactly |
| 19 | +match read sets on v1.4.x peers, enabling transactions to be endorsed across |
| 20 | +peers of different versions. |
| 21 | + |
| 22 | +**FAB-17479: Migrated Kafka cluster can be safely expanded later** |
| 23 | + |
| 24 | +When a new ordering service node was added to a migrated Kafka cluster, |
| 25 | +but was not added to all channels, the ordering service node would crash. |
| 26 | +The fix ensures that new ordering nodes can be added to a subset of channels. |
| 27 | + |
| 28 | +**FAB-17453: 'peer lifecycle chaincode package' required an MSP configured** |
| 29 | + |
| 30 | +'peer lifecycle chaincode package' is for local packaging of chaincode only, |
| 31 | +and therefore no longer requires a MSP to be configured. |
| 32 | + |
| 33 | +**FAB-17059: Change collection membership eligibility checks to only compare mspID** |
| 34 | + |
| 35 | +When a new CA root cert was added to an organization in the channel configuration, |
| 36 | +new peers with an identity from the new CA would not receive private data for |
| 37 | +blocks prior to the channel configuration change. This is because the peer didn't |
| 38 | +realize it was a member of the private data collection, even though it was |
| 39 | +based on the collection's mspid. The fix ensures that the peer evaluates |
| 40 | +private data collection membership based on its mspid. The fix is important |
| 41 | +when rotating CA root or intermediate certs, for example in a side-by-side |
| 42 | +migration scenario that uses new CA certs and new peers. |
| 43 | + |
| 44 | +**FAB-17519: Improve Discovery endorsement policy performance** |
| 45 | + |
| 46 | +Fix peer CPU spikes during evaluation of endorsement policy |
| 47 | +combinations, due to expensive reflection. |
| 48 | + |
| 49 | +**FAB-17523: Endorsing peer was not honoring private data RequiredPeerCount** |
| 50 | + |
| 51 | +If there were not enough known eligible peers to meet the private data collection RequiredPeerCount |
| 52 | +dissemination requirement, endorsement was succeeding rather than returning an error. |
| 53 | + |
| 54 | +**[FAB-17491] Do not disseminate private data for other organization's implicit collection** |
| 55 | + |
| 56 | +When using the new implicit private data collections in v2.0.0, in some use cases |
| 57 | +private data needs to be written to each of multiple organization's implicit |
| 58 | +private data collections in the same transaction. In these cases the endorsing peers were |
| 59 | +disseminating the private data to each of the respective organization's peers. |
| 60 | +Although not a security problem (each organization is authorized to receive its |
| 61 | +own implicit collection private data), dissemination should be managed by the endorsing |
| 62 | +peers of the implicit collection organization only. This fix ensures that only peers |
| 63 | +of the implicit collection organization disseminate the private data to their own |
| 64 | +organization's other peers. |
| 65 | + |
| 66 | +**[FAB-17515] Support configuring BlockValidation policy for orderer group** |
| 67 | + |
| 68 | +Prior to the fix, a configured BlockValidation policy (e.g. defined in configtx.yaml) |
| 69 | +would be ignored. The policy is now applied in the channel creation transaction, and |
| 70 | +must be specified. |
| 71 | + |
| 72 | + |
| 73 | +Known Issues and Workarounds |
| 74 | +---------------------------- |
| 75 | +**FAB-12134: Same chaincode source receiving fingerprint mismatch error** |
| 76 | + |
| 77 | +When using the legacy chaincode lifecycle, chaincode installed in different |
| 78 | +ways may result in "chaincode fingerprint mismatch data mismatch" error |
| 79 | +upon instantiation. This may happen when installing chaincode by using |
| 80 | +different SDKs. To workaround the problem, package the chaincode prior to |
| 81 | +installation and instantiation, by using the "peer chaincode package" command. |
| 82 | + |
| 83 | + |
| 84 | +Known Vulnerabilities |
| 85 | +--------------------- |
| 86 | +**FAB-8664: Peer should detect and react when its org has been removed** |
| 87 | + |
| 88 | +This is a relatively low severity problem, because it requires a significant |
| 89 | +conspiracy of network admins, but it will be addressed in a future release. |
| 90 | + |
| 91 | + |
| 92 | +Resolved Vulnerabilities |
| 93 | +------------------------ |
| 94 | +None. |
| 95 | + |
| 96 | +For the full list of changes, refer to the release change log: |
| 97 | +https://github.com/hyperledger/fabric/blob/release-2.0/CHANGELOG.md#v201 |
0 commit comments