Oct 30, 2018
PATCH - 2018 10 30 - CORDA-2109

@fenryka fenryka released this Oct 15, 2018 · 14 commits to release-V3 since this release

Assets 2

Corda 3.3 is now available!

Corda 3.3 brings together many small improvements, fixes, and community contributions to deliver a stable and polished release of Corda. Where both the 3.1 and 3.2 releases delivered a smaller number of critical bug fixes addressing immediate and impactful error conditions, 3.3 addresses a much greater number of issues, both small and large, that have been found and fixed since the release of 3.0 back in March. Rolling up a great many improvements and polish to truly make the Corda experience just that much better.

In addition to work undertaken by the main Corda development team, we've taken the opportunity in 3.3 to bring back many of the contributions made by community members from master onto the currently released stable branch. It has been said many times before, but the community and its members are the real life-blood of Corda and anyone who takes the time to contribute is a star in our eyes. Bringing that code into the current version we hope gives people the opportunity to see their work in action, and to help their fellow community members by having these contributions available in a supported release.

Changes of Note

Serialization fixes

Things "in the lab" always work so much better than they do in the wild, where everything you didn't think of is thrown at your code and a mockery is made of some dearly held assumptions. A great example of this is the serialization framework which delivers Corda's wire stability guarantee that was introduced in 3.0 and has subsequently been put to a rigorous test by our users. Corda 3.3 consolidates a great many fixes in that framework, both programmatically in terms of fixing bugs, but also in the documentation, hopefully making things clearer and easier to work with.

Certificate Hierarchy

After consultation, collaboration, and discussion with industry experts, we have decided to alter the default Certificate Hierarchy (PKI) utilized by Corda and the Corda Network. To facilitate this, the nodes have had their certificate path verification logic made much more flexible. All existing certificate hierarchy, certificates, and networks will remain valid. The possibility now exists for nodes to recognize a deeper certificate chain and thus Compatibility Zone operators can deploy and adhere to the PKI standards they expect and are comfortable with.

Practically speaking, the old code assumed a 3-level hierarchy of Root -> Intermediate CA (Doorman) -> Node, and this was hard coded. From 3.3 onward an arbitrary depth of certificate chain is supported. For the Corda Network, this means the introduction of an intermediate layer between the root and the signing certificates (Network Map and Doorman). This has the effect of allowing the root certificate to always be kept offline and never retrieved or used. Those new intermediate certificates can be used to generate, if ever needed, new signing certs without risking compromise of the root key.

Special Thanks

The Corda community is a vibrant and exciting ecosystem that spreads far outside the virtual walls of the
R3 organisation. Without that community, and the most welcome contributions of its members, the Corda project
would be a much poorer place.

We're therefore happy to extend thanks to the following members of that community for their contributions

@fenryka fenryka released this Jul 20, 2018 · 1485 commits to master since this release

Assets 2

Corda 3.2

As we see more Corda deployments in production this minor release of the open source platform brings
several fixes that make it easier for a node to join Corda networks broader than those used when
operating as part of an internal testing deployment. This will ensure Corda nodes will be free to interact
with upcoming network offerings from R3 and others who may make broad-access Corda networks available.

The Corda Network Builder

To make it easier to create more dynamic, flexible, networks for testing and deployment,
with the 3.2 release of Corda we are shipping a graphical network bootstrapping tool
to facilitate the simple creation of more dynamic ad hoc dev-mode environments.

Using a graphical interface you can dynamically create and alter Corda test networks, adding
nodes and CorDapps with the click of a button! Additionally, you can leverage its integration
with Azure cloud services for remote hosting of Nodes and Docker instances for local testing.

Split Compatibility Zone

Prior to this release compatibility zone membership was denoted with a single configuration setting

compatibilityZoneURL : "http://<host>(:<port>)"

That would indicate both the location of the Doorman service the node should use for registration
of its identity as well as the Network Map service where it would publish its signed Node Info and
retrieve the Network Map.

Compatibility Zones can now, however, be configured with the two disparate services, Doorman and
Network Map, running on different URLs. If the compatibility zone your node is connecting to
is configured in this manner, the new configuration looks as follows.

networkServices {
    doormanURL: "http://<host>(:<port>)"
    networkMapURL: "http://<host>(:<port>)"
}

NOTE: The compatibilityZoneURL setting should be considered deprecated in favor of the new networkServices settings group.

The Blob Inspector

The blob inspector brings the ability to unpack serialized Corda blobs at the
command line, giving a human-readable interpretation of the encoded date.

NOTE: This tool has been shipped as a separate Jar previously. We are now including it as part of an official release.

Documentation on its use can be found here :doc:blob-inspector

The Event Horizon

One part of joining a node to a Corda network is agreeing to the rules that govern that network as set out
by the network operator. A node's membership of a network is communicated to other nodes through the network
map, the service to which the node will have published its Node Info, and through which it receives the
set of NodeInfos currently present on the network. Membership of that list is a finite thing determined by
the network operator.

Periodically a node will republish its NodeInfo to the Network Map service. The Network Map uses this as a
heartbeat to determine the status of nodes registered with it. Those that don't "beep" within the
determined interval are removed from the list of registered nodes. The Event Horizon network parameter
sets the upper limit within which a node must respond or be considered inactive.

.. important:: This does not mean a node is unregistered from the Doorman, only that its NodeInfo is
removed from the Network Map. Should the node come back online it will be re-added to the published
set of NodeInfos

Issues Fixed

  • Update Jolokia to a more secure version [CORDA-1744]
  • Add the Blob Inspector [CORDA-1709]
  • Add support for the Event Horizon Network Parameter [CORDA-866]
  • Add the Network Bootstrapper [CORDA-1717]
  • Fixes for the finance CordApp[CORDA-1711]
  • Allow Doorman and NetworkMap to be configured independently [CORDA-1510]
  • Serialization fix for generics when evolving a class [CORDA-1530]
  • Correct typo in an internal database table name [CORDA-1499] and [CORDA-1804]
  • Hibernate session not flushed before handing over raw JDBC session to user code [CORDA-1548]
  • Fix Postgres db bloat issue [CORDA-1812]
  • Roll back flow transaction on exception [CORDA-1790]
Jul 16, 2018
Second 3.2 release candidate
Jul 6, 2018
First release candidate for the 3.2 OS release