[taler-docs] branch master updated: use ‘.. code-block:: none’ (22 instances)

[gnunet]

This is an automated email from the git hooks/post-receive script.

ttn pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 3cb2fde  use ‘.. code-block:: none’ (22 instances)
3cb2fde is described below

commit 3cb2fdecfaa3193c42ca3648fb73df66810ce860
Author: Thien-Thi Nguyen <ttn@gnuvola.org>
AuthorDate: Fri Dec 4 04:49:32 2020 -0500

    use ‘.. code-block:: none’ (22 instances)
---
 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 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
 

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.