diff options
| -rw-r--r-- | anastasis.rst | 4 | ||||
| -rw-r--r-- | developers-manual.rst | 6 | ||||
| -rw-r--r-- | taler-auditor-manual.rst | 6 | ||||
| -rw-r--r-- | taler-exchange-manual.rst | 4 | ||||
| -rw-r--r-- | taler-merchant-api-tutorial.rst | 6 | ||||
| -rw-r--r-- | taler-merchant-manual.rst | 8 | ||||
| -rw-r--r-- | taler-nfc-guide.rst | 2 |
7 files changed, 18 insertions, 18 deletions
diff --git a/anastasis.rst b/anastasis.rst index f7232c59..74d5160d 100644 --- a/anastasis.rst +++ b/anastasis.rst @@ -312,7 +312,7 @@ Anastasis server operators must be protected against denial-of-service attacks where an adversary attempts to exhaust operator's resources. The API protects against these attacks by allowing operators to set fees for all operations. Furthermore, all data stored comes with an expiration logic, so an -attacker cannot force servers to store data indefinitively. +attacker cannot force servers to store data indefinitely. A second availability issue arises from strong adversaries that may be able to compute the account keys of some user. While we assume that such an adversary @@ -484,7 +484,7 @@ In the following, UUID is always defined and used according to `RFC 4122`_. :status 200 OK: The escrow provider responds with an EncryptedRecoveryDocument_ object. :status 304 Not modified: - The client requested the same ressource it already knows. + The client requested the same resource it already knows. :status 400 Bad request: The $ACCOUNT_PUB is not an EdDSA public key. :status 402 Payment Required: diff --git a/developers-manual.rst b/developers-manual.rst index c5f5b771..22d205f0 100644 --- a/developers-manual.rst +++ b/developers-manual.rst @@ -965,7 +965,7 @@ Python for Scripting When using Python for writing small utilities, the following libraries are useful: -* ``click`` for argument parsing (should be prefered over argparse) +* ``click`` for argument parsing (should be preferred over argparse) * ``pathlib`` for path manipulation (part of the standard library) * ``subprocess`` for "shelling out" to other programs. Prefer ``subprocess.run`` over the older APIs. @@ -1314,7 +1314,7 @@ use when talking to end users or even system administrators. relative time method of keeping time in :term:`GNUnet` where the time is represented as a relative number of microseconds. Thus, a relative time specifies - an offet or a duration, but not a date. Called relative time in + an offset or a duration, but not a date. Called relative time in contrast to :term:`absolute time`. recoup @@ -1334,7 +1334,7 @@ use when talking to end users or even system administrators. making a payment with :term:`coins` to a :term:`merchant`. privacy policy - Statment of an operator how they will protect the privacy of users. + Statement of an operator how they will protect the privacy of users. proof Message that cryptographically demonstrates that a particular claim is correct. diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst index 1d84d45d..35f5a799 100644 --- a/taler-auditor-manual.rst +++ b/taler-auditor-manual.rst @@ -127,7 +127,7 @@ components: fail to be imported due to constraint violations, this is an immediate serious concern that must be addressed manually. The software only verifies the content of a well-formed exchange database (well-formed with respect to SQL). - For now, the GNU Taler reference implemenation + For now, the GNU Taler reference implementation only supports Postgres, but the code could be easily extended to support another DBMS. @@ -387,7 +387,7 @@ the exchange operator obtains a *blob* with the data about denomination keys that the exchange operator needs to get signed by every auditor the exchange wishes (or is forced to) work with. -In a normal scenario, an auditor must have some secure business proces to +In a normal scenario, an auditor must have some secure business process to receive the blob to sign (Website, manual delivery, ...). Note that the blob does not contain confidential data, but signing the wrong keys would be fatal. Given the blob, the auditor would sign it using: @@ -596,7 +596,7 @@ Auditor implementation guide The auditor implementation is split into five main processes, called ``taler-helper-auditor-XXX``. The split was done to realize the principle of -least priviledge and to enable independent logic to be possibly run in +least privilege and to enable independent logic to be possibly run in parallel. Only the taler-wire-auditor must have (read-only) access to the exchange's bank account, the other components only need access to the database. diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst index 6e4bae85..b156eb90 100644 --- a/taler-exchange-manual.rst +++ b/taler-exchange-manual.rst @@ -914,7 +914,7 @@ TALER_SIGNATURE_AUDITOR_EXCHANGE_KEYS purpose. .. [2] The current implementation does not make provisions for secret splitting. Still, the use of a hardware security module (HSM) for - protecting private keys is adviseable, so please contact the + protecting private keys is advisable, so please contact the developers for HSM integration support. .. [3] @@ -937,7 +937,7 @@ and clients, or only launch the parallel clients (``-m``), for example for distributed testing over a network. For each *parallel* (``-p``) client, a number of *reserves* (``-r``) is first established by -**transfering** money from a "user" account (42) to the Exchange's account +**transferring** money from a "user" account (42) to the Exchange's account with the respective reserve public key as wire subject. Next, the client will **withdraw** a *number of coins* (``-n``) from the reserve and **deposit** them. Additionally, a *fraction* (``-R``) of the dirty coins will then be diff --git a/taler-merchant-api-tutorial.rst b/taler-merchant-api-tutorial.rst index 39cf36da..823a6756 100644 --- a/taler-merchant-api-tutorial.rst +++ b/taler-merchant-api-tutorial.rst @@ -377,7 +377,7 @@ are recognized in the JSON request object: - amount: Amount that should be given to the visitor as a tip. - instance: Merchant instance that grants the tip (each instance may - have its own independend tipping funds configured). + have its own independent tipping funds configured). - justification: Description of why the tip was granted. Human-readable text not exposed to the customer, but used by the Back Office. @@ -533,14 +533,14 @@ signature (``session_sig``). This signature certifies that the wallet showed a payment receipt for the respective order in the current session. cookie -Session-bound payments are triggerd by passing the ``session_id`` +Session-bound payments are triggered by passing the ``session_id`` parameter to the ``/check-payment`` endpoint. The wallet will then redirect to the fulfillment page, but include an additional ``session_sig`` parameter. The frontend can query ``/check-payment`` with both the ``session_id`` and the ``session_sig`` to verify that the signature is correct. -The last session ID that was successfuly used to prove that the payment +The last session ID that was successfully used to prove that the payment receipt is in the user’s wallet is also available as ``last_session_id`` in the response to ``/check-payment``. diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst index 6d148068..1e6e72a1 100644 --- a/taler-merchant-manual.rst +++ b/taler-merchant-manual.rst @@ -87,7 +87,7 @@ components: to process financial transactions with Taler. This manual primarily describes how to install and configure this backend. - A DBMS which stores the transaction history for the Taler backend. - For now, the GNU Taler reference implemenation only supports + For now, the GNU Taler reference implementation only supports Postgres, but the code could be easily extended to support another DBMS. Please review the Postgres documentation for details on how to configure the database. @@ -1100,7 +1100,7 @@ in a special “402 Payment Required” response inside the ``X-Taler-Tip`` header. The frontend should handle errors returned by the backend, such as -missconfigured instances or a lack of remaining funds for tipping. +misconfigured instances or a lack of remaining funds for tipping. .. _Picking-up-of-the-tip: @@ -1336,7 +1336,7 @@ second gives the chance to leave some payments unaggregated, and also to use merchant instances other than the default (which is, actually, the one used by default by the tool). -Note: the abilty of driving the aggregation policy is useful for testing +Note: the ability of driving the aggregation policy is useful for testing the backoffice facility. Any subcommand is also equipped with the canonical ``--help`` option, so @@ -1410,7 +1410,7 @@ layout: [PAYMENTS-GENERATOR] # The exchange used during the test: make sure the merchant backend - # being tested accpets this exchange. + # being tested accepts this exchange. # If the sysadmin wants, she can also install a local exchange # and test against it. EXCHANGE = https://exchange.demo.taler.net/ diff --git a/taler-nfc-guide.rst b/taler-nfc-guide.rst index 88fa13d5..81433878 100644 --- a/taler-nfc-guide.rst +++ b/taler-nfc-guide.rst @@ -241,7 +241,7 @@ NFC. In particular, only JSON request and response bodies are allowed. It is currently assumed that the requests and responses fit into one APDU frame. For devices with more limited maximum APDU sizes, additional TIDs for segmented -tunnel requests/responsed may be defined in the future. +tunnel requests/responses may be defined in the future. A request for tunneling is initiated with TID ``0x03`` and responded to with TID ``0x02`` (see tables above). A tunneling request is identified by a |