From fea296058a893da4dd5f420805c97bfe12f6f1bd Mon Sep 17 00:00:00 2001 From: Joel Dudley Date: Wed, 13 Jun 2018 19:51:34 +0100 Subject: [PATCH 1/5] Cleanup of docs about building against master (#3361) * Small fixes to building-against-master docs * Self-review * Fixes bullet numbers. --- docs/source/building-against-master.rst | 27 ++++++++++--------------- 1 file changed, 11 insertions(+), 16 deletions(-) diff --git a/docs/source/building-against-master.rst b/docs/source/building-against-master.rst index e837f911a3..4c86894ade 100644 --- a/docs/source/building-against-master.rst +++ b/docs/source/building-against-master.rst @@ -1,30 +1,25 @@ -Building against Master -======================= +Building CorDapps against Master +================================ -It is advisable to develop CorDapps against the most recent Corda stable release. However you may need to build -against the unstable Master branch if you are using a very recent feature, or are testing a PR on the main codebase. +It is advisable to develop CorDapps against the most recent Corda stable release. However, you may need to build a CorDapp +against the unstable Master branch if your CorDapp uses a very recent feature, or you are using the CorDapp to test a PR +on the main codebase. To work against the Master branch, proceed as follows: -1. Open a terminal window in the folder where you cloned the Corda repository - (available `here `_) +1. Clone the `Corda repository `_ -2. Use the following command to check out the latest master branch: +2. Open a terminal window in the folder where you cloned the Corda repository + +3. Use the following command to check out the latest master branch: ``git checkout master; git pull`` -3. Publish Corda to your local Maven repository using the following commands: +4. Publish Corda to your local Maven repository using the following commands: * Unix/Mac OSX: ``./gradlew install`` * Windows: ``gradlew.bat install`` - By default, the Maven local repository is found at: - - * ``~/.m2/repository`` on Unix/Mac OS X - * ``%HOMEPATH%\.m2`` on Windows - - This step is not necessary when using a stable releases, as the stable releases are published online - .. warning:: If you do modify your local Corda repository after having published it to Maven local, then you must re-publish it to Maven local for the local installation to reflect the changes you have made. @@ -32,5 +27,5 @@ To work against the Master branch, proceed as follows: time may differ. If you are using a Master release and need help debugging an error, then please let us know the **commit** you are working from. This will help us ascertain the issue. -4. Update the ``ext.corda_release_version`` property in your CorDapp's root ``build.gradle`` file to match the version +5. Update the ``ext.corda_release_version`` property in your CorDapp's root ``build.gradle`` file to match the version here: https://github.com/corda/corda/blob/master/build.gradle#L7 From 3d107200a153adaa0f60144efe0c256abea1c917 Mon Sep 17 00:00:00 2001 From: Katarzyna Streich Date: Thu, 14 Jun 2018 10:20:18 +0100 Subject: [PATCH 2/5] Fix flaky test (#3363) --- .../corda/node/services/network/NetworkMapUpdaterTest.kt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/node/src/test/kotlin/net/corda/node/services/network/NetworkMapUpdaterTest.kt b/node/src/test/kotlin/net/corda/node/services/network/NetworkMapUpdaterTest.kt index f56a64489e..fd08de8cef 100644 --- a/node/src/test/kotlin/net/corda/node/services/network/NetworkMapUpdaterTest.kt +++ b/node/src/test/kotlin/net/corda/node/services/network/NetworkMapUpdaterTest.kt @@ -71,8 +71,8 @@ class NetworkMapUpdaterTest { server.close() } - private fun setUpdater(ourNodeHash: SecureHash? = null, extraNetworkMapKeys: List = emptyList()) { - updater = NetworkMapUpdater(networkMapCache, fileWatcher, networkMapClient, server.networkParameters.serialize().hash, ourNodeHash, baseDir, extraNetworkMapKeys) + private fun setUpdater(ourNodeHash: SecureHash? = null, extraNetworkMapKeys: List = emptyList(), netMapClient: NetworkMapClient? = networkMapClient) { + updater = NetworkMapUpdater(networkMapCache, fileWatcher, netMapClient, server.networkParameters.serialize().hash, ourNodeHash, baseDir, extraNetworkMapKeys) } @Test @@ -230,7 +230,7 @@ class NetworkMapUpdaterTest { @Test fun `remove node from filesystem deletes it from network map cache`() { - setUpdater() + setUpdater(netMapClient = null) val fileNodeInfoAndSigned1 = createNodeInfoAndSigned("Info from file 1") val fileNodeInfoAndSigned2 = createNodeInfoAndSigned("Info from file 2") updater.subscribeToNetworkMap() From 8f4973cd00ab42dd530ad89fea30b5bf98cbd322 Mon Sep 17 00:00:00 2001 From: Florian Friemel Date: Thu, 14 Jun 2018 13:09:03 +0100 Subject: [PATCH 3/5] [CORDA-1617] Fix explorer login error handling. (#3365) When specifying incorrect connection details for the nodes (e.g., wrong port), an RPCException would be thrown which was not handled correctly, resulting in busy waiting on the UI thread. Ideally the login should not block the UI thread anyways, but for now this fix is the most pragmatic solution. --- .../client/jfx/model/NodeMonitorModel.kt | 27 +++++++++++-------- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/client/jfx/src/main/kotlin/net/corda/client/jfx/model/NodeMonitorModel.kt b/client/jfx/src/main/kotlin/net/corda/client/jfx/model/NodeMonitorModel.kt index 07cb4f3797..0194edb110 100644 --- a/client/jfx/src/main/kotlin/net/corda/client/jfx/model/NodeMonitorModel.kt +++ b/client/jfx/src/main/kotlin/net/corda/client/jfx/model/NodeMonitorModel.kt @@ -6,6 +6,7 @@ import javafx.beans.property.SimpleObjectProperty import net.corda.client.rpc.CordaRPCClient import net.corda.client.rpc.CordaRPCClientConfiguration import net.corda.client.rpc.CordaRPCConnection +import net.corda.client.rpc.RPCException import net.corda.core.contracts.ContractState import net.corda.core.flows.StateMachineRunId import net.corda.core.identity.Party @@ -193,18 +194,22 @@ class NodeMonitorModel { val nodeInfo = _connection.proxy.nodeInfo() require(nodeInfo.legalIdentitiesAndCerts.isNotEmpty()) _connection - } catch (secEx: ActiveMQException) { - // Happens when: - // * incorrect credentials provided; - // * incorrect endpoint specified; - // - no point to retry connecting. - throw secEx - } catch (th: Throwable) { - // Deliberately not logging full stack trace as it will be full of internal stacktraces. - logger.info("Exception upon establishing connection: " + th.message) - null + } catch (throwable: Throwable) { + when (throwable) { + is ActiveMQException, is RPCException -> { + // Happens when: + // * incorrect credentials provided; + // * incorrect endpoint specified; + // - no point to retry connecting. + throw throwable + } + else -> { + // Deliberately not logging full stack trace as it will be full of internal stacktraces. + logger.info("Exception upon establishing connection: " + throwable.message) + null + } + } } - if (connection != null) { logger.info("Connection successfully established with: $nodeHostAndPort") return connection From c15fde242f4c785480f20e1f3fecdf88a1938541 Mon Sep 17 00:00:00 2001 From: Joel Dudley Date: Thu, 14 Jun 2018 13:46:20 +0100 Subject: [PATCH 4/5] Adds header of SGX design doc subheaders don't spill (#3366) --- docs/source/design/sgx-integration/design.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/source/design/sgx-integration/design.md b/docs/source/design/sgx-integration/design.md index daee03273d..3ea2a393ac 100644 --- a/docs/source/design/sgx-integration/design.md +++ b/docs/source/design/sgx-integration/design.md @@ -1,3 +1,5 @@ +# SGX Integration + This document is intended as a design description of how we can go about integrating SGX with Corda. As the infrastructure design of SGX is quite involved (detailed elsewhere) but otherwise flexible we can discuss the possible integration points separately, without delving into lower level technical detail. From 81730b0a140051e65ddf7505d4cba22b4dea04c4 Mon Sep 17 00:00:00 2001 From: Konstantinos Chalkias Date: Thu, 14 Jun 2018 14:34:56 +0100 Subject: [PATCH 5/5] [CORDA-1515] Clarify distinction between non-validating and validating notaries (#3369) --- docs/source/key-concepts-notaries.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/source/key-concepts-notaries.rst b/docs/source/key-concepts-notaries.rst index b3ac509bce..054ee7289c 100644 --- a/docs/source/key-concepts-notaries.rst +++ b/docs/source/key-concepts-notaries.rst @@ -4,7 +4,8 @@ Notaries .. topic:: Summary * *Notary clusters prevent "double-spends"* - * *Notary clusters may optionally also validate transactions* + * *Notary clusters are also time-stamping authorities. If a transaction includes a time-window, it can only be notarised during that window* + * *Notary clusters may optionally also validate transactions, in which case they are called "validating" notaries, as opposed to "non-validating"* * *A network can have several notary clusters, each running a different consensus algorithm* .. only:: htmlmode @@ -54,11 +55,11 @@ Validation A notary cluster must also decide whether or not to provide **validity consensus** by validating each transaction before committing it. In making this decision, it faces the following trade-off: -* If a transaction **is not** checked for validity, it creates the risk of "denial of state" attacks, where a node +* If a transaction **is not** checked for validity (non-validating notary), it creates the risk of "denial of state" attacks, where a node knowingly builds an invalid transaction consuming some set of existing states and sends it to the notary cluster, causing the states to be marked as consumed -* If the transaction **is** checked for validity, the notary will need to see the full contents of the transaction and +* If the transaction **is** checked for validity (validating notary), the notary will need to see the full contents of the transaction and its dependencies. This leaks potentially private data to the notary cluster There are several further points to keep in mind when evaluating this trade-off. In the case of the non-validating