|
| 1 | +v1.4.4 Release Notes - November 14, 2019 |
| 2 | +======================================== |
| 3 | + |
| 4 | +What's New in Hyperledger Fabric v1.4.4 |
| 5 | +--------------------------------------- |
| 6 | + |
| 7 | +The following enhancements are included in this release: |
| 8 | + |
| 9 | +- **FAB-16715, FAB-16544: Orderer endpoint override** |
| 10 | + |
| 11 | + Ordering networks whose addresses or TLS root certificates change will cause problems for new |
| 12 | + peers joining channels because the channel genesis block will contain the outdated orderer |
| 13 | + information. A new configuration option for orderer endpoint overrides allows administrators |
| 14 | + to configure peers to translate old orderer addresses and certificates to the updated |
| 15 | + orderer addresses and certificate pools. |
| 16 | + |
| 17 | +- **FAB-17000: Provide notification to users if certs are about to expire** |
| 18 | + |
| 19 | + Peers and orderers now log a warning to the log a week before the enrollment certificate or |
| 20 | + TLS certificate expire. Example log entries: |
| 21 | + |
| 22 | + `[certmonitor] trackCertExpiration -> WARN 011 The server TLS certificate expires within one week` |
| 23 | + |
| 24 | + `[certmonitor] trackCertExpiration -> WARN 011 The enrollment certificate expires within 2 days and 5 hours` |
| 25 | + |
| 26 | +- **FAB-15814: Add operations endpoint to expose peer/orderer version** |
| 27 | + |
| 28 | + Adds a /version endpoint to the operations server that serves peer/orderer metadata |
| 29 | + including Version number and CommitSHA. |
| 30 | + |
| 31 | +- **FAB-16852** Bump to Go v1.12.12 and baseimage 0.4.18 |
| 32 | + |
| 33 | +- **FABB-128** Bump node.js to 8.16.1 and npm to 6.11.3 in 0.4.18 baseimage |
| 34 | + |
| 35 | +Fixes |
| 36 | +----- |
| 37 | + |
| 38 | +- **FAB-13552: Re-addition of a removed OSN in a channel** - Prior to the fix, if a Raft orderer was |
| 39 | + removed from the consenter set in the channel configuration, it would not check to see if was added |
| 40 | + back and a reboot was required. |
| 41 | + |
| 42 | +- **FAB-15026: Segmentation violation in peer chaincode install** - Prior to the fix, the tar processing |
| 43 | + during chaincode package install could trigger a panic while looking up user info when run with |
| 44 | + certain versions of libc. The calls to libc are no longer made. |
| 45 | + |
| 46 | +- **FAB-15389: Endorsing peer is not honoring maxPeerCount for private data dissemination** - Prior |
| 47 | + to the fix, there was a chance that peers chosen for private data dissemination at endorsement time |
| 48 | + could potentially be counted twice towards maxPeerCount, leading to disseminating private data to |
| 49 | + fewer peers than expected. |
| 50 | + |
| 51 | +- **FAB-15666: NetworkMode does not get passed to chaincode image build** |
| 52 | + Prior to the fix, the peer's configured docker NetworkMode was not getting passed |
| 53 | + upon chaincode image build. |
| 54 | + |
| 55 | +- **FAB-16571: Fix panic in peer chaincode package command** - Prior to the fix, the peer |
| 56 | + chaincode package command could panic when traversing the chaincode location. |
| 57 | + |
| 58 | +- **FAB-16610: Commit block to ledger hang when chaincode crash** - Prior to the fix, if a chaincode |
| 59 | + terminated abnormally during an invocation, a lock would prevent blocks from committing until the |
| 60 | + execution timeout (core.chaincode.executetimeout property) was triggered. The fix ensures that the |
| 61 | + lock is released immediately on exit. |
| 62 | + |
| 63 | +- **FAB-16643: Nil pointer during reconciliation of deleted private data** - Prior to the fix, |
| 64 | + if a peer is trying to reconcile missing private data, and the private data key has since been |
| 65 | + deleted, the peer will panic with a nil pointer exception. |
| 66 | + |
| 67 | +- **FAB-16651: Fix connection leak if certificates renewed** - Prior to the fix, peers that have changed |
| 68 | + their enrollment certificate without changing their endpoint caused connections to leak over time. |
| 69 | + |
| 70 | +- **FAB-16695: Separate listeners causes panic** - Prior to the fix, configuring separate |
| 71 | + listeners for the peer admin service or for the orderer cluster service would cause a |
| 72 | + panic on startup if Prometheus metrics were enabled. |
| 73 | + |
| 74 | +- **FAB-16948: Nil pointer exception in CID GetID() when using Idemix** - GetID now returns an error |
| 75 | + when invoked on a chaincode request from an Idemix identity. |
| 76 | + |
| 77 | + |
| 78 | +Changes, Known Issues, and Workarounds |
| 79 | +-------------------------------------- |
| 80 | + |
| 81 | +- **FAB-12134: Same chaincode source receiving fingerprint mismatch error** - |
| 82 | + Chaincode installed in different ways may result in "chaincode fingerprint |
| 83 | + mismatch data mismatch" error upon instantiation. This may happen when |
| 84 | + installing chaincode by using different SDKs. To workaround the problem, |
| 85 | + package the chaincode prior to installation and instantiation, by using |
| 86 | + the "peer chaincode package" command. |
| 87 | + |
| 88 | + |
| 89 | +Known Vulnerabilities |
| 90 | +--------------------- |
| 91 | + |
| 92 | +- **FAB-8664: Peer should detect and react when its org has been removed** |
| 93 | + This is a relatively low severity problem, because it requires a significant |
| 94 | + conspiracy of network admins, but it will be addressed in a future release. |
| 95 | + |
| 96 | + |
| 97 | +Resolved Vulnerabilities |
| 98 | +------------------------ |
| 99 | +None. |
| 100 | + |
| 101 | + |
| 102 | +Deprecations |
| 103 | +------------ |
| 104 | +The following functions are deprecated and are targeted for removal in a future release. |
| 105 | + |
| 106 | +- Support for automatically vendoring the chaincode shim into user chaincodes. |
| 107 | + The fabric-ccenv image which is used to build chaincode, currently includes |
| 108 | + the github.com/hyperledger/fabric/core/chaincode/shim ("shim") package. |
| 109 | + This is convenient, as it provides the ability to package chaincode |
| 110 | + without the need to include the "shim". However, this may cause issues in future |
| 111 | + releases (and/or when trying to use packages which are included by the "shim"). |
| 112 | + In order to avoid any issues, users are advised to manually vendor the "shim" |
| 113 | + package with their chaincode prior to using the peer CLI for packaging and/or |
| 114 | + for installing chaincode. |
| 115 | + For more details see FAB-5177. |
| 116 | + |
| 117 | +- Support for CAR chaincode package format |
| 118 | + Support for packaging chaincode using the CAR format will be removed in |
| 119 | + a future release. |
| 120 | + For more details see FAB-14720. |
| 121 | + |
| 122 | +- Support for specifying orderer endpoints at the global level in channel configuration. |
| 123 | + Utilize the new 'OrdererEndpoints' stanza within the channel configuration of |
| 124 | + an organization instead. |
| 125 | + For more details see FAB-7559. |
| 126 | + |
| 127 | +- Support for invoking system chaincodes from user chaincodes. |
| 128 | + System chaincodes, for example QSCC, are intended to be invoked by |
| 129 | + a client rather than by a user chaincode. Invoking from a user chaincode |
| 130 | + may cause deadlocks. |
| 131 | + For more details see FAB-15285. |
| 132 | + |
| 133 | +- Support for user chaincodes to utilize the chaincode shim's logger via NewLogger(). |
| 134 | + Chaincodes that used the shim's NewLogger() will need to shift to their own preferred |
| 135 | + logging mechanism. |
| 136 | + For more details see FAB-15366. |
| 137 | + |
| 138 | +- Support for peer's Admin service. |
| 139 | + The peer's Admin service exposes APIs such as GetLogSpec() and SetLogSpec(). |
| 140 | + Instead of using these services, utilize the HTTP operations service that was |
| 141 | + introduced in v1.4.0. |
| 142 | + For more details see FAB-15390. |
| 143 | + |
| 144 | +- Support for Solo ordering service. |
| 145 | + With the introduction of Raft-based ordering service in v1.4.1, it is possible |
| 146 | + to deploy a single-node (non-production) or multi-node |
| 147 | + Raft-based ordering service with no external dependencies. |
| 148 | + For single-node (non-production) ordering services, utilize Raft-based ordering |
| 149 | + service with a single node instead of Solo ordering service. |
| 150 | + For more details see FAB-15754. |
| 151 | + |
| 152 | + |
| 153 | +Change log |
| 154 | +---------- |
| 155 | +For the full list of changes, refer to the release change log: |
| 156 | +https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v144 |
0 commit comments