summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThien-Thi Nguyen <ttn@gnuvola.org>2020-12-04 04:49:32 -0500
committerThien-Thi Nguyen <ttn@gnuvola.org>2020-12-04 04:49:32 -0500
commit3cb2fdecfaa3193c42ca3648fb73df66810ce860 (patch)
tree2de6700a7ea73dce2bd77734b210554faad72bc1
parent97b8feb3e1ffd8839fc3b01015b7684a199bb17b (diff)
downloaddocs-3cb2fdecfaa3193c42ca3648fb73df66810ce860.tar.gz
docs-3cb2fdecfaa3193c42ca3648fb73df66810ce860.tar.bz2
docs-3cb2fdecfaa3193c42ca3648fb73df66810ce860.zip
use ‘.. code-block:: none’ (22 instances)
-rw-r--r--anastasis.rst14
-rw-r--r--core/wireformats.rst4
-rw-r--r--design-documents/007-payment.rst12
-rw-r--r--developers-manual.rst10
-rw-r--r--taler-merchant-manual.rst4
5 files changed, 22 insertions, 22 deletions
diff --git a/anastasis.rst b/anastasis.rst
index 1d34acd..9773e95 100644
--- a/anastasis.rst
+++ b/anastasis.rst
@@ -145,7 +145,7 @@ determined by an adversary performing a targeted attack, as a user's
likely also be available to other actors.
-::
+.. code-block:: none
kdf_id := Argon2( identifier, server_salt, keysize )
@@ -173,7 +173,7 @@ generate the corresponding public key. Here, "ver" is used as a salt for the
HKDF to ensure that the result differs from other cases where we hash
**kdf_id**.
-::
+.. code-block:: none
ver_secret := HKDF(kdf_id, "ver", keysize)
eddsa_priv := eddsa_d_to_a(ver_secret)
@@ -190,7 +190,7 @@ HKDF to ensure that the result differs from other cases where we hash
**eddsa_d_to_a()**: Function which converts the ver_key to a valid EdDSA private key. Specifically, assuming the value eddsa_priv is in a 32-byte array "digest", the function clears and sets certain bits as follows:
-::
+.. code-block:: none
digest[0] = (digest[0] & 0x7f) | 0x40;
digest[31] &= 0xf8;
@@ -208,7 +208,7 @@ symmetric key and an initialization vector (IV). To ensure that the
symmetric key changes for each encryption operation, we compute the
key material using an HKDF over a nonce and the kdf_id.
-::
+.. code-block:: none
(iv,key) := HKDF(kdf_id, nonce, keysize + ivsize)
@@ -248,7 +248,7 @@ the **key_share**. To ensure that the key derivation for the encryption
of the **recovery document** differs fundamentally from that of an
individual **key share**, we use different salts ("erd" and "eks" respectively).
-::
+.. code-block:: none
(iv0, key0) = HKDF(key_id, nonce0, "erd", keysize + ivsize)
(encrypted_recovery_document, aes_gcm_tag) = AES256_GCM(recovery_document, key0, iv0)
@@ -277,7 +277,7 @@ The EdDSA keys are used to sign the data sent from the client to the
server. Everything the client sends to server is signed. The following
algorithm is equivalent for **Anastasis-Policy-Signature**.
-::
+.. code-block:: none
(anastasis-account-signature) = eddsa_sign(h_body, eddsa_priv)
ver_res = eddsa_verifiy(h_body, anastasis-account-signature, eddsa_pub)
@@ -291,7 +291,7 @@ algorithm is equivalent for **Anastasis-Policy-Signature**.
When requesting policy downloads, the client must also provide a signature:
-::
+.. code-block:: none
(anastasis-account-signature) = eddsa_sign(version, eddsa_priv)
ver_res = eddsa_verifiy(version, anastasis-account-signature, eddsa_pub)
diff --git a/core/wireformats.rst b/core/wireformats.rst
index 33cda9c..2f1c964 100644
--- a/core/wireformats.rst
+++ b/core/wireformats.rst
@@ -23,7 +23,7 @@ fully test the Taler system without using "real" currencies. The URL
format for ``x-taler-bank`` is simple, in that it only specifies an account
number and the origin (domain and optionally a port) of the bank:
-::
+.. code-block:: none
payto://x-taler-bank/BANK_URI/ACCOUNT_IDENTIFIER
@@ -54,7 +54,7 @@ levied by the receiving bank.
For the merchant to receive deposits through SEPA, the deposit request must
follow the payto:// specification for SEPA:
-::
+.. code-block:: none
payto://sepa/IBAN
diff --git a/design-documents/007-payment.rst b/design-documents/007-payment.rst
index 9a16776..432816a 100644
--- a/design-documents/007-payment.rst
+++ b/design-documents/007-payment.rst
@@ -75,7 +75,7 @@ The merchant backend runs the following steps to generate the
2. If *order-ID* does not identify an existing order, return a 404 Not Found response. **Terminate**.
3. If *order-ID* identifies an order that is *unclaimed* and has claim token *claim-token*, return the URL
- ::
+ .. code-block:: none
{backendBaseUrl}/orders/{order-ID}?token={claim-token}&session_id={session-ID}
@@ -85,7 +85,7 @@ The merchant backend runs the following steps to generate the
5. If the order remains unpaid or was paid for a different *session-ID*, obtain the contract terms hash *contract-hash* and return the URL
- ::
+ .. code-block:: none
{backendBaseUrl}/orders/{order-ID}?h_contract={contract-hash}&session_id={session-ID}
@@ -94,7 +94,7 @@ The merchant backend runs the following steps to generate the
6. Here *order-ID* must now identify an order that is *paid* or *refunded*. Obtain the contract terms hash *contract-hash* and return the URL
- ::
+ .. code-block:: none
{backendBaseUrl}/orders/{order-ID}?h_contract={contract-hash}&session_id={session-ID}
@@ -117,7 +117,7 @@ The merchant backend runs the following steps to generate the HTML page for
2. If the order has granted refunds that have not been obtained by the wallet yet, prompt the URI
- ::
+ .. code-block:: none
taler{proto_suffix}://refund/{/merchant_prefix*}/{order-id}/{session-id}
@@ -138,7 +138,7 @@ The merchant backend runs the following steps to generate the HTML page for
2. Prompt the URI
- ::
+ .. code-block:: none
taler{proto_suffix}://pay/{/merchant_prefix*}/{order-id}/{session-ID}?c={claim-token}
@@ -163,7 +163,7 @@ The merchant backend runs the following steps to generate the HTML page for
4. Prompt the URI
- ::
+ .. code-block:: none
taler{proto_suffix}://pay/{/merchant_prefix*}/{order-id}/{session-ID}
diff --git a/developers-manual.rst b/developers-manual.rst
index 842fd39..9fddc8d 100644
--- a/developers-manual.rst
+++ b/developers-manual.rst
@@ -51,7 +51,7 @@ Code Repositories
Taler code is versioned with Git. For those users without write access, all the
codebases are found at the following URL:
-::
+.. code-block:: none
git://git.taler.net/<repository>
@@ -78,7 +78,7 @@ in the `Git book <https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Yo
If you have been granted write access, you first of all must change the URL of
the respective repository to:
-::
+.. code-block:: none
ssh://git@git.taler.net/<repository>
@@ -218,7 +218,7 @@ Tagging components
All Taler components must be tagged with git before they are deployed on the
``demo`` environment, using a tag of the following form:
-::
+.. code-block:: none
demo-YYYY-MM-DD-SS
YYYY = year
@@ -232,7 +232,7 @@ Environment Layout
Environments have the following layout:
-::
+.. code-block:: none
$HOME/
deployment (deployment.git checkout)
@@ -601,7 +601,7 @@ See https://www.gnu.org/prep/maintain/maintain.html#Automated-FTP-Uploads
Directive file:
-::
+.. code-block:: none
version: 1.2
directory: taler
diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst
index 8e9ff04..bff0e84 100644
--- a/taler-merchant-manual.rst
+++ b/taler-merchant-manual.rst
@@ -800,7 +800,7 @@ If everything worked as expected, the command
should return the message
- ::
+.. code-block:: none
Hello, I'm a merchant's Taler backend. This HTTP server is not for humans.
@@ -1245,7 +1245,7 @@ FIXME: add full example output.
In our example, the output for the wire transfer subject is:
-::
+.. code-block:: none
QPE24X8PBX3BZ6E7GQ5VAVHV32FWTTCADR0TRQ183MSSJD2CHNEG