* NetworkBoostrapper can optionally whitelist contracts from signed jars based on include_whitelist.txt file.
* refactoring, docs
* logs
* add ne parameters to the generateWhitelist method at the end
* Addressing review comments.
* CORDA-2577 disable non-downgrade rule - test fix and docs
* Allow for duplicate (contract class, version) signed attachments in devMode.
* Code clean-up.
* Fix compilation error in test code.
* Additional gating/warning and added Unit test for development mode behaviour.
The overload that takes in a String does NOT check that the exception thrown has that message, which is what these tests are assuming. Rather it's the assertion message when the test fails.
TestCordapp has now two implementations to clearly separate the two use cases it has in the Corda repo:
* TestCordappImpl which implements the revised public API of TestCordapp; namely that a TestCordapp instance references a real CorDapp jar on the classpath. This is either an external dependency jar in which case it’s taken as is and given to the node, or it’s a local gradle project in which case it’s compiled using the gradle “jar” task to generate the CorDapp jar. This approach means the jar has all the original CorDapp versioning information, which is important that it’s correct when testing. To this end, TestCordapp only needs to expose the ability to specify the app’s config. All the remaining properties have moved to CustomCordapp.
* CustomCordapp for creating arbitrary custom CorDapps, including specifying the jar’s MANIFEST values. This is internal API and only used for testing the platform. Technically this shouldn’t implement TestCordapp but does so to reduce the complexity of the driver and mock network.
* Refactor into attachment service
Fix up mock service
First caching version, but with no invalidation currently
Set cache size
Fix up after rebase
Cache invalidation
Formatting tidy up
Sort out some nullability
Add kdocs.
Unit tests
More unit tests
Fix TODO
Unit test fixes
Unit test fixes
Fixed concurrent invalidating transaction support.
* Correct some transaction concurrency bug, including unit test.
* Added some unit tests for the method I added to persistence.
* Remove some blank lines
* Review feedback
* Fix imports
* Implementation of Contract and Workflow attribute identifiers.
* Fixes following rebase from master.
* Fix broken JUnit test.
* Fix broken JUnit test.
* Fix broken JUnit test.
* Added missing constants.
* Further clean-up.
* Updated documentation.
* Added changelog entry.
* Updated all samples (using new Gradle Plugin 4.0.37 functionality)
* Temporarily resolve gradle plugins from latest published snapshot.
* Temporarily resolve gradle plugins from latest published snapshot.
* Updates following feedback from PR review.
* Move constants into CordappInfo companion object.
* Contract and Workflow attribute `version` to `versionId` (as version is a reserved gradle variable)
* Clarified warning message on incorrect version identifier.
* Align version identifier processing logic with gradle cordapp plugin.
* Updated comment.
* Minor fixes following rebase from master.
* Fixed broken unit test.
* Improved exception reporting.
* Update to use 4.0.37 of Gradle Plugins.
* Added support for combined Contract and Workflow CorDapp info.
* Updated following discussions with Shams + cleanup.
* Updated following Shams PR review.
* Minor API improvements.
* Added missing cordapp info causing deployNodes to fail.
Contract class version non-downgrade rule is check by LedgerTransaction.verify().
TransactionBuilder.toWireTransaction(services: ServicesForResolution) selects attachments for the transaction which obey non downgrade rule.
New ServiceHub method loadAttachmentConstraint(stateRef: StateRef, forContractClassName: ContractClassName? = null) retrieves the attachment contract related to transaction output states of given contract class name.
TransactionBuilder loads attachment using attachment storage instead of CordappLoader,
contract class version is now Integer (format and stored in db as Integer).
* CORDA-2089 - network parameters tags - part
Data structures changes, storage and notarisation.
Tag transactions with network parameters hash that was in force when tx
was created. Add component group on all core transactions and resolved
parameters on full transactions. The hash should be always visible on
the filtered versions of transactions. Add
notarisation check that the parameters are current.
Implement network parameters storage on services for resolution.
This is only part of the work, next PR will include changes to
ResolveTransactionsFlow to make sure that parameters in the transaction
graph are ordered (this is to prevent the downgrade attack, when the
malicious notary and participants sign transaction that shouldn't be
notarised otherwise).
Probably on network services side we need the default parameters
endpoint for the
transactions that were created before this change - for now it's default
to the current ones.
* Make parameters storage agnostic to cert hierarchy
Test fixes
* Address most PR comments
* Fixes after rebase
* Fixes. Add epoch column to parameters storage.
* Address part of review comments
* Some more comments
* Hopefully fixing what I broke doing rebse
* Address Kostas comments
* Further fixes
* Save all parameters from updates to storage
* Fix integration test
* Address comments
* Fixes after rebase
* Fix test
* Fixes
* Add wrapper for filtering around parameters hash
* API stability fixes
* Add NetworkParametersStorageInternal
* Rename
* Temp commit
* Print the error message first by default, makes error output more natural.
* Polishing
* Further modifications after testing
* Documentation updates
* Couple of fixes after review
* Removing unnecessary tests
* Fix broken test
* Add interface to bootstrapper for testign
* Added unit tests
* Remove unused class
* Fix up bootstrapper unit tests and add a couple more
* Refactor the tests slightly
* Review comments
* Couple of minor tweaks
* ENT-2610: Separate passwords for store and for private keys in Corda OS.
When it comes to KeyStores there are *2* passwords: 1 for the keyStore as a whole and separately there is one private keys within this keyStore.
Unfortunately, those 2 passwords have to be the same due to Artemis limitation, for more details please see:
`org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport.loadKeyManagerFactory`
where it is calling `KeyManagerFactory.init()` with store password.
Before change in this PR, throughout our codebase there are multiple places where we assume that storePassword is the same as keyPassword, even in the classes that have nothing to do with Artemis.
This is of course less than ideal as TLS communication may be used not only for Artemis connectivity (e.g. Bridge/Float interaction in Ent) and it is unfair to impose same passwords constraint on that communication channel.
Therefore this PR is removing this limitation and properly separating storePassword from keyPassword.
Linked Jira(https://r3-cev.atlassian.net/browse/ENT-2610) has for more background info.
Suggest to start review from `net.corda.core.crypto.X509NameConstraintsTest` to get an idea about the nature of the changes made.
* ENT-2610: Address PR input from @kchalkias
* ENT-2610: Address PR input from @kchalkias, s/privateKeyPassword/entryPassword/
* ENT-2610: Address PR input from @kchalkias, s/keyPassword/entryPassword/
In the implementation of `CertificateStoreSupplier`
The entry point to the API has been simplified to just requireing a list of packages to scan, with sensible defaults provided for the metadata. Because of the wither methods, having parameters for the metadata (with default values) seems unnecessary. Also the ability to scan just individual classes has been made internal, as it seems unlikely app developers would need that level of control when testing their apps.
TestCordappImpl is a data class and thus acts as a natural key for the Jar caching, where previously the key was the package names. This fixes an issue where it was not possible to create two CorDapp Jars of the same package but different metadata.
* Provide an optional configuration setting to specify the minimum platform version to use in the network params file.
* Leave Cordform signature intact.
* Leave previous Gradle Plugin called signature intact.
* Incorporating feedback from PR review.
* Added minimum platform version validation check.
* Removed final 2 references to "default"
* Added changelog entry.
* Add test for SNI header to prevent changing it accidentally.
* added hardcoded values test to ensure hashing function and corda x500 name format can't be changed
* Create constraint, extract Jar signature collection
* Extract JarSignatureCollector into its own file
* Jar signature collection throws exception if signatures are inconsistent
* Focus testing in Jar signature collection
* Extract some helper functions in test
* Patch tests with mock attachment storage
* Assert that generated constraint is satisfied by signed attachment
* Clarify constraint selection logic
* Explicit return types on extension methods
* Link to docsite Signature Contrainsts documentation
* Fix issue with shared JAR reading buffer
Moved start up logic of the various node components out of their c’tors and into “start” methods, which are called from Node.start(). The components themselves are created in the Node’s c’tor with minimal initialisation logic.
Certain things are not immediately available at construction time, which are instead given to the components at start time in an orderly fashion:
* Certs from the node’s key store and trust store
* The network parameters, and thus access to things like maxMessageSize and the contracts whitelist
* A running database - several components were doing database stuff their c’tors
* The node’s NodeInfo, and thus access to things like identities and addresses
The messaging service couldn’t be created in the Node’s c’tor due to initialisation issues with MockNode. This should be fixed in a later commit.
* CORDA-1661 Reverting DEV certificates
* Addressing review comments
* Removed the intermediate certificate from the trust store and added some test cases for the revocation check
The list of CorDapps jars is no longer passed in via the cmd line but is now expected to be placed in the bootstrapped directory.
Ended up being a bit of a refactor to cater for unit testing, and also tidied up the bootstrapper docs.
node-api now depends on this module and upcoming changes will use this as well rather than having to depend on node-api.
EnumEvolveTests.deserializeWithRename and EnumEvolveTests.multiOperations are temporarily ignored since their test resources can't be regenerated due to bugs.
It's no longer used as we've switched over to AMQP for RPC calls so
remove it from everywhere and only use it for checkpointing
* Wire up demo bench post Kryo removal
* Test Fixes
* rebase and fix tests
* Test Fix
* wip
* revert changes to api now we don't need to add annotations
