|
1 | | -v2.3.2 <RELEASE DATE TBD> |
2 | | -========================= |
| 1 | +v2.3.2 Release Notes - April 23, 2021 |
| 2 | +===================================== |
| 3 | + |
| 4 | +Improvements |
| 5 | +------------ |
| 6 | + |
| 7 | +**peer and orderer - Implement legacy name constraints verification for Go 1.15** |
| 8 | + |
| 9 | +These changes reproduce the Go 1.14 name constraint verification in the MSP. |
| 10 | +Without these changes, certificate chains that would fail verification in Go 1.14 would |
| 11 | +successfully validate in Go 1.15 due to the change mentioned in the [Go 1.15 release notes](https://golang.org/doc/go1.15#commonname). |
| 12 | +Specifically, if a signing certificate contains a name constraint, the leaf certificate |
| 13 | +does not include SAN extensions, and the leaf's common name looks like a host name, |
| 14 | +then the additional verification is performed to ensure deterministic behavior relative |
| 15 | +to prior Fabric releases. |
| 16 | + |
3 | 17 |
|
4 | 18 | Fixes |
5 | 19 | ----- |
6 | 20 |
|
| 21 | +**FAB-18427: orderer - Report correct reason of stream abort in orderer cluster** |
| 22 | + |
| 23 | +This commit fixes a bug that makes the cluster communication infrastructure |
| 24 | +always report an "aborted" reason after a stream terminates. |
| 25 | + |
7 | 26 | **FAB-18424: peer - Ledger snapshot request submission with special value "blockNumber 0"** |
8 | 27 |
|
9 | | -If a ledger snapshot request is submitted with the special value "blockNumber 0", |
10 | | -peer is expected to translate the request to last committed block. This patch fixes |
11 | | -an issue where the request may be translated to block number 1 instead of last committed block. |
| 28 | +If a ledger snapshot request is submitted with the special value "blockNumber 0", peer is expected to translate the request to last committed block. |
| 29 | +This patch fixes the issue where, it may happen sometimes that the request is translated to block number 1 instead of last committed block. |
12 | 30 | This leads to the situation where no snapshot gets generated, including any future snapshot requests. |
13 | | -If you have used this special value on a snapshot request to a peer, check the list of pending snapshots |
14 | | -requests by using "peer snapshot listpending" command. If you notice one or more pending |
15 | | -requests that are for the the block numbers lower than the latest committed block, |
16 | | -cancel such requests with "peer snapshot cancelrequest" command to enable subsequent snapshot |
17 | | -requests to be processed. |
| 31 | +If you have ever used this special value, we encourage you to check the list of pending snapshots requests with `peer snapshot listpending`. |
| 32 | +If you notice one or more pending requests that are for the the block numbers lower than the latest committed block, cancel such requests with `peer snapshot cancelrequest` to enable the further snapshot requests to be processed. |
| 33 | + |
| 34 | +**FAB-18304: peer and orderer - Fix leveldb manifest corruption** |
18 | 35 |
|
19 | | -<ADD OTHER FIX NOTES HERE UP UNTIL RELEASE DATE> |
| 36 | +This fix updates the version of goleveldb. The prior version of goleveldb had a bug which |
| 37 | +could cause manifest corruption in crash scenarios, especially in disk full crash scenarios. |
| 38 | +With a corrupted goleveldb database, the peer or orderer would fail to start with error |
| 39 | +"panic: Error opening leveldb: leveldb: manifest corrupted". |
20 | 40 |
|
21 | 41 |
|
22 | 42 | Dependencies |
|
0 commit comments