ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-06-21 00:23:09 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'remotes/origin/master' into feature/ENT-2253-NonStop-changes

Browse Source 
# Conflicts:
#	node/src/main/resources/migration/node-info.changelog-master.xml
#	node/src/main/resources/migration/node-info.changelog-v3.xml
This commit is contained in:
szymonsztuka
2018-08-30 15:51:38 +01:00
parent cc27463b25 dbc1088417
commit b98f91ee61
28 changed files with 802 additions and 660 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
docs/source/changelog.rst
View File

@ -17,7 +17,7 @@ Unreleased
* Introduced ``TestCorDapp`` and utilities to support asymmetric setups for nodes through ``DriverDSL``, ``MockNetwork`` and ``MockServices``.
* Change type of the `checkpoint_value` column. Please check the upgrade-notes on how to update your database.
* Change type of the ``checkpoint_value`` column. Please check the upgrade-notes on how to update your database.
* Removed buggy :serverNameTablePrefix: configuration.
@ -153,7 +153,7 @@ Unreleased
Values are: [FAIL, WARN, IGNORE], default to FAIL if unspecified.
* Introduced a placeholder for custom properties within ``node.conf``; the property key is "custom".
* The deprecated web server now has its own ``web-server.conf`` file, separate from ``node.conf``.
* Property keys with double quotes (e.g. `"key"`) in ``node.conf`` are no longer allowed, for rationale refer to :doc:`corda-configuration-file`.
* Property keys with double quotes (e.g. "key") in ``node.conf`` are no longer allowed, for rationale refer to :doc:`corda-configuration-file`.
* Added public support for creating ``CordaRPCClient`` using SSL. For this to work the node needs to provide client applications
a certificate to be added to a truststore. See :doc:`tutorial-clientrpc-api`
@ -170,7 +170,7 @@ Unreleased
* The whitelist.txt file is no longer needed. The existing network parameters file is used to update the current contracts
whitelist.
* The CorDapp jars are also copied to each nodes' `cordapps` directory.
* The CorDapp jars are also copied to each nodes' ``cordapps`` directory.
* Errors thrown by a Corda node will now reported to a calling RPC client with attention to serialization and obfuscation of internal data.
@ -180,6 +180,8 @@ Unreleased
reference to the outer class) as per the Java documentation `here <https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html>`_
we are disallowing this as the paradigm in general makes little sense for contract states.
* Node can be shut down abruptly by ``shutdown`` function in ``CordaRPCOps`` or gracefully (draining flows first) through ``gracefulShutdown`` command from shell.
* API change: ``net.corda.core.schemas.PersistentStateRef`` fields (index and txId) are now non-nullable.
The fields were always effectively non-nullable - values were set from non-nullable fields of other objects.
The class is used as database Primary Key columns of other entities and databases already impose those columns as non-nullable
@ -192,8 +194,8 @@ Unreleased
* Table name with a typo changed from ``NODE_ATTCHMENTS_CONTRACTS`` to ``NODE_ATTACHMENTS_CONTRACTS``.
* Node logs a warning for any ``MappedSchema`` containing a JPA entity referencing another JPA entity from a different ``MappedSchema`.
The log entry starts with `Cross-reference between MappedSchemas.`.
* Node logs a warning for any ``MappedSchema`` containing a JPA entity referencing another JPA entity from a different ``MappedSchema``.
The log entry starts with "Cross-reference between MappedSchemas".
API: Persistence documentation no longer suggests mapping between different schemas.
* Upgraded Artemis to v2.6.2.
@ -476,6 +478,9 @@ Corda Enterprise 3.0 Developer Preview
will help make it clearer which parts of the api are stable. Scripts have been provided to smooth the upgrade
process for existing projects in the ``tools\scripts`` directory of the Corda repo.
* ``TransactionSignature`` includes a new ``partialMerkleTree`` property, required for future support of signing over
multiple transactions at once.
* Shell (embedded available only in dev mode or via SSH) connects to the node via RPC instead of using the ``CordaRPCOps`` object directly.
To enable RPC connectivity ensure node’s ``rpcSettings.address`` and ``rpcSettings.adminAddress`` settings are present.

11
docs/source/design/data-model-upgrades/signature-constraints.md
View File

@ -4,7 +4,7 @@ This design document outlines an additional kind of *contract constraint*, used
## Background
Contract constraints are a part of how Corda manages application upgrades. There are two kinds of upgrade that can be applied to the ledger:
Contract constraints are a part of how Corda ensures the correct code is executed to verify transactions, and also how it manages application upgrades. There are two kinds of upgrade that can be applied to the ledger:
* Explicit
* Implicit
@ -31,21 +31,20 @@ We would like a new kind of constraint that is more convenient and decentralised
## Goals
* Improve usability by eliminating the need to change the network parameters.
* Improve decentralisation by allowing apps to be developed and upgraded without the zone operator knowing or being able to influence it.
* Eventually, phase out zone whitelisting constraints.
## Non-goals
* Preventing downgrade attacks. Downgrade attack prevention will be tackled in a different design effort.
* Phase out of hash constraints. If malicious app creators are in the users threat model then hash constraints are the way to go.
* Handling the case where third parties re-sign app jars.
* Package namespace ownership (a separate effort).
* Allowing the zone operator to override older constraints, to provide a non-explicit upgrade path.
## Design details
We propose being able to constrain to any attachments signed by a specified set of keys.
We propose being able to constrain to any attachments whose files are signed by a specified set of keys.
This satisfies the usability requirement because the creation of a new application is as simple as invoking the `jarsigner` tool that comes with the JDK. This can be integrated with the build system via a Gradle or Maven task. For example, Gradle can use jarsigner via [the signjar task](https://ant.apache.org/manual/Tasks/signjar.html) ([example](https://gist.github.com/Lien/7150434)).
@ -87,7 +86,7 @@ The `TransactionBuilder` class can select the right constraint given what it alr
### Tooling and workflow
The primary tool required is of course `jarsigner`. In dev and integration test modes, the node will ignore missing signatures in attachment JARs and will simply log a warning if no signature is present.
The primary tool required is of course `jarsigner`. In dev mode, the node will ignore missing signatures in attachment JARs and will simply log an error if no signature is present when a constraint requires one.
To verify and print information about the signatures on a JAR, the `jarsigner` tool can be used again. In addition, we should add some new shell commands that do the same thing, but for a given attachment hash or transaction hash - these may be useful for debugging and analysis. Actually a new shell command should cover all aspects of inspecting attachments - not just signatures but what's inside them, simple way to save them to local disk etc.