v1.4.9

v1.4.9 Release Notes - September 30, 2020

What's New in Hyperledger Fabric v1.4.9

Hyperledger Fabric v1.4.9 provides important improvements and fixes, with a focus on the following areas:

• Management of certificate expirations
• Hardware security module (HSM) efficiency

Fixes

FAB-18163: orderer certificate expiration - TLSHandshakeTimeShift without separate cluster port

If the TLS certificates of the ordering service nodes expire and are not replaced in time,
communication between them cannot be established, making it impossible to send
new transactions to the ordering service. To recover from such a scenario, it is possible
to configure a backwards timeshift that ordering service nodes will utilize for TLS
handshakes so that transactions can be processed.
If the Raft cluster service is sharing the orderer’s main gRPC server port,
configure the new orderer.yaml General.TLS.TLSHandshakeTimeShift property.
If using a separate cluster listener port,
configure the orderer.yaml General.Cluster.TLSHandshakeTimeShift property.

FAB-18205: orderer certificate expiration - Permit peer CLI to communicate with orderers with expired TLS certificates

The change allows peer CLI to communicate with ordering service nodes with expired TLS certificates
by setting the --tlsHandshakeTimeShift flag to a desired backwards timeshift.
The change applies to the peer channel fetch and peer channel update commands to allow
fetching configuration blocks and updating the channel configuration for orderers with expired TLS certificates.

FAB-18171: orderer certificate expiration - Disregard certificate validity period in intra-orderer communication

This change makes the orderer cluster authentication infrastructure
disregard validity periods when comparing certificates, and only regard public keys.
With this change, an expiring Raft TLS certificate can be replaced
with a new certificate that has the same public key, without requiring channel configuration updates.

FAB-18188: peer and orderer certificate expiration - Log expiration date upon startup

The enrollment, TLS server, and TLS client certificate expiration dates are now logged upon peer and orderer startup.

peer and orderer PKCS#11 - Add object handle cache

With this change, object handles are cached in the PKCS#11 implementation.
In support of this change, in addition to pooling idle sessions, the
provider tracks active sessions. If some condition occurs that results
in all sessions being closed, cached object handles are no longer valid
so the handle cache is purged.

FAB-18208: peer - Do not sign gossip message if membership is empty

This change suppresses the signing of gossip messages if the message will not get
sent regardless due to an empty gossip membership. The change reduces CPU consumption
and eliminates unnecessary calls to an HSM.

FAB-18250: peer and orderer PKCS#11 - Introduce error checking for evicting invalid PKCS#11 sessions

FAB-17722 introduced a call to the pkcs11 GetSessionInfo function for retrieving the current state of
the PKCS11 session. The result of this function was used to determine whether a session was still
valid to perform HSM operations or if it should be evicted from the session pool. Performance tests
showed that the call to GetSessionInfo was computationally prohibitively expensive. FAB-18242 reverted
this change and FAB-18250 introduced a new method for determining if the PKCS11 session is invalid.
Now when an HSM operation fails, we check the resultant error against the known session error codes and
evict the session from the pool if the error was the result of an invalid session.

FAB-17539: peer - Always remember gossip anchor peers in membership

Gossip removes a peer from its membership cache if no new heartbeats are received from the peer within a timely manner.
If a network partition persists for too long, peers of different organizations never re-establish communication because all membership is purged.
With the fix, anchor peers are no longer removed from the membership cache even if they are offline.
Therefore, after the network partition is healed, peers among different organizations can reestablish communication as long as anchor peers are reachable.

peer - Verify user chaincodes are called with a channel context

While system chaincodes can be called without a channel context, user
chaincodes always require a channel context. This fix ensures that
a channel context is available for calls to user chaincodes, and
returns an error if the client did not pass a channel name.

Dependencies

Fabric v1.4.9 has been tested with the following dependencies:

• Go 1.13.12
• Fabric baseimage 0.4.21
• CouchDB v2.3.1

Changes, Known Issues, and Workarounds

FAB-12134: Same chaincode source receiving fingerprint mismatch error -
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.

Deprecations (existing)

The following functions are deprecated and are targeted for removal in a future release.

Support for automatically vendoring the chaincode shim into user chaincodes

The fabric-ccenv image which is used to build chaincode, currently includes
the github.com/hyperledger/fabric/core/chaincode/shim ("shim") package.
This is convenient, as it provides the ability to package chaincode
without the need to include the "shim". However, this may cause issues in future
releases (and/or when trying to use packages which are included by the "shim").
In order to avoid any issues, users are advised to manually vendor the "shim"
package with their chaincode prior to using the peer CLI for packaging and/or
for installing chaincode.
Support removed in v2.0. For more details see FAB-5177.

Support for CAR chaincode package format

Support for packaging chaincode using the CAR format will be removed in
a future release.
Support removed in v2.0. For more details see FAB-14720.

Support for invoking system chaincodes from user chaincodes.

System chaincodes, for example QSCC, are intended to be invoked by
a client rather than by a user chaincode. Invoking from a user chaincode
may cause deadlocks.
Support removed in v2.0. For more details see FAB-15285.

Support for user chaincodes to utilize the chaincode shim's logger via NewLogger()

Chaincodes that used the shim's NewLogger() will need to shift to their own preferred
logging mechanism.
Support removed in v2.0. For more details see FAB-15366.

Support for peer's Admin service

The peer's Admin service exposes APIs such as GetLogSpec() and SetLogSpec().
Instead of using these services, utilize the HTTP operations service that was
introduced in v1.4.0.
Support removed in v2.0. For more details see FAB-15390.

Support for specifying orderer endpoints at the global level in channel configuration.

Utilize the new 'OrdererEndpoints' stanza within the channel configuration of
an organization instead.
For more details see FAB-7559.

The 'Solo' consensus type is deprecated.

With the introduction of Raft-based ordering service in v1.4.1, it is possible
to deploy a single-node (non-production) or multi-node
Raft-based ordering service with no external dependencies.
For single-node (non-production) ordering services, utilize Raft-based ordering
service with a single node instead of Solo ordering service.
For more details see FAB-15754.

The 'Kafka' consensus type is deprecated

The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
production consensus type. There is a documented and tested migration path from
Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
For compatibility with existing deployments, Kafka is still supported,
but may be removed entirely in a future release.
Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published.

fabric-couchdb docker image no longer updated, maintained, or published

The fabric-couchdb docker image will no longer be updated, maintained, or published.
Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead.

Change log

For the full list of changes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v149

Changes:

• da55272 Release commit for v1.4.9
• 5146a9f Remove No Longer Relevant Release Note
• 4924294 Update release notes with FAB-18250
• 56a81f7 [FAB-18250] Check Error Before Returning Session to Pool (#1938)
• 17e171b Remove escc and vscc from list of system chaincodes
• 2d63281 Remove GetSessionInfo Call
• 4f1e340 Add release notes for v1.4.9
• 40abeec [FAB-18237] always update stateInfo message upon chaincode update (#1915)
• 693cae5...

v1.4.8

v1.4.8 Release Notes - July 22, 2020

Fixes

Ordering Service: Check suspect info once per suspect interval when using Raft

The raft-based ordering service node was checking to see if it was evicted too often.
This fix ensures that the ordering service node only checks once per suspect interval,
every 10 minutes by default.

Dependency updates

Bump Go to 1.13.12.
Bump Fabric baseimage to 0.4.21.
Fabric v1.4.8 has been tested with CouchDB v2.3.1.

Changes, Known Issues, and Workarounds

core.yaml chaincode.builder property updated to pull correct fabric-ccenv image

The sample core.yaml configuration that gets included in fabric-peer docker
image now sets chaincode.builder property to $(DOCKER_NS)/fabric-ccenv:$(TWO_DIGIT_VERSION)
instead of $(DOCKER_NS)/fabric-ccenv:latest, since fabric-ccenv:latest tag
has been retired from dockerhub. This change ensures that v1.4.x peers using the default
configuration will pull the latest v1.4 fabric-ccenv image from dockerhub to build chaincode,
if the local fabric-ccenv image is not found.

FAB-12134: Same chaincode source receiving fingerprint mismatch error -
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.

Deprecations

The following functions are deprecated and are targeted for removal in a future release.

Support for automatically vendoring the chaincode shim into user chaincodes

The fabric-ccenv image which is used to build chaincode, currently includes
the github.com/hyperledger/fabric/core/chaincode/shim ("shim") package.
This is convenient, as it provides the ability to package chaincode
without the need to include the "shim". However, this may cause issues in future
releases (and/or when trying to use packages which are included by the "shim").
In order to avoid any issues, users are advised to manually vendor the "shim"
package with their chaincode prior to using the peer CLI for packaging and/or
for installing chaincode.
For more details see FAB-5177.

Support for CAR chaincode package format

Support for packaging chaincode using the CAR format will be removed in
a future release.
For more details see FAB-14720.

Support for specifying orderer endpoints at the global level in channel configuration.

Utilize the new 'OrdererEndpoints' stanza within the channel configuration of
an organization instead.
For more details see FAB-7559.

Support for invoking system chaincodes from user chaincodes.

System chaincodes, for example QSCC, are intended to be invoked by
a client rather than by a user chaincode. Invoking from a user chaincode
may cause deadlocks.
For more details see FAB-15285.

Support for user chaincodes to utilize the chaincode shim's logger via NewLogger()

Chaincodes that used the shim's NewLogger() will need to shift to their own preferred
logging mechanism.
For more details see FAB-15366.

Support for peer's Admin service

The peer's Admin service exposes APIs such as GetLogSpec() and SetLogSpec().
Instead of using these services, utilize the HTTP operations service that was
introduced in v1.4.0.
For more details see FAB-15390.

The 'Solo' consensus type is deprecated.

With the introduction of Raft-based ordering service in v1.4.1, it is possible
to deploy a single-node (non-production) or multi-node
Raft-based ordering service with no external dependencies.
For single-node (non-production) ordering services, utilize Raft-based ordering
service with a single node instead of Solo ordering service.
For more details see FAB-15754.

The 'Kafka' consensus type is deprecated

The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
production consensus type. There is a documented and tested migration path from
Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
For compatibility with existing deployments, Kafka is still supported,
but may be removed entirely in a future release.
Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published.

fabric-couchdb docker image no longer updated, maintained, or published

The fabric-couchdb docker image will no longer be updated, maintained, or published.
Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead.

Change log

For the full list of changes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v148

Changes:

• 29e1e77 Release commit for v1.4.8 (#1625)
• 112c6d9 Add release notes for v1.4.8
• ae1395b Tag built docker images with BASE_VERSION and TWO_DIGIT_VERSION
• 81f32de Fix latest tag on ccenv
• caf5b56 Raft: Check suspect info once per suspect interval (#1602)
• 66349cc Print channel name in learnAnchorPeers
• a7eb1f7 [FAB-18043] Correct the code comments (#1530)
• 34294ad Only canonize ECDSA signatures in MSP:IsWellFormed (#1495)
• c2ea18f Bump Go to 1.13.12 and Third-Party Images to 0.4.21 (#1492)
• d34fd05 Fix wrong link sampleconfig

See More

• 4a193ed Set http header entries before writing header
• 9d2258c Update gotools mockery path for release-1.4 (#1417)
• 65e7353 FAB-17161 improve error message
• 52ee947 Fix the installed binary list in the document
• 877cadd [DocUpdate] configtxlator decode/common.ConfigUpdate
• 38b40b5 Prepare for Fabric v1.4.8 release
• e0afaa7 Release Fabric v1.4.7
• 51138b8 Add release notes for v1.4.7
• a178051 [FAB-17728] Add 100ms delay to pkcs11 create session loop (#1253)
• ea185b8 Correct HSM environment variables
• 8ff5d16 Bump baseimage version
• 6112b99 [FAB-17821] fix: use keyword as variable name
• 1964a1b [FAB-17778] MSP.IsWellFormed: Only allow canonical CA signatures
• 5066919 [FAB-17778] Force sanitized signatures be canonically built
• c66c3c4 add the sample policy to remove the test warning info
• e1db649 FAB-17552: add unit test for createKeyStore
• f27803f FAB-17752: following review guide
• c403374 FAB-17752: return errors when creating keystore
• 2f740c4 [FAB-17732] Port HSM updates to release-1.4 branch (#1110)
• 1f0a0dd Validate session and get new if invalid
• b03b3d9 [FAB-17540] Fix for race read/write tlsconfig (#1050)
• 856f215 FAB-15461 Fix election adapter to return correct peers
• f9e80e8 [FAB-16879] Add stack trace to couchdb http errors (#1048)
• c68ee5c [FABB-148, FABB-149]
• 9007739 Properly handle malformed gossip envelopes (#1037)
• 780b16f Fix organizations typo
• 5c2a996 Update to go 1.13
• 3b5b58b Fix deadline logging test
• be925f8 [FAB-16810] comm test changes to support go 1.13
• 7cf38b5 [FAB-16810] bccsp test changes for go 1.13
• 9461ba2 [FAB-17696] Fixed Wiki Link to Contributor meetings
• 1e51225 [FAB-17109] Retrieve ReconnectBackoffThreshold as duration
• afbc42f [FAB-16951] Alternative mechanisms to find pkcs11 key
• ca93be5 BCCSP initialization cleanup
• 2bb6415 [FAB-17517] Only Initialize specified provider
• defb36c Add MSP Key concepts topic to release-1.4 branch
• 609ddf8 Prepare for fabric v1.4.7 release (#743)
• 635fa7b Update release notes for v1.4.6
• af2b462 Release fabric v1.4.6
• 87df051 [FAB-17515] Support configuring BlockValidation policy for orderer group
• 29c58ac [FAB-17431] Decouple javaenv from Fabric version
• ac6305e [FAB-17523] Endorsing peer was not honoring RequiredPeerCount (#716) (#733)
• 0c421c8...

v2.2.0

v2.2.0 Release Notes - July 9, 2020

v2.2 is the first long-term support (LTS) release of Fabric v2.x. Fixes will be provided on the v2.2.x release stream until after the next LTS release is announced.

What's New in Hyperledger Fabric v2.2

FAB-13460: Add Support for TLS 1.3

TLS 1.3 is now supported and will be utilized automatically if client supports TLS 1.3.

FAB-17401: Add function to query the details of the approved chaincode definition

Add support to query an organization's approved chaincode definition from its peer.
The function is available by using peer CLI command peer lifecycle chaincode queryapproved.

Fixes

Return Error From PKCS11 CreateSession

The prior implementation of BCCSP performed a fatal
logging function in the event it could not open a session
with the HSM. It was possible for the fatal log to occur when an expected error
occurred, i.e., the HSM had reached its maximum session handles.
Instead of issuing a fatal log call, an error is returned so that
the error can be properly handled.

FAB-17819: Discovery returns user friendly errors

Service discovery endorsement service error message "cannot satisfy any principal combination" is
improved to return a more specific message, either "no peer combination can satisfy the endorsement policy"
or "required chaincodes are not installed on sufficient peers".

FAB-17774: Support orderer restart without system channel genesis block

When BootstrapMethod was set to 'file', the system channel genesis block
was required to be passed for every orderer service start. The system
channel genesis block is now only required for the initial orderer start.

FAB-17844: External builder fails to copy symlinks from build output into persistent directory

Previously, the external builder code did not check for symlinks in build output when copying them.
This resulted in the resolved files being copied as files instead of symlinks. The external builder
now copies them as symlinks instead of copying them as files into the destination directory.

Errors should be checked when orderer gRPC server is serving requests

gRPC errors are now checked when servicing the orderer atomic broadcast gRPC service.

FAB-17900: Fix environment variable override bug

Integer config values for peer and orderer could not be overridden with environment variables.

FAB-17951: Fetch correct node id for orderer consenter validation

Config update validator may incorrectly reject updates if some nodes are inactive.

FAB-17875: Fix ordering service node leader election failure

Previously with Raft consensus, when one ordering service node was deleted
from a channel and rejoined later, it would be assigned a new Raft id.
However, in some cases the ordering service node still used the old Raft
id. Other ordering service nodes including the leader are using the latest view and believe
that the rejoined node would use a new Raft id. This may result in leader election failure and no new
transactions would be accepted. The fix ensures the correct Raft id is used after tracking the latest config block.

Private data performance optimization: purge transient store in background

Private data performance is improved by purging entries present in the transient store in the background.

FAB-17933: Fix cache update logic for installed chaincode info when an empty or uninstalled package ID is specified

Previous cache update logic for install chaincode info did not work properly when an empty or uninstalled package ID was specified.

FAB-17539: Always remember gossip anchor peers in membership

Gossip removes a peer from its membership cache if no new heartbeats are received from the peer within a timely manner.
If a network partition persists for too long, peers of different organizations never re-establish communication because all membership is purged.
With the fix, anchor peers are no longer removed from the membership cache even if they are offline.
Therefore, after the network partition is healed, peers among different organizations can reestablish communication as long as anchor peers are reachable.

Note: Fixes included in v2.1.1 release notes are also included in v2.2.

Changes

FAB-17786: upgrade_dbs peer command now drops state CouchDB databases

Previously the upgrade_dbs command did not automatically drop state CouchDB
databases and therefore a separate step was required to drop CouchDB data
when upgrading to v2.x. upgrade_dbs command now automatically drops
state CouchDB databases. CouchDB state database will get rebuilt on the first
peer start after the upgrade to v2.x. CouchDB database service
must be available when running upgrade_dbs command. Similarly,
rebuild-dbs also drops state CouchDB data now, so that state database
can be rebuilt on the next peer start.

FAB-17869: Allow TLS CAs with overlapping issuers

The client root TLS CA certificate pool construction didn't allow different issuers
with the same subject name to exist in the CA cert pool. Different issuers with
the same subject name are now allowed.

Fabric CouchDB tests have been updated from CouchDB 2.3.1 to CouchDB 3.1.0

Support is added for CouchDB 3.1.0 as the recommended and tested version of CouchDB.
If prior versions are utilized, a Warning will appear in peer log.
Note that CouchDB 3.1.0 requires that an admin username and password be set,
while this was optional in CouchDB v2.x. See the
Fabric CouchDB documentation
for configuration details.
Also note that CouchDB 3.1.0 default max_document_size is reduced to 8MB. Set a higher value if needed in your environment.
Finally, the fabric-couchdb docker image will not be updated to v3.1.0 and will no longer be updated, maintained, or published.
Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead.

FAB-17917: Peer CouchDB default maxRetriesOnStartup property has been updated

Peer property peer.ledger.state.couchDBConfig.maxRetriesOnStartup default has
changed from 12 to 10. The time between retries doubles after each attempt.
Therefore if CouchDB is not yet started, the peer start will now retry
for about 2 minutes rather than 16 minutes before retries are exhausted.

FAB-16435: Peer gossip defaults have been updated

Block dissemination via gossip may be removed in a future release,
since it is more straightforward for peers to simply pull blocks from ordering service.
The gossip defaults have been updated to prepare users for this possible change, so that peers by default
pull blocks from ordering service, do not use leader election, and do not use block transfer across peers.
Additionally, two block cache default sizes have been lowered to reduce the memory
used by a peer when it has joined many channels.
The new defaults are as follows:

peer.gossip.orgLeader: true
peer.gossip.useLeaderElection: false
peer.gossip.state.enabled: false
peer.gossip.maxBlockCountToStore: 10
peer.gossip.state.blockBufferSize: 20

Default configuration values are included in the peer docker image, therefore if you apply
the new peer image the new defaults will be effective unless you specifically override them
in your configuration.

Build Your First Network sample and tutorial has been removed

Users are recommended to use the test network introduced in v2.0 instead,
and to review the new deployment guides.

FAB-18028: Replace environmentWhiteList peer property with propagateEnvironment

Peer configuration property peer.chaincode.externalBuilders.environmentWhiteList has been replaced with peer.chaincode.externalBuilders.propagateEnvironment.
environmentWhiteList continues to work but is deprecated.

Dependency updates

Fabric project now uses Go modules for vendoring code dependencies.

Bump Go gRPC to 1.29.1.

Bump Go to 1.14.4.

Bump Alpine to 3.12 in Fabric images.

CouchDB 3.1.0 is now the tested CouchDB version.

Deprecations

FAB-15754: The 'Solo' consensus type is deprecated.

The 'Solo' consensus type has always been marked non-production and should be in
use only in test environments, however for compatibility it is still available,
but may be removed entirely in a future release.

FAB-16408: The 'Kafka' consensus type is deprecated.

The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
production consensus type. There is a documented and tested migration path from
Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
For compatibility with existing deployments, Kafka is still supported,
but may be removed entirely in a future release.
Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published.

FAB-7559: Support for specifying orderer endpoints at the global level in channel configuration is deprecated.

Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
Configuring orderer endpoints at the organization level accommodates
scenarios where orderers are run by different organizations. Using
this configuration ensures that only the TLS CA certificates of that organization
are used for orderer communications, in contrast to the global channel level endpoints which
would cause an aggregation of all orderer TLS CA certificates across
all orderer organizatio...

v2.1.1

v2.1.1 Release Notes - June 1, 2020

Fixes

FAB-17778: Fix policy support of multiple signatures from single organization

Fix de-duplication logic to ensure sufficient number of signatures are received to satisfy
policies that require multiple signatures from the same organization.
This problem is rare since most users have policies that require signatures from different
organizations, not policies that require multiple signatures from the same organization.

FAB-17722: Validate HSM session and get new if invalid

Previously the pkcs11 code was set to have a session cache and reuse sessions
if available in cache. If a session went bad (due to connection issues with HSM),
the session was not evicted from cache and would be reused.
If all sessions went bad, the client would never be able to recover and keep using bad sessions.

FAB-17728: Add delay to pkcs11 create session loop

Previously there was no backoff when attempting to create a new session if one was not
available in the HSM session cache. This fix introduces a hardcoded backoff of 100ms
after each attempt up to 10.

FAB-17784: Clarify error message when legacy chaincode install fails during build

When a legacy chaincode install fails due to an error building the
chaincode, the chaincode will remain installed on the peer. This change clarifies
the error message so that users understand the behavior:
"chaincode installed to peer but could not build chaincode".

FAB-17844: Copy symlinks as-is in external builder output

Previously, the external builder code did es not check for symlinks in build output
when copying them. This resulted in the resolved files being copied as files
instead of symlinks. This commit changes the external builder code so that
it tests for symlinks, and copies them as symlinks instead of copying them as
files into the destination directory.

External builder switch from os.Stat to exec.LookPath

Replace call to os.Stat to check for the presence of the bin/release script with exec.LookPath.
The LookPath function, when provided with a relative path, will look for the presence of the
executable and determine if it's executable. On non-unix platforms, it will also handle looking
for executable suffixes as appropriate.

FAB-17907: New chaincode lifecycle should ignore previous build failure during install

When a chaincode build previously failed while installing the chaincode, the new lifecycle
would not attempt to rebuild the chaincode on the next install attempt, rather the prior
build error message was returned to the client. This change ensures that the subsequent
install attempt rebuilds the chaincode.

FAB-17733: Validate TLS certs during raft consenter addition

Validate the client/server TLS certs against the orderer organizations while adding a raft consenter.

For the full list of changes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/release-2.1/CHANGELOG.md#v211

Changes:

• 6393adb Release commit for Fabric v2.1.1
• e8bfb68 Add release notes for v2.1.1
• 7be9c62 _lifecycle ignore previous build failure during install
• 4cbaeb4 Validate TLS certs during raft consenter addition (#1342)
• 02fc373 Fixed write_first_app.rst typo
• 6b7177b Ensure backward compatibility of range query rwset
• d39afc8 Update Prereqs for Fabric users
• f485b83 [FAB-10879] Adding instructions for modifying Commands Reference
• 389d616 Switch from os.Stat to exec.LookPath
• fe7e948 Fix script help text in the test network document

See More

• dff43d2 fix test network docs typo
• c705510 Fix the installed binary list in the document
• 716dc7e [FAB-17844] Copy symlinks as-is in external builder output
• f2bfb58 Add export to deploy CC tutorial
• 6dc13f0 Remove adding PWD to path in tutorials
• e197020 Cherry pick test network tutorial improvements to 2.1
• 6eec309 Clarify error message when lscc chaincode install fails during build
• bd61a92 Merge first component of create channel tutorial
• e765962 [FAB-17438] Add links to CA deployment Guide from Fabric Deployment Guide
• 2cac1e2 Replace link to removed topic with link to relavent image
• 2052dd2 [FAB-17728] Add 100ms delay to pkcs11 create session loop
• 9ce5aeb Validate session and get new if invalid (#1255)
• ba86e48 Fix misleading doc statement
• c66bcda Correct HSM environment variables
• d1e1cbd Update enable_cc_lifecycle.md
• bde493c Update old link in command wrappers
• 971add2 Add link to Go contract API to smart contract processing topic
• 2909e71 Doc that Init is not required if you use the contract API
• d25e8ce Replace erroneous double dash
• e87c350 Add statement about compliance to HSM docs
• a3d4168 [FAB-17778] Force sanitized signatures be canonically built
• 407afa7 Remove typo from commercial paper tutorial
• 4abbf5a Add upgrade steps and troubleshooting to deployCC tutorial
• 6189c3b Let users know that anchor peer tx is deprecated
• 5cf1f96 [FAB-17700] Fix wrong docker rmi in documents
• aee43e6 [FAB-17732] HSM clarifications (#1108)
• 1bdf975 Fabric v2.1.0 release commit
• 6cfea8b Add release notes for v2.1.0
• 4fbbc88 [FAB-17719] Upgrade docs for 2.1
• d50e8f4 [FAB-17724] Fix configtxgen cannot find etcdraft default config
• c2e8534 [FAB-17716] Fix test flake due to too many requests for /protos.Deliver
• 5358d6e Properly handle malformed gossip envelopes (#1039)
• 0602969 [FAB-17540] Fix for race read/write tlsconfig (#967) (#1052)
• 10ed627 Add release note for FAB-17725
• 08df2e1 Omit go.{mod,sum} from pkg when not in module mode
• d0d4a3f Clear {U,G}name fields in package tar entries
• 53eda41 Fix typo
• 6334d22 Fix organizations typo
• 0f23dad [FAB-16879] Add stack trace to couchdb http errors (#1015)
• 6f4b196 Update chaincode lifecycle topic
• 2f13c6c Update tutorials overview for test network
• 32533a8 3 small fixes that documentation matches samples
• a28ef41 Set default keepalive options for peer clients (#987)
• c740f39 Update doc for Go v1.14.1
• 99d3a8d Remove Config Transaction Package from release-2.1
• 30e5862 Fix missing export instruction in docs/deploy_chaincode.md
• 534ed60 Move comm pkg to internal
• 7919e72 [FAB-17109] Retrieve and use ReConnectBackoffThreshold as duration (#951)
• f293f92 mv encoding util to consumer (pvtdatastorage)
• 25e3386 Fix code block typo in add org tutorial
• 20dca4d Clarify instructions for CouchDB state database upgrade.
• 8704abf Add discussion of MSP folder to test net doc
• 5148730 [FAB-17687] Rename AddValue() to SetValue() (#946)
• 0491bcd Refactor MSP-related pkg/config functions
• 4d7d4ac [FAB-17638] Support retrieving application configuration from an existing config
• 84e2338 [FAB-17658] Separate config package examples into groups
• eb4623f [FAB-17408] Move first app tutorial (fabcar) to test network
• 1cdd885 Update commercial_paper.md
• cce54ab [FAB-17664] Add/Remove channel policies
• 424807d Add jq to the vagrant development environment
• 8ab138e Address comments from #928
• b8e2e83 [FAB-17611] IT: discover all peers before endorsement
• 8a012a0 Consistently use ubuntu-18.04
• fa29042 Move to go 1.14.1 (#934)
• 69da72e Remove x509 Utility
• 4db1939 Remove Clone Utility
• 1a3dab1 Remove DirMissingOrEmpty Util Function
• d7c1796...

v1.4.7

v1.4.7 Release Notes - May 14, 2020

Fixes

• FAB-17517: Only Initialize specified BCCSP provider

  This fix ensures that only specified provider is initialized
  based on ProviderName.
  This fixes "Failed initializing PKCS11.BCCSP %!s()" error
  when the code compiled with PKCS11 or PLUGINS enabled expected
  configuration to not be nil even when Provider is set to SW.

• FAB-16951: Alternative mechanisms to find pkcs11 key

  This modification adds a parameter called AltID to the PKCS11 BCCSP configuration.
  This change is required in situations where the HSM does not allow
  modification of the CKA_ID after creation, for example when using AWS CloudHSM.

• FAB-17726: Properly handle malformed gossip envelopes

  If a malformed envelope is read from the stream, an error is propagated
  synchronously up the stack.
  Under very rare circumstances a race condition caused a nil pointer peer panic.

• FAB-16879: Add stack trace to couchdb http errors

  If there was an http error calling couchdb, no context was provided in the error message.
  This change adds stack trace in addition to the http error message,
  so that administrators can identify where the error was hit.

• FAB-17722: Validate HSM session and get new if invalid

  Previously the pkcs11 code was set to have a session cache and reuse sessions
  if available in cache. If a session went bad (due to connection issues with HSM),
  the session was not evicted from cache and would be reused.
  If all sessions went bad, the client would never be able to recover and keep using bad sessions.

• FAB-17752: Return errors when creating keystore

  An error is now returned if BCCSP is not able to create keystore directory.

• FAB-17778: Fix policy support of multiple signatures from single organization

  Fix de-duplication logic to ensure sufficient number of signatures are received to satisfy
  policies that require multiple signatures from the same organization.
  This problem is rare since most users have policies that require signatures from different
  organizations, not policies that require multiple signatures from the same organization.

• FAB-17728: Add delay to pkcs11 create session loop

  Previously there was no backoff when attempting to create a new session if one was not
  available in the HSM session cache. This fix introduces a hardcoded backoff of 100ms
  after each attempt up to 10.

Dependency updates

• Bump Go to 1.13.9.
• Bump Fabric baseimage to 0.4.20.

Changes, Known Issues, and Workarounds

• FAB-12134: Same chaincode source receiving fingerprint mismatch error -
  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.

Deprecations

The following functions are deprecated and are targeted for removal in a future release.

• Support for automatically vendoring the chaincode shim into user chaincodes

  The fabric-ccenv image which is used to build chaincode, currently includes
  the github.com/hyperledger/fabric/core/chaincode/shim ("shim") package.
  This is convenient, as it provides the ability to package chaincode
  without the need to include the "shim". However, this may cause issues in future
  releases (and/or when trying to use packages which are included by the "shim").
  In order to avoid any issues, users are advised to manually vendor the "shim"
  package with their chaincode prior to using the peer CLI for packaging and/or
  for installing chaincode.
  For more details see FAB-5177.

• Support for CAR chaincode package format

  Support for packaging chaincode using the CAR format will be removed in
  a future release.
  For more details see FAB-14720.

• Support for specifying orderer endpoints at the global level in channel configuration.

  Utilize the new 'OrdererEndpoints' stanza within the channel configuration of
  an organization instead.
  For more details see FAB-7559.

• Support for invoking system chaincodes from user chaincodes.

  System chaincodes, for example QSCC, are intended to be invoked by
  a client rather than by a user chaincode. Invoking from a user chaincode
  may cause deadlocks.
  For more details see FAB-15285.

• Support for user chaincodes to utilize the chaincode shim's logger via NewLogger()

  Chaincodes that used the shim's NewLogger() will need to shift to their own preferred
  logging mechanism.
  For more details see FAB-15366.

• Support for peer's Admin service

  The peer's Admin service exposes APIs such as GetLogSpec() and SetLogSpec().
  Instead of using these services, utilize the HTTP operations service that was
  introduced in v1.4.0.
  For more details see FAB-15390.

• Support for Solo ordering service

  With the introduction of Raft-based ordering service in v1.4.1, it is possible
  to deploy a single-node (non-production) or multi-node
  Raft-based ordering service with no external dependencies.
  For single-node (non-production) ordering services, utilize Raft-based ordering
  service with a single node instead of Solo ordering service.
  For more details see FAB-15754.

Change log

For the full list of changes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v147

Changes:

• e0afaa7 Release Fabric v1.4.7
• 51138b8 Add release notes for v1.4.7
• a178051 [FAB-17728] Add 100ms delay to pkcs11 create session loop (#1253)
• ea185b8 Correct HSM environment variables
• 8ff5d16 Bump baseimage version
• 6112b99 [FAB-17821] fix: use keyword as variable name
• 1964a1b [FAB-17778] MSP.IsWellFormed: Only allow canonical CA signatures
• 5066919 [FAB-17778] Force sanitized signatures be canonically built
• c66c3c4 add the sample policy to remove the test warning info
• e1db649 FAB-17552: add unit test for createKeyStore

See More

• f27803f FAB-17752: following review guide
• c403374 FAB-17752: return errors when creating keystore
• 2f740c4 [FAB-17732] Port HSM updates to release-1.4 branch (#1110)
• 1f0a0dd Validate session and get new if invalid
• b03b3d9 [FAB-17540] Fix for race read/write tlsconfig (#1050)
• 856f215 FAB-15461 Fix election adapter to return correct peers
• f9e80e8 [FAB-16879] Add stack trace to couchdb http errors (#1048)
• c68ee5c [FABB-148, FABB-149]
• 9007739 Properly handle malformed gossip envelopes (#1037)
• 780b16f Fix organizations typo
• 5c2a996 Update to go 1.13
• 3b5b58b Fix deadline logging test
• be925f8 [FAB-16810] comm test changes to support go 1.13
• 7cf38b5 [FAB-16810] bccsp test changes for go 1.13
• 9461ba2 [FAB-17696] Fixed Wiki Link to Contributor meetings
• 1e51225 [FAB-17109] Retrieve ReconnectBackoffThreshold as duration
• afbc42f [FAB-16951] Alternative mechanisms to find pkcs11 key
• ca93be5 BCCSP initialization cleanup
• 2bb6415 [FAB-17517] Only Initialize specified provider
• defb36c Add MSP Key concepts topic to release-1.4 branch
• 609ddf8 Prepare for fabric v1.4.7 release (#743)
• 635fa7b Update release notes for v1.4.6
• af2b462 Release fabric v1.4.6
• 87df051 [FAB-17515] Support configuring BlockValidation policy for orderer group
• 29c58ac [FAB-17431] Decouple javaenv from Fabric version
• ac6305e [FAB-17523] Endorsing peer was not honoring RequiredPeerCount (#716) (#733)
• 0c421c8 Fix nil dereference in etcdraft config parsing (#724)
• 9072299 Add ending braces to ReadWrite set.
• a0b7584 Optimize inquire.IsSubset (#713)
• 60c8ab9 Prepare for next fabric rel v1.4.6
• 11ff991 Release fabric v1.4.5 (#695)
• 1893808 Remove rollback code from private data store
• f354c81 [FAB-17472] Clarify doc and samples for NodeOU Certificate
• d45bac4...

v2.1.0

v2.1.0 Release Notes - April 15, 2020

What's New in Hyperledger Fabric v2.1

FAB-17357: Add endorser metric for simulation failure

Added metric endorser_proposal_simulation_failures.

FAB-14761: Limit concurrent requests to endorser and deliver services

Limits can now be placed on the number of endorser and deliver requests
that a peer will process at any one time. If a peer is already processing its
limit of requests, subsequent requests in excess of the limit will return an error,
and the client will need to retry the call. The limits are configured using the
following core.yaml properties:

• peer.limits.concurrency.endorserService
• peer.limits.concurrency.deliverService

FAB-17463: Allow peer to override implicit collection dissemination properties

The following config properties have been added to peer's core.yaml
for implicit private data collection dissemination:

• peer.gossip.pvtData.ImplicitCollectionDisseminationPolicy.requiredPeerCount
• peer.gossip.pvtData.ImplicitCollectionDisseminationPolicy.maxPeerCount

When a peer endorses a transaction that writes to its own organization's
implicit private data collection, the new properties will dictate how
many other peers in the organization the endorsing peer will attempt to
disseminate to (maxPeerCount), and how many peers must acknowledge receipt
of the private data before endorsement succeeds (requiredPeerCount).
These properties are applicable to all channels the peer has joined. The implication
is that requiredPeerCount has to be smaller than the number of peers in a channel
that has the lowest numbers of peers from the organization.

FAB-17279: Support collection level endorsement policies for discovery

v2.0 added an option to specify an endorsement policy at a chaincode's private
data collection level. Service discovery now supports this feature when the
collection name is passed to the discovery endorsers query.

Discover CLI now supports SEC 1 formatted private keys
Private keys that are generated with openssl ecparam (SEC 1 format) are now supported
with the discover CLI, in addition to the PKCS8 private keys that were already supported.

Dependency updates

• Bump docker images to Alpine 3.11.
• Bump Go to 1.14.1.
• Bump Go grpc to 1.28.0.

Fixes

All fixes in v2.0.1 have also been applied to v2.1.0. Additionally the following fixes have been made.

FAB-17441: approveformyorg lifecycle command should allow update of only package ID

approveformyorg lifecycle command now allows only the package ID to be updated.

Fix nil dereference in etcdraft config parsing

The etcdraft config parsing code checked that the consensus
metadata was not nil, but it failed to check that the options were not nil.
The additional nil checks have been added.

FAB-17517: Only Initialize specified BCCSP provider

When Fabric is built with GO_TAGS="pkcs11",
BCCSP attempted to initialize PKCS11 even when BCCSP is configured for software.
This resulted in error
"Failed to initialize local MSP: could not initialize BCCSP Factories: Failed initializing PKCS11.BCCSP"

FAB-17672: Prevent gossip probes from registering as long lasting connections

This fix helps to more quickly establish gossip connections when
peers are starting at the same time.

FAB-17726: Properly handle malformed gossip envelopes

Fix rare nil pointer panic at:
github.com/hyperledger/fabric/gossip/comm.interceptAcks.func1(0x0)
/opt/gopath/src/github.com/hyperledger/fabric/gossip/comm/ack.go:66 +0x2e

FAB-17725: Omit go.mod and go.sum from package when not in module mode

In certain environments, it's possible to package chaincode that is structured
as a module from an active GOPATH. This often happens when the path provided
to the package command is an import path resolvable from the GOPATH instead of
a file system path.

If the package can successfully build in the packaging environment from the
import path, the chaincode dependencies are calculated and packaged from the
GOPATH for compilation as a traditional go package.

In this scenario where the code at the import path is structured as a module,
the go.mod would be included in the chaincode package as packaging always
includes all non-hidden files in the top level folder of the import path.

On the server, the presence of the go.mod implies that the build process
should execute in module mode. When the dependencies have been vendored in the
module, the build uses -mod=vendor flag to indicate the module requirements
should be satisfied from the vendor folder. Unfortunately, since the
chaincode dependencies were packaged using GOPATH mode instead of module mode,
there are some metadata files missing from the vendor folder that are expected
by the module mode build process.

To help prevent this from occurring, we will explicitly omit go.mod and go.sum
from top level folder of chaincode that is not packaged in module mode.

For the full list of changes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/release-2.1/CHANGELOG.md#v210

Changes:

• 1bdf975 Fabric v2.1.0 release commit
• 6cfea8b Add release notes for v2.1.0
• 4fbbc88 [FAB-17719] Upgrade docs for 2.1
• d50e8f4 [FAB-17724] Fix configtxgen cannot find etcdraft default config
• c2e8534 [FAB-17716] Fix test flake due to too many requests for /protos.Deliver
• 5358d6e Properly handle malformed gossip envelopes (#1039)
• 0602969 [FAB-17540] Fix for race read/write tlsconfig (#967) (#1052)
• 10ed627 Add release note for FAB-17725
• 08df2e1 Omit go.{mod,sum} from pkg when not in module mode
• d0d4a3f Clear {U,G}name fields in package tar entries

See More

• 53eda41 Fix typo
• 6334d22 Fix organizations typo
• 0f23dad [FAB-16879] Add stack trace to couchdb http errors (#1015)
• 6f4b196 Update chaincode lifecycle topic
• 2f13c6c Update tutorials overview for test network
• 32533a8 3 small fixes that documentation matches samples
• a28ef41 Set default keepalive options for peer clients (#987)
• c740f39 Update doc for Go v1.14.1
• 99d3a8d Remove Config Transaction Package from release-2.1
• 30e5862 Fix missing export instruction in docs/deploy_chaincode.md
• 534ed60 Move comm pkg to internal
• 7919e72 [FAB-17109] Retrieve and use ReConnectBackoffThreshold as duration (#951)
• f293f92 mv encoding util to consumer (pvtdatastorage)
• 25e3386 Fix code block typo in add org tutorial
• 20dca4d Clarify instructions for CouchDB state database upgrade.
• 8704abf Add discussion of MSP folder to test net doc
• 5148730 [FAB-17687] Rename AddValue() to SetValue() (#946)
• 0491bcd Refactor MSP-related pkg/config functions
• 4d7d4ac [FAB-17638] Support retrieving application configuration from an existing config
• 84e2338 [FAB-17658] Separate config package examples into groups
• eb4623f [FAB-17408] Move first app tutorial (fabcar) to test network
• 1cdd885 Update commercial_paper.md
• cce54ab [FAB-17664] Add/Remove channel policies
• 424807d Add jq to the vagrant development environment
• 8ab138e Address comments from #928
• b8e2e83 [FAB-17611] IT: discover all peers before endorsement
• 8a012a0 Consistently use ubuntu-18.04
• fa29042 Move to go 1.14.1 (#934)
• 69da72e Remove x509 Utility
• 4db1939 Remove Clone Utility
• 1a3dab1 Remove DirMissingOrEmpty Util Function
• d7c1796 [FAB-17663] Update a consortium group's channel creation policy value
• 23ebd79 Update grpc to v1.28.0
• e06bb3f [FAB-17675] Prevent gossip probe from registering as a connection (#925)
• b5be754 [FAB-17637] Support adding and removing capability
• 222f99a [FAB-17639] Add/Remove ACLs from channel config.
• 4d515e0 [FAB-17619] Fix exported ConfigTx functions to retrieve/set correct field
• 79fb075 [FAB-17619] encapsulate config proto in new type
• 441fd13 [FAB-17650] fix incorrect word
• edd5908 Update MSP config for application org
• cdc2f68 Cleanup followup comments from FAB-17568
• 4b9302e Ignore containers that are not part of the network (#909)
• aa80495 U...

v2.0.1

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

Changes:

• 1cfa5da Updates for fabric release v2.0.1
• 7282895 [FAB-17515] Support configuring BlockValidation policy for orderer group
• 618a4ce [FAB-17491] Do not disseminate pvtdata for other org's implicit collection
• 727327d [FAB-17523] Endorsing peer was not honoring RequiredPeerCount (#716) (#729)
• 371c435 Optimize inquire.IsSubset (#714)
• bb46909 [FAB-17059] Extend private data integration tests to cover case when a
• 0885c2f [FAB-17059] Change collection membership eligibility checks to
• f4e4a95 [FAB-17472] Clarify doc and samples for NodeOU Certificate
• c742dd6 [FAB-17453] 'peer lifecycle chaincode package' mandates does not need to init crypto
• 4665ec5 [FAB-17479] Migrated Kafka cluster can be safely expanded later (#645)

See More

• 61f5706 [FAB-14679] Update commercial paper tutorial for new
• c63e674 Explicitly enumerate orderer and peer metrics
• 2daa2b0 Add link to policies topic to chaincode for operators (#659) (#660)
• dc8071c Update Copyright for 2020
• f8b21b1 fix typo
• 4961395 Fix typo in package error message
• 993b7a0 [FAB-17458] check LifecycleV20 capability before getting cc info (#608)
• 7a1d517 Remove 1.x video from 2.0 docs
• 5bf6583 Remove Fabric functionalities doc
• 361edb6 [FAB-17267] Move add an org to a channel tutorial to test network
• b96f178 [FAB-17381] Update policy concept for test network
• c987e77 Update branch to dynamic variable
• 5fe6530 Add support for placeholder replacement in doc builds
• 13d12e5 [FABCN-378] Update links to chaincode JSDoc
• 721a6e7 Remove link for node SDK tutorial
• 913d770 [FAB-17424] Fix broken link in DevApps connection profile
• a521d2a Fix conditional_packages processing in UT script
• 0432c3e Add changelog for v2.0.0
• 77ff3d2 Install doc and script updates for v2.0.0
• 324d2d1 Add release notes for v2.0.0
• 5eec23d What's New updates for v2.0.0 release
• 7f772f9 Add Core Maintainers to /docs in CODEOWNERS
• 63228ea Revert "FAB-14693 Vendor updated fabric-amcl package"
• a04d430 [FAB-17439] Add integration test for verifying fabric-chaincode-go
• ac2f490 [FAB-17421] Reword links to contract APIs and documentation
• 94eeecf Enable service discovery querying _lifecycle endorsers
• 3777652 Validate label when packaging _lifecycle chaincode
• 419690a [FAB-17431] Use two digit version for chaincode images
• d25d2a5 Create a new Documentation Maintainers sub-group
• e7fb9c7 [FAB-17303] Set RequiredPeerCount and MaxPeerCount defaults for implicit
• 9bd0a95 [FAB-17439] Expose peer's MSPID to chaincode as an env var (#549)
• be23695 Bump fabric-chaincode-go (#564)
• 666a5b7 FAB-17410 Updated doc links to latest levels
• 2777611 [FAB-17428] Deprecate --outputAnchorPeersUpdate flag in configtxgen
• ded1729 Updating chaincode document.
• da131ec Stop _lifecycle ccs that are no longer referenced
• 5c6bdda No need to explicitly deregister handler from registry
• 0f18fc9 FAB-16033 Update channel_artifacts location in doc.
• 0da8233 Update resources in enable _lifecycle doc
• 5131473 Update _lifecycle resources in configtx.yaml
• 868da99 Improve chaincode lifecycle peer log messages (#530)
• dbac8a5 Add disclaimer for commercial paper tutorial
• f94d3b1 Remove references to instantiating a chaincode
• 5cadc61 [FAB-17411] Update Fabric versions where necessary
• 8556a43...

v1.4.6

v1.4.6 Release Notes - February 25, 2020

Fixes

• FAB-17519: Improve Discovery endorsement policy performance

  Fix peer CPU spikes during evaluation of endorsement policy
  combinations, due to expensive reflection.

• Fix nil dereference in etcdraft config parsing

  The etcdraft config parsing code was failing to check that the consensus
  metadata options are not nil.

• FAB-17523: Endorsing peer was not honoring private data RequiredPeerCount

  In Fabric v1.4.4 and v1.4.5, 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-17431: Decouple javaenv version from Fabric version

  By default Fabric peer core.yaml was configured to use the following javaenv
  image for java chaincode:

  runtime: $(DOCKER_NS)/fabric-javaenv:$(ARCH)-$(PROJECT_VERSION)

  Since javaenv versioning may deviate from Fabric versioning,
  the javaenv reference is updated to use the latest two digit version:

  runtime: $(DOCKER_NS)/fabric-javaenv:$(TWO_DIGIT_VERSION)

  For example, Fabric v1.4.6 would utilize fabric-javaenv:1.4.

Changes, Known Issues, and Workarounds

• FAB-12134: Same chaincode source receiving fingerprint mismatch error -
  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.

Deprecations

The following functions are deprecated and are targeted for removal in a future release.

• Support for automatically vendoring the chaincode shim into user chaincodes

  The fabric-ccenv image which is used to build chaincode, currently includes
  the github.com/hyperledger/fabric/core/chaincode/shim ("shim") package.
  This is convenient, as it provides the ability to package chaincode
  without the need to include the "shim". However, this may cause issues in future
  releases (and/or when trying to use packages which are included by the "shim").
  In order to avoid any issues, users are advised to manually vendor the "shim"
  package with their chaincode prior to using the peer CLI for packaging and/or
  for installing chaincode.
  For more details see FAB-5177.

• Support for CAR chaincode package format

  Support for packaging chaincode using the CAR format will be removed in
  a future release.
  For more details see FAB-14720.

• Support for specifying orderer endpoints at the global level in channel configuration.

  Utilize the new 'OrdererEndpoints' stanza within the channel configuration of
  an organization instead.
  For more details see FAB-7559.

• Support for invoking system chaincodes from user chaincodes.

  System chaincodes, for example QSCC, are intended to be invoked by
  a client rather than by a user chaincode. Invoking from a user chaincode
  may cause deadlocks.
  For more details see FAB-15285.

• Support for user chaincodes to utilize the chaincode shim's logger via NewLogger()

  Chaincodes that used the shim's NewLogger() will need to shift to their own preferred
  logging mechanism.
  For more details see FAB-15366.

• Support for peer's Admin service

  The peer's Admin service exposes APIs such as GetLogSpec() and SetLogSpec().
  Instead of using these services, utilize the HTTP operations service that was
  introduced in v1.4.0.
  For more details see FAB-15390.

• Support for Solo ordering service

  With the introduction of Raft-based ordering service in v1.4.1, it is possible
  to deploy a single-node (non-production) or multi-node
  Raft-based ordering service with no external dependencies.
  For single-node (non-production) ordering services, utilize Raft-based ordering
  service with a single node instead of Solo ordering service.
  For more details see FAB-15754.

Change log

For the full list of changes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v146

Changes:

• 635fa7b Update release notes for v1.4.6
• af2b462 Release fabric v1.4.6
• 87df051 [FAB-17515] Support configuring BlockValidation policy for orderer group
• 29c58ac [FAB-17431] Decouple javaenv from Fabric version
• ac6305e [FAB-17523] Endorsing peer was not honoring RequiredPeerCount (#716) (#733)
• 0c421c8 Fix nil dereference in etcdraft config parsing (#724)
• 9072299 Add ending braces to ReadWrite set.
• a0b7584 Optimize inquire.IsSubset (#713)
• 60c8ab9 Prepare for next fabric rel v1.4.6

This list of changes was auto generated.

v1.4.5

v1.4.5 Release Notes - February 19, 2020

What's New in Hyperledger Fabric v1.4.5

The following enhancements are included in this release:

• FAB-15648: Allow separate TLS config for Raft cluster and client

  When intra-cluster Raft communication is configured to use separate
  listener, allow TLS to be disabled for the client-facing listener,
  and assume TLS is always enabled for the cluster listener.

Fixes

• FAB-17261: Add HostConfig to chaincode image builder

  Prior to the fix, the Docker HostConfig configured in peer was only used
  when creating a chaincode container. The configured Docker HostConfig is
  now used when building a chaincode image and when creating a chaincode container.

• FAB-17220: Dynamically build TLS config in Raft client handshake

  This fix ensures that the latest TLS CA certificates are used by Raft ordering
  service nodes when certificates are updated in the channel config.

• FAB-17289: Fix gossip goroutine memory leak when reading msg

  A peer gossip memory leak observed in stress tests is fixed.

• FAB-17327: Static leader should not give up retrieving blocks

  When a peer is configured as a static org leader for gossip, it will
  not give up on retrieving blocks in the event that the ordering
  service goes down for an extended period of time (i.e. longer than the
  peer.deliveryclient.reconnectTotalTimeThreshold). Prior to the fix,
  the peer had to be restarted before it would retrieve blocks again.

• FAB-17277: Fix too many TCP connections between peer and CouchDB

  The peer created a large number of TCP connections to CouchDB because the
  default reusable connection pool size is 2 per host while the max pool size
  is 100 (combining all hosts). Thus only 2 TCP connections could be reused
  by the peer when it accessed CouchDB. When more than two goroutines in the
  peer tried to simultaneously access CouchDB, it resulted in new non-reusable
  connections (i.e., creation of new TCP connection outside the pool).
  The fix sets MaxIdleConns and MaxIdleConnsPerHost to 2000. This creates 2000
  TCP connections in the pool which are reused whenever the peer accesses CouchDB.

• 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-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.

Changes, Known Issues, and Workarounds

• FAB-12134: Same chaincode source receiving fingerprint mismatch error -
  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.

Deprecations

The following functions are deprecated and are targeted for removal in a future release.

• Support for automatically vendoring the chaincode shim into user chaincodes

  The fabric-ccenv image which is used to build chaincode, currently includes
  the github.com/hyperledger/fabric/core/chaincode/shim ("shim") package.
  This is convenient, as it provides the ability to package chaincode
  without the need to include the "shim". However, this may cause issues in future
  releases (and/or when trying to use packages which are included by the "shim").
  In order to avoid any issues, users are advised to manually vendor the "shim"
  package with their chaincode prior to using the peer CLI for packaging and/or
  for installing chaincode.
  For more details see FAB-5177.

• Support for CAR chaincode package format

  Support for packaging chaincode using the CAR format will be removed in
  a future release.
  For more details see FAB-14720.

• Support for specifying orderer endpoints at the global level in channel configuration.

  Utilize the new 'OrdererEndpoints' stanza within the channel configuration of
  an organization instead.
  For more details see FAB-7559.

• Support for invoking system chaincodes from user chaincodes.

  System chaincodes, for example QSCC, are intended to be invoked by
  a client rather than by a user chaincode. Invoking from a user chaincode
  may cause deadlocks.
  For more details see FAB-15285.

• Support for user chaincodes to utilize the chaincode shim's logger via NewLogger()

  Chaincodes that used the shim's NewLogger() will need to shift to their own preferred
  logging mechanism.
  For more details see FAB-15366.

• Support for peer's Admin service

  The peer's Admin service exposes APIs such as GetLogSpec() and SetLogSpec().
  Instead of using these services, utilize the HTTP operations service that was
  introduced in v1.4.0.
  For more details see FAB-15390.

• Support for Solo ordering service

  With the introduction of Raft-based ordering service in v1.4.1, it is possible
  to deploy a single-node (non-production) or multi-node
  Raft-based ordering service with no external dependencies.
  For single-node (non-production) ordering services, utilize Raft-based ordering
  service with a single node instead of Solo ordering service.
  For more details see FAB-15754.

Change log

For the full list of changes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v145

Changes:

• 11ff991 Release fabric v1.4.5 (#695)
• 1893808 Remove rollback code from private data store
• f354c81 [FAB-17472] Clarify doc and samples for NodeOU Certificate
• d45bac4 Add release notes for Fabric v1.4.5
• a9a1d07 [FAB-17059] Extend private data integration tests to cover case when a
• ca1ae38 [FAB-17059] Change collection membership eligibility checks to
• e75bc71 [FAB-17479] Migrated Kafka cluster can be safely expanded later (#642)
• 5eaae3a Explicitly enumerate orderer and peer metrics
• 9faad9e define couchDB connection pool size
• b27a7c7 [FAB-16681] Fix inconsistencies in the fabcar tutorial

See More

• 46daf02 [FAB-16508] Update commercial paper tutorial to match code
• 0a6993d Add Documentation Maintainers to CODEOWNERS file
• 52e5155 Point to Artifactory for chaintool downloads
• 1786f10 [FABCN-378] Update links to chaincode JSDoc
• bc3bb1a [FAB-15578] Fix typos on the endorser metric name
• 975cc00 FAB-16033 Update channel_artifacts location in doc.
• cae8b55 Static leader should not give up retrieving blocks
• f0ea825 [FAB-17169] Add AZP Status Badge (#511)
• 3ad450d Go SDK link should point to 1.4 release [ #476 ]
• 1b6bea7 Update dead link to Go Chaincode SDK
• 9ec196b Add CODEOWNERS group
• a8639ba Allow seperate TLS config for cluster and client (#393)
• d4dca95 [FAB-17235] Fixed broken links in Chaincode for Operators release-1.4
• 835cae3 [FAB-15900] Add pkcs11 section to orderer.yaml
• 3bae50c [FAB-17289] Fix gossip goroutine leak when reading msg (#439)
• 24d418d [FAB-17128] Add single quote to channel name env var (#437)
• f627b88 Wrong protobuf import in etcdarft
• 778f87b FAB-17177] Config block shouldn't verify itself in block replication
• 0ce6685 [FAB-17220] Dynamically build TLS config in Raft client handshake
• eea42cb Increase open file limit to address Gossip flakes
• 3a9b5e3 Fix flaky etcdraft test by installing chaincode serially
• b4b0191 Deliver can send multiple blocks when seeking newest
• 634e14b Attempt to fix flak...

v2.0.0

v2.0.0 Release Notes - January 29, 2020

What's New in Hyperledger Fabric v2.0

The following new major features are included in the v2.0.0 release.
For additional details including upgrade steps, see the What's New documentation.

FAB-11237: Decentralized smart contract governance

Fabric 2.0 introduces decentralized governance for smart contracts, with a
new process for installing a chaincode on your peers and starting it on a
channel. The new Fabric chaincode lifecycle allows multiple organizations to
come to agreement on the parameters of a chaincode, such as the chaincode
endorsement policy, before it can be used to interact with the ledger.

New application patterns and private data enhancements

The same decentralized methods of coming to agreement that underpin the new chaincode
lifecycle management can also be used in your own chaincode applications to ensure
organizations consent to data transactions before they are committed to the ledger.

Fabric v2.0 also enables new patterns for working with and sharing private data,
without the requirement of creating private data collections for all combinations
of channel members that may want to transact. Specifically, instead of sharing private
data within a collection of multiple members, you may want to share private data
across collections, where each collection may include a single organization,
or perhaps a single organization along with a regulator or auditor.

• FAB-10889: Implicit org-specific collections
• FAB-15066: Endorsement policies for collections
• FAB-13581: memberOnlyWrite collection configuration option
• FAB-13527: GetPrivateDataHash chaincode API
• FAB-12043: Option to include private data in block events

FAB-13584: External chaincode launcher

The external chaincode launcher feature empowers operators to build and launch
chaincode with the technology of their choice. Use of external builders and
launchers is not required as the default behavior builds and runs chaincode
in the same manner as prior releases using the Docker API.

FAB-103: State database cache for CouchDB

A new peer cache improves performance when using CouchDB state database.

Important Changes

FAB-5177: The ccenv build image no longer includes the shim

The shim package and dependencies for go chaincode are no longer included in
the chaincode build environment. Chaincode packages that do not include their
own dependencies will no longer successfully build on the peer. We strongly
recommend that existing go chaincode be updated to vendor the
github.com/hyperledger/fabric-chaincode-go/shim package and its dependencies.
While there are many tools for managing vendored dependencies, we recommend
moving directly to go modules and vendoring with go mod vendor.

FAB-15366: Logger removed from chaincode shim

Chaincode that used the shim's NewLogger() will need to shift to a new
logging mechanism. Chaincode logging is intended to be the responsibility
of the application developer. As such it should be handled using tools and
libraries that make the most sense to the chaincode developer and the
application in general. Chaincode developers can forward STDOUT and STDERR
from the chaincode container to the peer container by setting
CORE_VM_DOCKER_ATTACHSTDOUT=true. While not recommended for production,
once enabled, each chaincode will receive its own logging channel and
STDOUT and STDERR will be integrated in the peers log on a per-line basis.
A production grade approach would be to run a log aggregation service and
forward your logs to the aggregation service.

FAB-16213: The go chaincode entities extension has been removed

Chaincode implementations that used the entities extension package from an
earlier version of Fabric will need to vendor a 1.x version of the package
for as part of their chaincode package.

FAB-12075: Client Identity (CID) library has moved

If chaincode uses client identity (CID) library, note that the source
location has moved to fabric-chaincode-go repository at location /pkg/cid.

FAB-14720: Support for CAR chaincode package format removed

FAB-15285: Support for invoking system chaincodes from user chaincodes
has been removed.

System chaincodes, for example QSCC, are intended to be
invoked by a client rather than by a user chaincode. Invoking from a user
chaincode caused deadlocks in prior releases.

FAB-15390: Support for peer's Admin service has been removed.

The peer's Admin service exposed APIs such as GetLogSpec() and SetLogSpec().
Instead of using these services, utilize the HTTP operations service that was
introduced in v1.4.0.

FAB-16303: GetHistoryForKey returns results from newest to oldest

In prior releases, the GetHistoryForKey chaincode API had no
guarantees on the order of returned results.
Starting in Fabric v2.0, the GetHistoryForKey chaincode API
will return results from newest to oldest in terms of ordered transaction
height (block height and transaction height within block).
This will allow applications to iterate through the top results
to understand recent changes to a key.

FAB-16722: The 'provisional' genesis method of generating the system channel
for orderers has been removed.

Existing users of the provisional genesis method
should instead set BootstrapMethod to 'file', and generate a genesis block file
using configtxgen. Orderer nodes will then use the generated file for the
orderer system channel.

FAB-16477 and FAB-17116: New configuration for orderer genesismethod and genesisfile

The orderer config general.genesismethod and general.genesisfile are replaced
by the new general.bootstrapmethod and general.bootstrapfile.

FAB-15343: System Chaincode Plugins have been removed.

As part of a general
move away from go plugins as an extension mechanism for Fabric, the ability to
add system chaincodes via go plugins has been removed. Users wishing to extend
Fabric with custom system chaincodes may rebuild the peer binary with the
system chaincode built into the binary. This system chaincode should then be
defined and initialized like any other user chaincode would be. This new model
is very similar to the plugin model (which required that the plugin to be built
at the same exact commit of Fabric), and addresses the significant shortcomings
around the lifecycle and validation of system chaincode transactions.

FAB-11096: Docker images with Alpine Linux

Hyperledger Fabric Docker images will now use Alpine Linux,
a security-oriented, lightweight Linux distribution.

FAB-11096: Bash not available in Docker images with Alpine Linux

Bash is no longer available in Fabric images. Utilize Alpine's built-in
sh or ash instead.

FAB-15499: Ledger data format upgrade

The Fabric ledger data structures use a more optimal and extensible
data format in v2.0. The peer node upgrade-dbs command must be run
on peers to upgrade them to the new v2.0 data format. See the upgrade
documentation for details.

FAB-16866: Chaincode built upon installation on peer

Chaincode images are now built when a chaincode is installed onto a peer,
rather than at instantiation time as in prior releases. The behavior is
common to both the prior chaincode lifecycle and new chaincode lifecycle.
Expect chaincode installation to take longer than in prior releases.
Chaincode installation may time out and return an error to the client, even
though the installation and chaincode image build may ultimately succeed on
the peer.

FAB-15837: Orderer FileLedger location moved if specified with relative path

If FileLedger is specified with a relative path, it will be relative to the
config file, instead of where the binary is being executed.

FAB-14271: Policies must be specified in configtx.yaml

In Fabric v1.x configtxgen would create default policies if they were omitted
in configtx.yaml, but this behavior was deprecated in v1.2. In v2.0, configtxgen
no longer creates default policies, and they must be explicitly defined in configtx.yaml.

FAB-17000: Warn when certificates are about to expire

This change set adds a warning to the peer and orderer
that logs a warning a week before the enrollment certificate
or the server (client) TLS certificate expires.

FAB-16987: Go version has been updated to 1.13.4.

Deprecations

FAB-15754: The 'Solo' consensus type is deprecated.

The 'Solo' consensus type has always been marked non-production and should be in
use only in test environments, however for compatibility it is still available,
but may be removed entirely in a future release.

FAB-16408: The 'Kafka' consensus type is deprecated.

The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
production consensus type. There is a documented and tested migration path from
Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
For compatibility with existing deployments, Kafka is still supported,
but may be removed entirely in a future release.

FAB-7559: Support for specifying orderer endpoints at the global level
in channel configuration is deprecated.

Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
Configuring orderer endpoints at the organization level accommodates
scenarios where orderers are run by different organizations. Using
this configuration ensures that only the TLS CA certificates of that organization
are used for orderer communications, in contrast to the global channel level endpoints which
would cause an aggregation of all orderer TLS CA certificates across
all orderer organizations to be used for ord...