use ‘.. code-block:: none’ (22 instances)

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/<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 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