From 3cb2fdecfaa3193c42ca3648fb73df66810ce860 Mon Sep 17 00:00:00 2001 From: Thien-Thi Nguyen Date: Fri, 4 Dec 2020 04:49:32 -0500 Subject: use ‘.. code-block:: none’ (22 instances) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- anastasis.rst | 14 +++++++------- core/wireformats.rst | 4 ++-- design-documents/007-payment.rst | 12 ++++++------ developers-manual.rst | 10 +++++----- taler-merchant-manual.rst | 4 ++-- 5 files changed, 22 insertions(+), 22 deletions(-) diff --git a/anastasis.rst b/anastasis.rst index 1d34acd4..9773e959 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 33cda9cf..2f1c9647 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 9a16776d..432816a0 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 842fd39d..9fddc8d9 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/ @@ -78,7 +78,7 @@ in the `Git book @@ -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 8e9ff045..bff0e84d 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 -- cgit v1.2.3