1 Star 2 Fork 0

王林/fabric

标签名
描述
提交信息
操作

v1.4.4 Release Notes - November 14, 2019

What's New in Hyperledger Fabric v1.4.4

The following enhancements are included in this release:

  • FAB-16715, FAB-16544: Orderer endpoint override

    Ordering networks whose addresses or TLS root certificates change will cause problems for new
    peers joining channels because the channel genesis block will contain the outdated orderer
    information. A new configuration option for orderer endpoint overrides allows administrators
    to configure peers to translate old orderer addresses and certificates to the updated
    orderer addresses and certificate pools.

  • FAB-17000: Provide notification to users if certs are about to expire

    Peers and orderers now log a warning to the log a week before the enrollment certificate or
    TLS certificate expire. Example log entries:

    [certmonitor] trackCertExpiration -> WARN 011 The server TLS certificate expires within one week

    [certmonitor] trackCertExpiration -> WARN 011 The enrollment certificate expires within 2 days and 5 hours

  • FAB-15814: Add operations endpoint to expose peer/orderer version

    Adds a /version endpoint to the operations server that serves peer/orderer metadata
    including Version number and CommitSHA.

  • FAB-16852 Bump to Go v1.12.12 and baseimage 0.4.18

  • FABB-128 Bump node.js to 8.16.1 and npm to 6.11.3 in 0.4.18 baseimage

Fixes

  • FAB-13552: Re-addition of a removed OSN in a channel - Prior to the fix, if a Raft orderer was
    removed from the consenter set in the channel configuration, it would not check to see if was added
    back and a reboot was required.

  • FAB-15026: Segmentation violation in peer chaincode install - Prior to the fix, the tar processing
    during chaincode package install could trigger a panic while looking up user info when run with
    certain versions of libc. The calls to libc are no longer made.

  • FAB-15389: Endorsing peer is not honoring maxPeerCount for private data dissemination - Prior
    to the fix, there was a chance that peers chosen for private data dissemination at endorsement time
    could potentially be counted twice towards maxPeerCount, leading to disseminating private data to
    fewer peers than expected.

  • FAB-15666: NetworkMode does not get passed to chaincode image build
    Prior to the fix, the peer's configured docker NetworkMode was not getting passed
    upon chaincode image build.

  • FAB-16571: Fix panic in peer chaincode package command - Prior to the fix, the peer
    chaincode package command could panic when traversing the chaincode location.

  • FAB-16610: Commit block to ledger hang when chaincode crash - Prior to the fix, if a chaincode
    terminated abnormally during an invocation, a lock would prevent blocks from committing until the
    execution timeout (core.chaincode.executetimeout property) was triggered. The fix ensures that the
    lock is released immediately on exit.

  • FAB-16643: Nil pointer during reconciliation of deleted private data - Prior to the fix,
    if a peer is trying to reconcile missing private data, and the private data key has since been
    deleted, the peer will panic with a nil pointer exception.

  • FAB-16651: Fix connection leak if certificates renewed - Prior to the fix, peers that have changed
    their enrollment certificate without changing their endpoint caused connections to leak over time.

  • FAB-16695: Separate listeners causes panic - Prior to the fix, configuring separate
    listeners for the peer admin service or for the orderer cluster service would cause a
    panic on startup if Prometheus metrics were enabled.

  • FAB-16948: Nil pointer exception in CID GetID() when using Idemix - GetID now returns an error
    when invoked on a chaincode request from an Idemix identity.

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#v144

2019-11-13 20:45

v1.4.3 Release Notes - August 26, 2019

What's New in Hyperledger Fabric v1.4.3

The following features are included in this release:

FAB-15388: Node OU certificate support for admin identities.
FAB-12620: Node OU certificate support for orderer nodes.

Node OUs are now supported for admin and orderer identity
classifications (extending the existing Node OU support for clients and peers).
These "organizational units" allow organizations to further classify identities
into admins and orderers based on the OUs specified in their x509 certificates.
This feature requires v1.4.3 'channel' capability to be enabled so that all
orderer and peer nodes identify administrators consistently.
Peers need to be updated to version v1.4.3 before channel administrators
update a channel to v1.4.3 channel capability.
Organizations that wish to take advantage of the new capability
will need to update their MSP information in the channel configuration.
For more details see:
https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html#identity-classification

Important Fixes

FAB-16292 Fix nil pointer exception upon gossip peer expiration

There was an issue introduced in v1.4.2 where peers participating in channels with
gossip enabled may crash with a nil pointer exception, if another known peer goes down
for several minutes (when using default aliveExpirationTimeout peer configuration
of 25 seconds). To work around the problem on v1.4.2, automatically restart
the peer process if it goes down, or configure a large value for aliveExpirationTimeout
(peer environment variable CORE_PEER_GOSSIP_ALIVEEXPIRATIONTIMEOUT) to completely
avoid the problem until peer can be upgraded to v1.4.3.

FAB-16114 - v1.4.2 private data application capability enablement requires peer restart

Prior to the fix, enablement of the v1.4.2 application capability required
a peer restart to become effective. Since the v1.4.2 application capability
changes how peers disseminate private data for invalid transactions, peers
that have not been restarted after the application capability has been
updated on the channel may not disseminate the data to peers that are
attempting to pull the private data upon block commit. The pulling peers
may therefore get stalled while pulling private data.
The remedy on v1.4.2 requires restarting any peer that participates
in private data dissemination, after v1.4.2 application
capability has been enabled on a channel.
Starting in v1.4.3, the application channel capability becomes effective upon
processing the configuration block update, without requiring a peer restart.

FAB-16327 Fix service discovery with orderer endpoints configured at organization level

v1.4.2 introduced orderer endpoint configuration at the organization level
('OrdererEndpoints' stanza). Prior to the fix, if orderer endpoints are configured
only at the new organization level, and not at the global 'Orderer.Addresses'
level, then service discovery is not able return the channel configuration with the
orderer endpoints.
With the v1.4.3 fix, service discovery functions correctly even if orderer endpoints
are configured only at the organization level.

FAB-16089 Use latest npm version of ccenv image

In the ccenv image that is used to build node.js chaincode, npm is updated to
the latest version. This resolves issues from prior npm versions, such as
the ability to include 'prepare' statements in node.js chaincode
package.json.

Changes, Known Issues, and Workarounds

FAB-12088 - Java chaincode support on s390x architecture
Java chaincode support is not available on s390x architecture.

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.

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

2019-08-27 03:07

v1.4.2 Release Notes - July 17, 2019

What's New in Hyperledger Fabric v1.4.2

The following features are included in this release:

FAB-15041 - Kafka to Raft Consensus Migration
A Kafka-based ordering service can now be migrated to utilize Raft consensus.
For details see the documentation at
https://hyperledger-fabric.readthedocs.io/en/latest/kafka_raft_migration.html.
This feature requires v1.4.2 'orderer' and 'channel' capabilities to be
enabled.

FAB-14307 Channel rollback on a peer
The new 'peer node rollback' command provides
administrative ability to rollback a channel's ledger on a peer to a prior
block height in the case a peer's channel data gets into a corrupt state at a
later block height. The peer will re-retrieve the rolled back blocks from
ordering service or another peer upon the next peer start. Note that during
the rollback, the ledger's private data will be preserved, since it cannot
be obtained from ordering service at a later time, and may not be available
from other peers.
Similarly, the command 'peer node reset' command can be used to rollback
all of a peer's channel ledgers to the genesis block of each channel.
Both commands must be issued from the peer's CLI while the peer process
is down.
It is recommended to enable v1.4.2 'application' capability to ensure that all
private data is stored on the local peer (including for invalidated transactions),
in case rollback and reprocessing is required on a peer.

FAB-7559 - Ability to specify orderer endpoints at the organization level
Starting from version v1.4.2, it is possible and highly recommended to define
orderer endpoints at the organization level (new 'OrdererEndpoints' stanza
within the channel configuration of an organization) and not at the global
'Orderer.Addresses' section of channel configuration. If at least one
organization has an ordering service endpoint defined at an organizational
level, all orderers and peers will ignore the channel level endpoints when
connecting to ordering nodes.
Utilizing organization level orderer endpoints is required when using
service discovery with orderer nodes provided by multiple organizations,
so that clients can provide the correct organization TLS certificates.
This feature requires v1.4.2 'channel' capability to be
enabled.

Important Fixes

FAB-15450 - History database queries do not return all results
Prior to the fix, history database queries excluded transactions from
blocks that were multiples of 256 (block 256, 512, 768, etc).

FAB-15411 - GetTransactionByID does not return configuration transactions
Prior to the fix, GetTransactionByID and GetBlockByTxID did not return
configuration transactions, since these transactions were not indexed
correctly. To fix indexes for pre-existing configuration transactions
on a peer's channel ledgers, stop the peer and delete the index directory,
e.g. /var/hyperledger/production/ledgersData/chains/index directory.
The peer will rebuild the indexes correctly upon the next restart.

FAB-15404 - Orderer Kafka TLS Issue
Prior to the fix, orderer nodes could not communicate to kafka if
TLS is enabled.

FAB-15144 - Assorted orderer serviceability fixes

Changes, Known Issues, and Workarounds

FAB-15031 - ledger.blockstorage_commit_time metric is available on orderer nodes
ledger.blockstorage_commit_time is now available on both peer and orderer nodes,
but only includes block storage commit time. A new metric,
ledger_blockstorage_and_pvtdata_commit_time, is available on peer nodes and
includes the total commit time for blockstorage and pvtdata.

FAB-15549 - Restrict service discovery endorsement computation
If the endorsement policy contains an NoutOf that yields too many combinations
(such as - 13 out of 25), service discovery will not return all possible
combinations to the application (as that number can be huge), but instead will
return a random subset of endorsement combinations.

FAB-12088 - Java chaincode support on s390x architecture
Java chaincode support is not available on s390x architecture.

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.

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

2019-07-18 02:18

v1.4.1 Release Notes - April 11, 2019

What's New in Hyperledger Fabric v1.4.1

The following features are included in this release:

FAB-6135 - Raft Consensus
The ordering service now provides an option to use the Raft Consensus
algorithm.
See https://raft.github.io/ for details on the Raft algorithm.

Additional operational metrics and health checks
FAB-13088 Endorser metrics
FAB-14077 Orderer communication metrics
FAB-11937 Raft metrics
FAB-13237 Metrics for log records
FAB-13341 Kafka health check
FAB-12908 CouchDB health check

Changes, Known Issues, and Workarounds

FAB-14723 - Deprecate CAR package format
Support for packaging chaincode using the CAR format will be removed in
v2.0.0.

FAB-12088 - Java chaincode support on s390x architecture
Java chaincode support is not yet available on s390x architecture.

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.

Other noteworthy improvements and fixes

FAB-14420 - Allow statically configured CAs for TLS communication with orderers
FAB-13471 - Fix for multiple chaincode upgrades in a single block
FAB-14687 - Fix memory leak in gossip message store

Updated to Go version 1.11.5
Updated baseimage version to 0.4.15

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

2019-04-11 20:03

v2.0.0-alpha Release Notes - April 9, 2019

What's New in Hyperledger Fabric v2.0

The following major features are included in the v2.0.0 Alpha release:

FAB-11237 - Improved chaincode lifecycle
The Fabric 2.0 Alpha introduces decentralized governance for chaincode, 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.

FAB-11144 - Native token support
The Fabric 2.0 Alpha provides users the ability to easily represent assets
as tokens on Fabric channels. FabToken is a token management system that uses
an Unspent Transaction Output (UTXO) model to issue, transfer, and redeem tokens
using the identity and membership infrastructure provided by Hyperledger Fabric.
A new 'token' command line interface is included as a way to drive token transactions
without an application.

FAB-6135 - Raft Consensus
Introduced in v1.4.1 and v2.0.0 Alpha, the ordering service now provides
an option to use the Raft Consensus algorithm. Raft is a crash fault tolerant
(CFT) ordering service based on an implementation of Raft protocol in etcd.

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

New operational metrics and health checks
FAB-13088 Endorser metrics
FAB-14077 Orderer communication metrics
FAB-11937 Raft metrics
FAB-13237 Metrics for log records
FAB-12727 Gossip metrics
FAB-13341 Kafka health check
FAB-12908 CouchDB health check

Changes, Known Issues, and Workarounds

FAB-11237 - Improved chaincode lifecycle
The new Fabric chaincode lifecycle in the v2.0.0 Alpha release is not yet feature
complete. Specifically, be aware of the following limitations in the Alpha release:

  • CouchDB indexes are not yet supported
  • Chaincodes defined with the new lifecycle are not yet discoverable via service discovery
    These limitations will be resolved after the Alpha release.

FAB-11096 - Docker images with Alpine Linux
Bash is no longer available in Fabric images. Utilize Alpine's built-in
sh or ash instead.

FAB-12075 - Duplicate Go Client identity library removed
If vendoring the Client identity library (CID) in chaincode, import
github.com/hyperledger/fabric/core/chaincode/shim/ext/cid
rather than
github.com/hyperledger/fabriccore/chaincode/lib/cid/cid.go

FAB-12088 - Java chaincode support on s390x architecture
Java chaincode support is not yet available on s390x architecture.

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.

Other improvements and fixes

FAB-13471 - Fix for multiple chaincode upgrades in a single block
FAB-14687 - Fix memory leak in gossip message store
Updated to Go version 1.11.5
Updated baseimage version to 0.4.15 for third party dependencies.

For the full list of improvements and fixes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v200-alpha

2019-04-09 22:26

v1.4.1-rc1 Release Notes - March 29, 2019

What's New in Hyperledger Fabric v1.4.1

The following features are included in this release:

FAB-6135 - Raft Consensus
The ordering service now provides an option to use the Raft Consensus
algorithm.
See https://raft.github.io/ for details on the Raft algorithm.

Additional operational metrics and health checks
FAB-13088 Endorser metrics
FAB-14077 Orderer communication metrics
FAB-11937 Raft metrics
FAB-13237 Metrics for log records
FAB-13341 Kafka health check
FAB-12908 CouchDB health check

Changes, Known Issues, and Workarounds

FAB-14723 - Deprecate CAR package format
Support for packaging chaincode using the CAR format will be removed in
v2.0.0.

FAB-12088 - Java chaincode support on s390 architecture
Java chaincode support is not yet available on s390 architecture.

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.

Other noteworthy improvements and fixes

FAB-14420 - Allow statically configured CAs for TLS communication with orderers
FAB-13471 - Fix for multiple chaincode upgrades in a single block
FAB-14687 - Fix memory leak in gossip message store

Updated to Go version 1.11.5
Updated baseimage version to 0.4.15

For the full list of improvements and fixes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/release-1.4/CHANGELOG.md#v141-rc1

2019-03-30 05:10

v1.4.0 Release Notes - January 9, 2019

What's New in Hyperledger Fabric v1.4

The following features are included in this release:

Fabric operations service
A new HTTP based "operations" endpoint has been implemented on the orderer and
the peer. The endpoint exposes APIs to check the server's health, to query
and modify the logging level of the process, and, when configured, to expose
Fabric metrics.

FAB-3388 - Operational metrics for Fabric components
The peer and orderer have been instrumented to provide basic operational
metrics. The metrics can be surfaced for consumption by Prometheus or StatsD.

FAB-10851 - Health check endpoint
The orderer and the peer now provide a mechanism to check the health of the
process via an HTTP request. Requests to GET /healthz on the operations
endpoint will complete with a status 200 OK when the server believes it is
healthy. When a health check fails, the server will respond with a 503 Service
Unavailable and a JSON payload indicating which component detected an issue.
The types of health checks that are performed will be extended over time.

FAB-12265 - Dynamic log levels
The orderer and the peer now provide a mechanism to get and update the active
logging specification of the server. Requests to GET /logspec on the
operations endpoint will return with a JSON payload that contains the active
spec. When a JSON payload of {"spec":"the-log-spec"} is sent as the body of
a PUT /logspec request, the active logging spec will be updated.

FAB-12357 - Updates to logging
In earlier versions of Fabric, loggers were associated with named components
and configuration would control the active level of each logger. While this
model works in theory, because of the configuration management libraries used
by Fabric and the structure of the Fabric code base, in practice it had a
number of issues.
With 1.4, we're changing the model slightly. Instead of associating loggers
with components, we are naming loggers and to help avoid side effects during
initialization, the logging configuration is no longer obtained from the
fabric configuration system but from environment variables that define
the logging specification and log format.
The log specification is a single string that consists of colon separated
tokens. Each token declares one or more logger name prefixes (separated by
commas) and an optional log level. When the logger name prefix ends with a
period, it indicates that the log level should only apply to the logger with
that exact name without the trailing period. When the logger name pattern is
omitted, it specifies the default log level. In cases where multiple entries
reference the same name pattern or multiple instances of a default are
provided, the last specification takes precedence.

FAB-12363 - Logging for gRPC interactions
The orderer and the peer now provide logging (INFO level) for each gRPC
interaction completed.

FAB-12372 - Obtain Go routine stacks without termination
When SIGUSR1 is received by the peer or the orderer, the state of all go
routines will be captured and logged at the INFO level. This collection
activity will not terminate the process.

FAB-5093 - Private data reconciliation
Allows peers for organizations that are added to private data collections
to retrieve the private data for prior transactions to which they now are
entitled. This feature is only supported on peers that have joined
a channel since v1.4.

FAB-11409 - Private data client access control
Ability to automatically enforce access control within chaincode based
on the client organization collection membership without having to
write specific chaincode logic. This feature is configured by using
the collection configuration property memberOnlyRead:true. If you have
a mixed network of v1.4 peers and prior release peers, the prior
release peers will not honor this configuration until they are upgraded
to v1.4.

Changes, Known Issues, and Workarounds

FAB-12357 - Updates to logging
Instead of using logging.level and CORE_LOGGING_LEVEL to control the logging
level for the peer, and General.LogLevel or ORDERER_GENERAL_LOGLEVEL to
control logging at the orderer, both processes now use the FABRIC_LOGGING_SPEC
environment variable to acquire the initial logging specification for the
server. Existing logging configuration should be converted to the new model.

FAB-12489 - peer logging command updates
The getlevel, setlevel, and revertlevels subcommands of the peer logging command are deprecated and users should migrate to the operations
server.
The behavior of setlevel has also changed slightly. The previous
implementation would treat the logger argument as a regular expression and
apply the new log level to all loggers that matched the expression. The
updated implementation treats the logger argument as a logger name and
appends it to the active logging spec at the indicated level.

FAB-12088 - Java chaincode support on s390 architecture
Java chaincode support is not yet available on s390 architecture.

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.

Other improvements and fixes

Updated to Go version 1.11.1
Updated baseimage version to 0.4.14

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

2019-01-09 23:47

v1.4.0-rc2 Release Notes - December 20, 2018

What's New in Hyperledger Fabric v1.4

The following features are included in this release:

Fabric operations service
A new HTTP based "operations" endpoint has been implemented on the orderer and
the peer. The endpoint exposes APIs to check the server's health, to query
and modify the logging level of the process, and, when configured, to expose
Fabric metrics.

FAB-3388 - Operational metrics for Fabric components
The peer and orderer have been instrumented to provide basic operational
metrics. The metrics can be surfaced for consumption by Prometheus or StatsD.

FAB-10851 - Health check endpoint
The orderer and the peer now provide a mechanism to check the health of the
process via an HTTP request. Requests to GET /healthz on the operations
endpoint will complete with a status 200 OK when the server believes it is
healthy. When a health check fails, the server will respond with a 503 Service
Unavailable and a JSON payload indicating which component detected an issue.
The types of health checks that are performed will be extended over time.

FAB-12265 - Dynamic log levels
The orderer and the peer now provide a mechanism to get and update the active
logging specification of the server. Requests to GET /logspec on the
operations endpoint will return with a JSON payload that contains the active
spec. When a JSON payload of {"spec":"the-log-spec"} is sent as the body of
a PUT /logspec request, the active logging spec will be updated.

FAB-12357 - Updates to logging
In earlier versions of Fabric, loggers were associated with named components
and configuration would control the active level of each logger. While this
model works in theory, because of the configuration management libraries used
by Fabric and the structure of the Fabric code base, in practice it had a
number of issues.
With 1.4, we're changing the model slightly. Instead of associating loggers
with components, we are naming loggers and to help avoid side effects during
initialization, the logging configuration is no longer obtained from the
fabric configuration system but from environment variables that define
the logging specification and log format.
The log specification is a single string that consists of colon separated
tokens. Each token declares one or more logger name prefixes (separated by
commas) and an optional log level. When the logger name prefix ends with a
period, it indicates that the log level should only apply to the logger with
that exact name without the trailing period. When the logger name pattern is
omitted, it specifies the default log level. In cases where multiple entries
reference the same name pattern or multiple instances of a default are
provided, the last specification takes precedence.

FAB-12363 - Logging for gRPC interactions
The orderer and the peer now provide logging (INFO level) for each gRPC
interaction completed.

FAB-12372 - Obtain Go routine stacks without termination
When SIGUSR1 is received by the peer or the orderer, the state of all go
routines will be captured and logged at the INFO level. This collection
activity will not terminate the process.

FAB-5093 - Private data reconciliation
Allows peers for organizations that are added to private data collections
to retrieve the private data for prior transactions to which they now are
entitled. This feature is only supported on peers that have joined
a channel since v1.4.

FAB-11409 - Private data client access control
Ability to automatically enforce access control within chaincode based
on the client organization collection membership without having to
write specific chaincode logic. This feature is configured by using
the collection configuration property memberOnlyRead:true. If you have
a mixed network of v1.4 peers and prior release peers, the prior
release peers will not honor this configuration until they are upgraded
to v1.4.

Changes, Known Issues, and Workarounds

FAB-12357 - Updates to logging
Instead of using logging.level and CORE_LOGGING_LEVEL to control the logging
level for the peer, and General.LogLevel or ORDERER_GENERAL_LOGLEVEL to
control logging at the orderer, both processes now use the FABRIC_LOGGING_SPEC
environment variable to acquire the initial logging specification for the
server. Existing logging configuration should be converted to the new model.

FAB-12489 - peer logging command updates
The getlevel, setlevel, and revertlevels subcommands of the peer logging command are deprecated and users should migrate to the operations
server.
The behavior of setlevel has also changed slightly. The previous
implementation would treat the logger argument as a regular expression and
apply the new log level to all loggers that matched the expression. The
updated implementation treats the logger argument as a logger name and
appends it to the active logging spec at the indicated level.

FAB-12088 - Java chaincode support on s390 architecture
Java chaincode support is not yet available on s390 architecture.

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.

Other improvements and fixes

Updated to Go version 1.11.1
Updated baseimage version to 0.4.14

For the full list of improvements and fixes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v140-rc2

2018-12-20 22:01

v1.4.0-rc1 Release Notes - December 10, 2018

What's New in Hyperledger Fabric v1.4

The following features are included in this release:

Fabric operations service
A new HTTP based "operations" endpoint has been implemented on the orderer and
the peer. The endpoint exposes APIs to check the server's health, to query
and modify the logging level of the process, and, when configured, to expose
Fabric metrics.

FAB-3388 - Operational metrics for Fabric components
The peer and orderer have been instrumented to provide basic operational
metrics. The metrics can be surfaced for consumption by Prometheus or StatsD.

FAB-10851 - Health check endpoint
The orderer and the peer now provide a mechanism to check the health of the
process via an HTTP request. Requests to GET /healthz on the operations
endpoint will complete with a status 200 OK when the server believes it is
healthy. When a health check fails, the server will respond with a 503 Service
Unavailable and a JSON payload indicating which component detected an issue.
The types of health checks that are performed will be extended over time.

FAB-12265 - Dynamic log levels
The orderer and the peer now provide a mechanism to get and update the active
logging specification of the server. Requests to GET /logspec on the
operations endpoint will return with a JSON payload that contains the active
spec. When a JSON payload of {"spec":"the-log-spec"} is sent as the body of
a PUT /logspec request, the active logging spec will be updated.

FAB-12357 - Updates to logging
In earlier versions of Fabric, loggers were associated with named components
and configuration would control the active level of each logger. While this
model works in theory, because of the configuration management libraries used
by Fabric and the structure of the Fabric code base, in practice it had a
number of issues.
With 1.4, we're changing the model slightly. Instead of associating loggers
with components, we are naming loggers and to help avoid side effects during
initialization, the logging configuration is no longer obtained from the
fabric configuration system but from environment variables that define
the logging specification and log format.
The log specification is a single string that consists of colon separated
tokens. Each token declares one or more logger name prefixes (separated by
commas) and an optional log level. When the logger name prefix ends with a
period, it indicates that the log level should only apply to the logger with
that exact name without the trailing period. When the logger name pattern is
omitted, it specifies the default log level. In cases where multiple entries
reference the same name pattern or multiple instances of a default are
provided, the last specification takes precedence.

FAB-12363 - Logging for gRPC interactions
The orderer and the peer now provide logging (INFO level) for each gRPC
interaction completed.

FAB-12372 - Obtain Go routine stacks without termination
When SIGUSR1 is received by the peer or the orderer, the state of all go
routines will be captured and logged at the INFO level. This collection
activity will not terminate the process.

FAB-5093 - Private data reconciliation
Allows peers for organizations that are added to private data collections
to retrieve the private data for prior transactions to which they now are
entitled. This feature is only supported on peers that have joined
a channel since v1.4.

FAB-11409 - Private data client access control
Ability to automatically enforce access control within chaincode based
on the client organization collection membership without having to
write specific chaincode logic. This feature is configured by using
the collection configuration property memberOnlyRead:true. If you have
a mixed network of v1.4 peers and prior release peers, the prior
release peers will not honor this configuration until they are upgraded
to v1.4.

Changes, Known Issues, and Workarounds

FAB-12357 - Updates to logging
Instead of using logging.level and CORE_LOGGING_LEVEL to control the logging
level for the peer, and General.LogLevel or ORDERER_GENERAL_LOGLEVEL to
control logging at the orderer, both processes now use the FABRIC_LOGGING_SPEC
environment variable to acquire the initial logging specification for the
server. Existing logging configuration should be converted to the new model.

FAB-12489 - peer logging command updates
The getlevel, setlevel, and revertlevels subcommands of the peer logging command are deprecated and users should migrate to the operations
server.
The behavior of setlevel has also changed slightly. The previous
implementation would treat the logger argument as a regular expression and
apply the new log level to all loggers that matched the expression. The
updated implementation treats the logger argument as a logger name and
appends it to the active logging spec at the indicated level.

FAB-12088 - Java chaincode support on s390 architecture
Java chaincode support is not yet available on s390 architecture.

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.

Other improvements and fixes

Updated to Go version 1.11.1
Updated baseimage version to 0.4.14

For the full list of improvements and fixes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v140-rc1

2018-12-11 02:10

v1.3.0 Release Notes - October 10, 2018

What's New in Hyperledger Fabric v1.3

The following features/epics are included in this release:

FAB-10120 - Identity Mixer for anonymous transactions
Keep client identities anonymous and unlinkable through the use of
zero-knowledge proofs.

FAB-8812 - State-based endorsement
Allows the default chaincode-level endorsement policy to be overridden by a
per-key endorsement policy.

FAB-2809 - Chaincode pagination of query results
Clients can now page through result sets from chaincode queries, making it
feasible to support large result sets with high performance.

FAB-8779 - Java chaincode support
As an addition to the current Fabric support for chaincode written in Go and
Node.js, Java is now supported.

Changes, Known Issues, and Workarounds

FAB-11122 - Removal of event hub

The 'old' event hub has been removed in Hyperledger Fabric v1.3. It is
replaced by the peer channel-based event service which was introduced in
Fabric v1.1.
Applications using the old event hub must switch over to the new
channel-based event service before upgrading to v1.3 peer or SDKs.

FAB-12088 - Java chaincode support on s390 architecture

Java chaincode support is not yet available on s390 architecture.

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.

Other improvements and fixes

Updated to Go version 1.10.4
Updated baseimage version to 0.4.13

For the full list of improvements and fixes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v130

2018-10-10 15:44
2018-09-28 02:33

v1.3.0-rc1 Release Notes - September 24, 2018

What's New in Hyperledger Fabric v1.3

The following features/epics are included in this release:

FAB-10120 - Identity Mixer for anonymous transactions
Keep client identities anonymous and unlinkable through the use of
zero-knowledge proofs.

FAB-8812 - State-based endorsement
Allows the default chaincode-level endorsement policy to be overridden by a
per-key endorsement policy.

FAB-2809 - Chaincode pagination of query results
Clients can now page through result sets from chaincode queries, making it
feasible to support large result sets with high performance.

FAB-8779 - Java chaincode support
As an addition to the current Fabric support for chaincode written in Go and
Node.js, Java is now supported.

Changes, Known Issues, and Workarounds

FAB-11122 - Removal of event hub

The 'old' event hub has been removed in Hyperledger Fabric v1.3. It is
replaced by the peer channel-based event service which was introduced in
Fabric v1.1.
Applications using the old event hub must switch over to the new
channel-based event service before upgrading to v1.3 peer or SDKs.

FAB-12088 - Java chaincode support on s390 architecture

Java chaincode support is not yet available on s390 architecture.

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.

Other improvements and fixes

Updated to Go version 1.10.4
Updated baseimage version to 0.4.12

For the full list of improvements and fixes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v130-rc1

2018-09-25 22:54

v1.1.1 July 5, 2018

Release Notes

Bug fixes, documentation and test coverage improvements, UX improvements
based on user feedback and changes to address a variety of static scan
findings (unused code, static security scanning, spelling, linting and more).

Known Vulnerabilities

none

Resolved Vulnerabilities

https://jira.hyperledger.org/browse/FAB-10537
https://jira.hyperledger.org/browse/FAB-10577

Known Issues & Workarounds

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.

Please refer to https://jira.hyperledger.org/browse/FAB-5177 for more details,
and kindly be aware that given the above, we may end up changing the
fabric-ccenv in the future.

Change Log

https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v111

2018-07-08 20:26

v1.2.0 Release Notes - July 3, 2018

What's New in v1.2

The following features/epics are included in this release:

FAB-8718 - Channel Private Data
Keep chaincode data confidential among a subset of channel members.

FAB-8727 - Access control for peer functions
Configure which client identities can interact with peer functions, per channel.

FAB-8729 - Pluggable endorsement and validation
Utilize pluggable endorsement and validation logic per chaincode.

FAB-8779 - Service Discovery
Discover network services dynamically, including orderers, peers, chaincode,
and endorsement policies, to simplify client applications.

Hygiene and Technical debt
Ginkgo-based integration tests have been added, and component code has been
refactored for improved readability and maintainability.

Changes, Known Issues, and Workarounds

FAB-10151 - configtx.yaml samples fixed

Previous releases included example input files for configtxgen (configtx.yaml)
that contained invalid YAML which referenced YAML anchors before they were
defined. It was not a problem in prior releases since the golang YAML parser
tolerated references before definitions.
The configtx.yaml samples are corrected in version v1.2. Users are advised
to evaluate their configtxgen input documents for places where YAML anchors
are referenced before they are defined. Either reorder nodes to ensure
anchors are defined before they are referenced, or re-create YAML documents
using the updated configtx.yaml sample documents as a starting point.
Refer to https://jira.hyperledger.org/browse/FAB-10151 for more details.

FAB-8557 - Transaction index and query behavior changed

There is a change to how some of the indexes maintained by ledger are updated.
Specifically, this includes indexes that maintain information by txid. In the rare
scenario when two transactions were submitted with the same transaction ids,
in the previous releases, the last transaction would be indexed. Only the first
instance of a transaction can be valid, therefore it was possible for an invalid
transaction to overwrite the status of a valid transaction, and therefore APIs
such as 'GetTransactionByID' and 'GetBlockByTxID' may return the latter invalid
transaction. In these cases the ledger remained correct, however transaction
queries may have returned unexpected results.
In this release, the behavior is changed so that the first transaction (the only
instance that can be valid) will not be overwritten in the index.
In the rare scenario where this problem has occurred on a channel, the peer's
transaction index can be rebuilt after upgrading to version v1.2, by stopping the
peer, deleting the <CORE_PEER_FILESYSTEMPATH>/ledgersData/chains/index directory,
and restarting the peer. The peer will automatically rebuild its indexes
using the new behavior.
Refer to https://jira.hyperledger.org/browse/FAB-8557 for more details.

FAB-8877 - Reserved field validation for CouchDB state database

Prior releases did not validate chaincode data against all state database
content restrictions. Specifically, version v1.2 adds validation during
chaincode execution to ensure that keys that will be written to CouchDB
state database are UTF8 complaint, do not start with an underscore, and
that there are no top-level JSON fields named '~version' or that start with
underscores, as these fields are reserved for use by CouchDB (and Fabric).
If these conditions are found during chaincode execution, an error will
be returned to the client in the proposal response.
For the same reason, all peers on a channel must utilize the same state
database type, and it is not possible to convert a channel's peers from
using LevelDB state database to CouchDB state database, unless the
chaincode performs the same validations.
Refer to https://jira.hyperledger.org/browse/FAB-8877 for more details.

Known Vulnerabilities

FAB-8664 - Peer does not detect his own org ejection
This is a relatively low severity problem, because it requires a significant
conspiracy of network admins, but it will be addressed in an upcoming release.

Resolved Vulnerabilities

FAB-10537 - Reject CONFIG/ORDERER_TRANSACTION messages
Ensures that clients cannot submit transactions intended to be generated
from orderer nodes.

Other improvements and fixes

For the full list of improvements and fixes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v120

2018-07-03 21:41

v1.2.0-rc1 Release Notes - June 22, 2018

What's New in v1.2

The following features/epics are included in this release:

FAB-8718 - Channel Private Data
Keep chaincode data confidential among a subset of channel members.

FAB-8727 - Access control for peer functions
Configure which client identities can interact with peer functions, per channel.

FAB-8729 - Pluggable endorsement and validation
Utilize pluggable endorsement and validation logic per chaincode.

FAB-8779 - Service Discovery
Discover network services dynamically, including orderers, peers, chaincode,
and endorsement policies, to simplify client applications.

Hygiene and Technical debt
Ginkgo-based integration tests have been added, and component code has been
refactored for improved readability and maintainability.

Changes, Known Issues, and Workarounds

FAB-10151 - configtx.yaml samples fixed

Previous releases included example input files for configtxgen (configtx.yaml)
that contained invalid YAML which referenced YAML anchors before they were
defined. It was not a problem in prior releases since the golang YAML parser
tolerated references before definitions.
The configtx.yaml samples are corrected in version v1.2. Users are advised
to evaluate their configtxgen input documents for places where YAML anchors
are referenced before they are defined. Either reorder nodes to ensure
anchors are defined before they are referenced, or re-create YAML documents
using the updated configtx.yaml sample documents as a starting point.
Refer to https://jira.hyperledger.org/browse/FAB-10151 for more details.

FAB-8557 - Transaction index and query behavior changed

There is a change to how some of the indexes maintained by ledger are updated.
Specifically, this includes indexes that maintain information by txid. In the rare
scenario when two transactions were submitted with the same transaction ids,
in the previous releases, the last transaction would be indexed. Only the first
instance of a transaction can be valid, therefore it was possible for an invalid
transaction to overwrite the status of a valid transaction, and therefore APIs
such as 'GetTransactionByID' and 'GetBlockByTxID' may return the latter invalid
transaction. In these cases the ledger remained correct, however transaction
queries may have returned unexpected results.
In this release, the behavior is changed so that the first transaction (the only
instance that can be valid) will not be overwritten in the index.
In the rare scenario where this problem has occurred on a channel, the peer's
transaction index can be rebuilt after upgrading to version v1.2, by stopping the
peer, deleting the <CORE_PEER_FILESYSTEMPATH>/ledgersData/chains/index directory,
and restarting the peer. The peer will automatically rebuild its indexes
using the new behavior.
Refer to https://jira.hyperledger.org/browse/FAB-8557 for more details.

FAB-8877 - Reserved field validation for CouchDB state database

Prior releases did not validate chaincode data against all state database
content restrictions. Specifically, version v1.2 adds validation during
chaincode execution to ensure that keys that will be written to CouchDB
state database are UTF8 complaint, do not start with an underscore, and
that there are no top-level JSON fields named '~version' or that start with
underscores, as these fields are reserved for use by CouchDB (and Fabric).
If these conditions are found during chaincode execution, an error will
be returned to the client in the proposal response.
For the same reason, all peers on a channel must utilize the same state
database type, and it is not possible to convert a channel's peers from
using LevelDB state database to CouchDB state database, unless the
chaincode performs the same validations.
Refer to https://jira.hyperledger.org/browse/FAB-8877 for more details.

Known Vulnerabilities

FAB-8664 - Peer does not detect his own org ejection
This is a relatively low severity problem, because it requires a significant
conspiracy of network admins, but it will be addressed in an upcoming release.

Resolved Vulnerabilities

FAB-10537 - Reject CONFIG/ORDERER_TRANSACTION messages
Ensures that clients cannot submit transactions intended to be generated
from orderer nodes.

Other improvements and fixes

For the full list of improvements and fixes, refer to the release change log:
https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v120-rc1

2018-06-22 20:48

v1.1.0 March 15, 2018

Release Notes

The v1.1 release includes all of the features delivered in v1.1.0-preview
and v1.1.0-alpha.

Additionally, there are feature improvements, bug fixes, documentation and test
coverage improvements, UX improvements based on user feedback and changes to address a
variety of static scan findings (unused code, static security scanning, spelling,
linting and more).

Updated to Go version 1.9.2.
Updated baseimage version to 0.4.6.

Known Vulnerabilities

none

Resolved Vulnerabilities

https://jira.hyperledger.org/browse/FAB-4824
https://jira.hyperledger.org/browse/FAB-5406

Known Issues & Workarounds

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.

Please refer to https://jira.hyperledger.org/browse/FAB-5177 for more details,
and kindly be aware that given the above, we may end up changing the
fabric-ccenv in the future.

Change Log

https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v110

2018-03-16 01:44

v1.1.0-rc1 March 1, 2018

Release Notes

The v1.1 release candidate 1 (rc1) includes all of the features delivered in v1.1.0-preview
and v1.1.0-alpha.

Additionally, there are feature improvements, bug fixes, documentation and test
coverage improvements, UX improvements based on user feedback and changes to address a
variety of static scan findings (unused code, static security scanning, spelling,
linting and more).

Known Vulnerabilities

none

Resolved Vulnerabilities

none

Known Issues & Workarounds

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.

Please refer to https://jira.hyperledger.org/browse/FAB-5177 for more details,
and kindly be aware that given the above, we may end up changing the
fabric-ccenv in the future.

Change Log

https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v110-rc1

2018-03-02 02:28

v1.0.6 February 18, 2018

Release Notes

Bug fixes, documentation and test coverage improvements, UX improvements
based on user feedback and changes to address a variety of static scan
findings (unused code, static security scanning, spelling, linting and more).

Known Vulnerabilities

none

Resolved Vulnerabilities

none

Known Issues & Workarounds

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.

Please refer to https://jira.hyperledger.org/browse/FAB-5177 for more details,
and kindly be aware that given the above, we may end up changing the
fabric-ccenv in the future.

Change Log

https://github.com/hyperledger/fabric/blob/v1.0.6/CHANGELOG.md#v106

2018-02-19 00:26

v1.1.0-alpha January 25, 2018

Release Notes

This is a feature-complete alpha release of the up-coming 1.1 release. The 1.1 release
includes the following new major features:

Additionally, there are feature improvements, bug fixes, documentation and test
coverage improvements, UX improvements based on user feedback and changes to address a
variety of static scan findings (unused code, static security scanning, spelling,
linting and more).

Known Vulnerabilities

none

Resolved Vulnerabilities

none

Known Issues & Workarounds

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.

Please refer to https://jira.hyperledger.org/browse/FAB-5177 for more details,
and kindly be aware that given the above, we may end up changing the
fabric-ccenv in the future.

Change Log

https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v110-alpha

2018-01-26 00:20

v1.0.5 December 4, 2017

Release Notes

Bug fixes, documentation and test coverage improvements, UX improvements
based on user feedback and changes to address a variety of static scan
findings (unused code, static security scanning, spelling, linting and more).

Known Vulnerabilities

none

Resolved Vulnerabilities

none

Known Issues & Workarounds

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.

Please refer to https://jira.hyperledger.org/browse/FAB-5177 for more details,
and kindly be aware that given the above, we may end up changing the
fabric-ccenv in the future.

Change Log

https://github.com/hyperledger/fabric/blob/v1.0.5/CHANGELOG.md#v105

2017-12-07 00:17
Go
1
https://gitee.com/linva/fabric.git
git@gitee.com:linva/fabric.git
linva
fabric
fabric

搜索帮助