network-parameters file read in by the node at startup, of which only the list of notaries is used. For now, the driver and MockNetwork have been updated to require notaries to be started first. This is so that the same set of network parameters can be defined for all the nodes.
CN in the legal name is not longer disallowed since it's no longer reserved for distributed notary names.
Single-node notaries now only have one identity, their main identity. Nodes part of a cluster continue to have two.
(Based off Kasia's work)
Define the two transforms that will be useful for enum evolvability (see
design document for more details).
Furthermore, define the generic mechanism by which transform annotations
on classes are encoded into the AMQP envelope
With nothing to check for these annotations at either end, this is
mostly a no op, but an important step toward getting evolvability in
place
* CORDA-351: force update dependencies and suppress vulnerabilities not affecting corda
* CORDA-351: force update dependencies and suppress vulnerabilities not affecting corda
* [CORDA-442] let Driver run without network map
- Nodes started by driver run without a networkMapNode.
- Driver does not take a networkMapStartStrategy anymore
- a new parameter in the configuration "noNetworkMapServiceMode" allows for a node not to be a networkMapNode nor to connect to one.
- Driver now waits for each node to write its own NodeInfo file to disk and then copies it into each other node.
- When driver starts a node N, it waits for every node to be have N nodes in their network map.
Note: the code to copy around the NodeInfo files was already in DemoBench, the NodeInfoFilesCopier class was just moved from DemoBench into core (I'm very open to core not being the best place, please advise)
* Remove local function because it is serialised as a lambda.
* Don't automatically whitelist Kotlin lambdas unless checkpointing.
* Add comment to @CordaSerializable, warning not to allow AnnotationTarget.EXPRESSION.
* Don't repackage well known key types when converting keys to a well known type
* Remove custom key serializers
* Remove duplicate serializer registration
* Added schedulable flows to cordapp scanning
Fixed a bug where the core flows are included in every cordapp. Added a test to prove the scheduled flows are loaded correctly. Added scheduled flow support to cordapp.
Renabled broken test.
Fixed test to prove cordapps aren't retreived from network.
Review fixes.
Fixed a test issue caused by gradle having slightly different paths to IntelliJ
* Fixed test for real this time.
* Rename and move CordaPluginRegistry to reflect its real purpose now.
* Docs: docsite improvements
* Remove discussion of webserver from 'writing a cordapp' page.
* Fixup some flow docs.
* Add a couple more package descriptions.
* Review comments - always apply default whitelist and no longer load it via ServiceLoader
* Added wording about renaming services resource file
* CORDA-540: Do not use concrete instance of an ArrayList as wire representation of it may be different
* CORDA-540: Make data structures suitable for AMQP serialization
* CORDA-540: Use "name" instead of "toString()"
Classes like "net.corda.finance.contracts.DayCountBasisDay" override "toString()" which leads to error behaviour
Handle PR comments
Add nicer constructors to CordaException and CordaRuntimeException
(cherry picked from commit 89478c8)
Fix ambiguous defaulted constructor
(cherry picked from commit ec9bafe)
Address PR comment
Update a few more custom exceptions
So...
On reflection, and adding a number of tests for static initialisation
with serialised types it looks like there is no chance that the
serializer factory will ever pass a non white-listed type through to the
carpenter in the first place.
As such leaving the plumbing in as it may be useful to pass a blacklist
at some point into the carpenter and the tests are always useful
(ignoring those that won't work without the white-list checking)
The class carpenter should refuse to carpent classes that are not
whitelisted or marked as CordaSerializable. This prevents any security
issue where a malicious message could indicate a class had a member of
some type that on construction did something bad. By respecting the
whitelist we avoid this.
As the carpeter annotates anythign it constructs as CordaSerializable,
it will always be able to carpent classes that contain memebrs that were
unknown, and thus unannotated, carpented classes
The current use of SSL RPC relies on access to the node's keystore file, and further to that some uses where using the NODE_USER to login on the p2p port.