ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-03-15 00:36:49 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Fixes formatting. (#1326)

Browse Source 
* Fixes formatting.

* Fixes backticks.
This commit is contained in:
Joel Dudley 2018-08-10 11:27:35 +01:00 committed by GitHub
parent e4ae53d99b
commit b72d4295ba
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 21 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
docs/source/upgrade-notes.rst
View File

@ -25,7 +25,6 @@ Upgrading to |release| from Open Source 3.x requires updating build file propert
ext.corda_release_distribution = 'com.r3.corda'
ext.corda_release_version = '3.1'
ext.corda_gradle_plugins_version = '4.0.25'
..
and specifying an additional repository entry to point to the location of the Corda Enterprise distribution. As an example:
@ -45,13 +44,13 @@ and specifying an additional repository entry to point to the location of the Co
.. note:: While the Corda Gradle Plugins need no changes apart from the version, ensure that Corda Enterprise dependencies are referenced with the right distribution. As an example:
.. sourcecode:: shell
.. sourcecode:: shell
cordaCompile "net.corda:corda-core:$corda_release_version"
becomes:
becomes:
.. sourcecode:: shell
.. sourcecode:: shell
cordaCompile "$corda_release_distribution:corda-core:$corda_release_version"
@ -62,25 +61,26 @@ becomes:
ext.kotlin_version = '1.2.50'
.. note:: Explicit overriding of properties `ext.quasar_group` and `ext.quasar_version` is not necessary anymore for CorDapps depending on the `quasar-utils` plugin. You can remove these two lines from which ever file.
.. note:: Explicit overriding of properties ``ext.quasar_group`` and ``ext.quasar_version`` is not necessary anymore
for CorDapps depending on the ``quasar-utils`` plugin. You can remove these two lines from which ever file.
Certificate Revocation List (CRL) support
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The newly added feature of certificate revocation (see :doc:`certificate-revocation`) introduces a few changes to the node configuration.
In the configuration file it is required to explicitly specify how strictly the node should apply the CRL check. For that purpose the `crlCheckSoftFail`
In the configuration file it is required to explicitly specify how strictly the node should apply the CRL check. For that purpose the ``crlCheckSoftFail``
parameter is now expected to be set explicitly in the node's SSL configuration.
Setting the `crlCheckSoftFail` to true, relaxes the CRL checking policy. In this mode, the SSL communication
Setting the ``crlCheckSoftFail`` to true, relaxes the CRL checking policy. In this mode, the SSL communication
will fail only when the certificate revocation status can be checked and the certificate is revoked. Otherwise it will succeed.
If `crlCheckSoftFail` is false, then an SSL failure can occur if the certificate revocation status cannot be checked (e.g. due to a network failure), as well as when
If ``crlCheckSoftFail`` is false, then an SSL failure can occur if the certificate revocation status cannot be checked (e.g. due to a network failure), as well as when
a certificate is revoked.
Older versions of Corda do not have CRL distribution points embedded in the SSL certificates.
As such, in order to be able to reuse node and SSL certificates generated in those versions of Corda, the `crlCheckSoftFail` needs
As such, in order to be able to reuse node and SSL certificates generated in those versions of Corda, the ``crlCheckSoftFail`` needs
to be set to true.
.. note::
Mitigation of this issue and thus being able to use the `strict` mode (i.e. with `crlCheckSoftFail` = false)
Mitigation of this issue and thus being able to use the ``strict`` mode (i.e. with ``crlCheckSoftFail = false``)
of the CRL checking with the certificates generated in previous versions of Corda is going to be added in the near future.
Upgrading from Corda Enterprise 3.0 Developer Preview 3.0
@ -94,13 +94,13 @@ A limited distribution preview of |release| was made available to a small number
ext.corda_release_version = '3.1'
ext.corda_gradle_plugins_version = '4.0.25'
ext.kotlin_version = '1.2.50'
..
.. note:: Explicit overriding of properties `ext.quasar_group` and `ext.quasar_version` is not necessary anymore for CorDapps depending on the `quasar-utils` plugin. You can remove these two lines from which ever file.
.. note:: Explicit overriding of properties ``ext.quasar_group`` and ``ext.quasar_version`` is not necessary anymore for CorDapps depending on the ``quasar-utils`` plugin. You can remove these two lines from which ever file.
* For CorDapps depending on the `cordapp-plugin`, version `4.0.25` allows specifying distribution information. As an example:
* For CorDapps depending on the ``cordapp-plugin``, version ``4.0.25`` allows specifying distribution information. As an example:
.. sourcecode:: groovy
cordapp {
info {
name "My CorDapp"
@ -109,23 +109,25 @@ A limited distribution preview of |release| was made available to a small number
}
}
.. note:: Properties `name` and `version` of a CorDapp's distribution information are derived automatically by the `cordapp-plugin` if not provided. The `vendor` property should be provided explicitly. A warning is raised by Corda Enterprise nodes for CorDapps that do not specify the `vendor` property.
.. note:: Properties ``name`` and ``version`` of a CorDapp's distribution information are derived automatically by
the ``cordapp-plugin`` if not provided. The ``vendor`` property should be provided explicitly. A warning is raised
by Corda Enterprise nodes for CorDapps that do not specify the ``vendor`` property.
Certificate Revocation List (CRL) support
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The newly added feature of certificate revocation (see :doc:`certificate-revocation`) introduces a few changes to the node configuration.
In the configuration file it is required to explicitly specify how strictly the node should apply the CRL check. For that purpose the `crlCheckSoftFail`
In the configuration file it is required to explicitly specify how strictly the node should apply the CRL check. For that purpose the ``crlCheckSoftFail``
parameter is now expected to be set explicitly in the node's SSL configuration.
Setting the `crlCheckSoftFail` to true, relaxes the CRL checking policy. In this mode, the SSL communication
Setting the ``crlCheckSoftFail`` to true, relaxes the CRL checking policy. In this mode, the SSL communication
will fail only when the certificate revocation status can be checked and the certificate is revoked. Otherwise it will succeed.
If `crlCheckSoftFail` is false, then an SSL failure can occur if the certificate revocation status cannot be checked (e.g. due to a network failure), as well as when
If ``crlCheckSoftFail`` is false, then an SSL failure can occur if the certificate revocation status cannot be checked (e.g. due to a network failure), as well as when
a certificate is revoked.
Older versions of Corda do not have CRL distribution points embedded in the SSL certificates.
As such, in order to be able to reuse node and SSL certificates generated in those versions of Corda, the `crlCheckSoftFail` needs
As such, in order to be able to reuse node and SSL certificates generated in those versions of Corda, the ``crlCheckSoftFail`` needs
to be set to true.
.. note::
Mitigation of this issue and thus being able to use the `strict` mode (i.e. with `crlCheckSoftFail` = false)
Mitigation of this issue and thus being able to use the ``strict`` mode (i.e. with ``crlCheckSoftFail = false``)
of the CRL checking with the certificates generated in previous versions of Corda is going to be added in the near future.