diff options
Diffstat (limited to 'texinfo')
| -rw-r--r-- | texinfo/taler-auditor.texi | 190 | ||||
| -rw-r--r-- | texinfo/taler-bank.texi | 4 | ||||
| -rw-r--r-- | texinfo/taler-developer-manual.texi | 210 | ||||
| -rw-r--r-- | texinfo/taler-exchange.texi | 44 | ||||
| -rw-r--r-- | texinfo/taler-merchant-api-tutorial.texi | 10 | ||||
| -rw-r--r-- | texinfo/taler-merchant.texi | 91 |
6 files changed, 279 insertions, 270 deletions
diff --git a/texinfo/taler-auditor.texi b/texinfo/taler-auditor.texi index 4a99aed8..fb41a174 100644 --- a/texinfo/taler-auditor.texi +++ b/texinfo/taler-auditor.texi @@ -21,7 +21,7 @@ @copying @quotation -GNU Taler 0.8.0pre0, Aug 03, 2021 +GNU Taler 0.8.2, Aug 08, 2021 GNU Taler team @@ -102,7 +102,7 @@ Configuration * Using taler-config:: * Initial configuration:: * Keys:: -* Configuring the auditor's REST endpoint:: +* Configuring the auditor’s REST endpoint:: * Bank account:: * Database:: @@ -129,7 +129,7 @@ Operation Auditor implementation guide -* The auditor's database:: +* The auditor’s database:: * Invariants checked by the auditor:: * Testing the auditor:: @@ -197,7 +197,7 @@ to other parties. To perform this duty, you will need at least (read-only) access to the bank transactions of the exchange, as well as a continuously synchronized replica -of the exchange's database. The general assumption for running the auditor +of the exchange’s database. The general assumption for running the auditor is that this is done on a separate system controlled by the auditor. After all, the goal is to detect nerfarious activity of the exchange operator, which cannot be effectively done on a machine controlled by the exchange @@ -209,9 +209,9 @@ withdrawals made by consumers and income received by merchants. As a result, the auditor is expected to provide high confidentiality for the database. In general, the auditor does not have to offer high-availability: the exchange operator can continue operations without the auditor, and the auditor can -catch up with it later when the auditor's systems are restored. However, of +catch up with it later when the auditor’s systems are restored. However, of course any downtime would provide a window of opportunity for fraud and should -thus be minimized. Finally, the auditor's copy of the exchange's database can +thus be minimized. Finally, the auditor’s copy of the exchange’s database can be useful as a backup to the exchange in case the exchange experiences a loss of its own copies. Thus, business agreements between auditor and exchanges may include availability requirements as well. @@ -219,7 +219,7 @@ include availability requirements as well. Then, with the software provided, auditors can verify the cryptographic proofs collected by the exchange and detect if any improper bank transactions have been made. There are additional tasks which an auditor should perform. While this -manual only focuses on the audit of the exchange's database and wire transfers +manual only focuses on the audit of the exchange’s database and wire transfers with the existing tools, a proper auditor should also perform the following tasks: @@ -245,7 +245,7 @@ verification that the exchange properly implements the @code{/link} protocol @item verification that the exchange properly reports coins issued during the refresh protocol (by irregularly refreshing coins withdrawn by -the auditor and comparing against the exchange's database --- the +the auditor and comparing against the exchange’s database — the code required to support this is not yet implemented) @end itemize @@ -266,8 +266,8 @@ oversight function. Auditors should generally be independent third parties that verify that the exchange operates correctly. However, an exchange is likely to also run the auditing logic, as it is also used to calculate the exchange’s profits, risk -and liabilities. Furthermore, it's usually a good idea to not only rely on -third parties to verify one's own work. +and liabilities. Furthermore, it’s usually a good idea to not only rely on +third parties to verify one’s own work. The Taler software stack for an auditor consists of the following components: @@ -299,7 +299,7 @@ the auditor to detect if an exchange is underreporting deposits. In the future, the Web service should be extended to allow customers and merchants to automatically upload cryptographic proof of other violations of the specification by the exchange. However, for now it is assumed that -the respective cryptographic proofs are reported and verified manually --- +the respective cryptographic proofs are reported and verified manually — as with a well-behaved exchange this should obviously be a rare event. The main binary of this component is the @code{taler-auditor-httpd}. @@ -319,7 +319,7 @@ needs access to the wire gateway). The @code{taler-helper-auditor-wire} auditor verifies that the bank transactions performed by the exchange were done properly. This component must have access to the bank account -of the exchange, as well as to a copy of the exchange's database. +of the exchange, as well as to a copy of the exchange’s database. The @code{taler-auditor} script invokes the various helpers, each generating a JSON report. It then invokes the @code{taler-helper-auditor-render.py} @@ -594,22 +594,22 @@ is not recommended for security. The recommended set of users includes: @itemize * @item -auditor --- runs the main auditing process and HTTP backend +auditor — runs the main auditing process and HTTP backend @item -sync --- synchronizes the ingres database with the production database +sync — synchronizes the ingres database with the production database @item -helper --- runs taler-auditor-offline download and upload commands +helper — runs taler-auditor-offline download and upload commands @item -auditor-ingres --- imports database from exchange production system +auditor-ingres — imports database from exchange production system @item -auditor-wire --- imports wire transfer data from bank production system +auditor-wire — imports wire transfer data from bank production system @item -offline --- manages the offline key, on a separate @emph{offline} machine +offline — manages the offline key, on a separate @emph{offline} machine @end itemize @end quotation @@ -629,10 +629,10 @@ distribution would typically create for you): @itemize * @item -www-data --- runs the HTTPS frontend (usually nginx or Apache) +www-data — runs the HTTPS frontend (usually nginx or Apache) @item -postgres --- runs the Postgres database +postgres — runs the Postgres database @end itemize @end quotation @@ -649,16 +649,16 @@ We recommend using the following databases for the auditor: @itemize * @item -exchange-ingres --- synchronized exchange database over the network +exchange-ingres — synchronized exchange database over the network @item -exchange-production --- local copy of exchange database with trusted schema +exchange-production — local copy of exchange database with trusted schema @item -auditor --- auditor production database with current state of the audit +auditor — auditor production database with current state of the audit @item -libeufin --- local state of the auditor-wire tool for the bank transfer data import +libeufin — local state of the auditor-wire tool for the bank transfer data import @end itemize @end quotation @@ -690,7 +690,7 @@ $ echo 'GRANT SELECT ON ALL TABLES IN SCHEMA public TO auditor;' | psql libeufin @chapter Configuration -The auditor's configuration works the same way as the configuration of other +The auditor’s configuration works the same way as the configuration of other Taler components. This section discusses configuration options related to the auditor. @@ -699,7 +699,7 @@ This section discusses configuration options related to the auditor. * Using taler-config:: * Initial configuration:: * Keys:: -* Configuring the auditor's REST endpoint:: +* Configuring the auditor’s REST endpoint:: * Bank account:: * Database:: @@ -848,9 +848,9 @@ $ taler-config -s auditor -o BASE_URL -V https://auditor.example.com/ The @code{helper} user that is used to download information from the exchange needs to know details about the exchange. Similarly, the @code{offline} user -needs to check signatures signed with the exchange's offline key. Hence, you +needs to check signatures signed with the exchange’s offline key. Hence, you need to obtain the @code{MASTER_PUBLIC_KEY} from the exchange operator (they need -to run taler-exchange-offline setup) and the REST endpoint of the exchange +to run @code{taler-exchange-offline setup}) and the REST endpoint of the exchange and configure these: @example @@ -859,14 +859,14 @@ $ taler-config -s exchange -o BASE_URL -V https://exchange.example.com/ $ taler-config -s exchange -o MASTER_PUBLIC_KEY -V $SOMELONGBASE32VALUEHERE @end example -@node Keys,Configuring the auditor's REST endpoint,Initial configuration,Configuration +@node Keys,Configuring the auditor’s REST endpoint,Initial configuration,Configuration @anchor{taler-auditor-manual auditorkeys}@anchor{13}@anchor{taler-auditor-manual keys}@anchor{14} @section Keys The auditor works with one signing key to certify that it is auditing -a particular exchange's denomination keys. This key can and should -be kept @emph{offline} (and backed up adequately). As with the exchange's +a particular exchange’s denomination keys. This key can and should +be kept @emph{offline} (and backed up adequately). As with the exchange’s offline key, it is only used for a few cryptographic signatures and thus the respective code can be run on modest hardware, like a Raspberry Pi. @@ -897,12 +897,8 @@ of the @code{auditor} user in the @code{[auditor]]} configuration section: @item @code{PUBLIC_KEY}: Public key of the auditor, in Base32 encoding. -@end itemize - -@quotation - Set from value printed by @code{taler-auditor-offline setup}. -@end quotation +@end itemize You can set this configuration value using: @@ -911,9 +907,9 @@ You can set this configuration value using: $ taler-config -s auditor -o PUBLIC_KEY -V $SOMELONGBASE32VALUEHERE @end example -@node Configuring the auditor's REST endpoint,Bank account,Keys,Configuration +@node Configuring the auditor’s REST endpoint,Bank account,Keys,Configuration @anchor{taler-auditor-manual auditorserving}@anchor{15}@anchor{taler-auditor-manual configuring-the-auditor-s-rest-endpoint}@anchor{16} -@section Configuring the auditor's REST endpoint +@section Configuring the auditor’s REST endpoint The auditor can serve HTTP over both TCP and UNIX domain socket. @@ -939,7 +935,7 @@ HTTP over a UNIX domain socket for @code{unixpath} (i.e. 660 = @code{rw-rw----}). @end itemize -@node Bank account,Database,Configuring the auditor's REST endpoint,Configuration +@node Bank account,Database,Configuring the auditor’s REST endpoint,Configuration @anchor{taler-auditor-manual auditorbank-account}@anchor{17}@anchor{taler-auditor-manual bank-account}@anchor{18} @section Bank account @@ -982,14 +978,14 @@ CONFIG = postgres:///auditordemo If an exchange runs its own auditor, it may use the same database for the auditor and the exchange itself. -The @code{taler-auditor-dbinit} tool is used to initialize the auditor's +The @code{taler-auditor-dbinit} tool is used to initialize the auditor’s tables. After running this tool, the rights to CREATE or DROP tables are no longer required and should be removed. Both the @code{taler-auditor-httpd} and the @code{taler-auditor} (and its helpers) also need (read-only) access to a (recent, current, synchronized) copy of the -exchange's database. The configuration options are the same that are also -used when configuring the exchange' database: +exchange’s database. The configuration options are the same that are also +used when configuring the exchange’ database: @quotation @@ -1010,7 +1006,7 @@ CONFIG = postgres:///exchangedemo @anchor{taler-auditor-manual wallets}@anchor{1d} Before GNU Taler wallets will happily interact with an exchange, the -respective auditor's public key (as obtained via @code{taler-auditor-offline +respective auditor’s public key (as obtained via @code{taler-auditor-offline setup} from the @code{offline} user) must be added under the respective currency to the wallet. This is usually expected to be hard-coded into the Taler wallet. @@ -1018,7 +1014,7 @@ wallet. Users can also manually add auditors for a particular currency via a Web page offering the respective pairing. -FIXME-DOLD: explain how that Web page works, once it works... +FIXME-DOLD: explain how that Web page works, once it works… @menu * Exchange:: @@ -1032,13 +1028,13 @@ FIXME-DOLD: explain how that Web page works, once it works... @section Exchange -The next step is to add the exchange's master public key and the base URL of +The next step is to add the exchange’s master public key and the base URL of the exchange to the list of exchanges audited by the auditor. This is done using the @code{taler-auditor-exchange} tool. The tool basically creates the -respective record in the auditor's database. +respective record in the auditor’s database. If this step is skipped, the auditor will malfunction at all future stages -with a foreign key violation, as it does not know the exchange's master public +with a foreign key violation, as it does not know the exchange’s master public key. @example @@ -1048,7 +1044,7 @@ $ taler-auditor-exchange -m $MASTER_PUB -u $EXCHANGE_BASE_URL An equivalent step must be performed by the exchange operator. Here, the exchange operator must use the @code{taler-exchange-offline} tool to add the -auditor's public key, base URL and (business) name to the list of approved +auditor’s public key, base URL and (business) name to the list of approved auditors of the exchange. For details, see Auditor-configuration in the exchange operator manual. @@ -1086,7 +1082,7 @@ process that is outside of the scope of this document. Note that the @code{input.json} does not contain any confidential data. However, signing the wrong keys would be fatal in that it may allow an illegitimate exchange to convince users that it is a trustworthy operator and subsequently -betray the user's trust that is anchored in the existence of a trustworthy +betray the user’s trust that is anchored in the existence of a trustworthy auditor. Given the verified JSON input, the auditor can then sign it (typically @@ -1121,21 +1117,21 @@ command-line option, send logging output to standard error by default. The next key step for the auditor is to configure replication of the -@emph{exchange}'s database in-house. This should be performed in two steps +@emph{exchange}’s database in-house. This should be performed in two steps as illustrated in the following figure: @image{taler-auditor-figures/replication,,,,png} First, the exchange should use standard Postgres replication features to -enable the auditor to obtain a full copy of the exchange's database. -Second, the auditor should make a "trusted" local copy, ensuring that it +enable the auditor to obtain a full copy of the exchange’s database. +Second, the auditor should make a “trusted” local copy, ensuring that it never replicates malicious changes using @code{taler-auditor-sync}. Both of these steps are described in more detail below. We note that as a result of these steps, the auditor will have three databases: its own production primary database (as configured in -@code{auditordb-postgres}), its on production copy of the exchange's database -(@code{exchangedb-postgress}), and a third, untrusted "ingres" copy of the +@code{auditordb-postgres}), its on production copy of the exchange’s database +(@code{exchangedb-postgress}), and a third, untrusted “ingres” copy of the exchange database. The untrusted database should run as a separate Postgres instance and is only accessed via @code{taler-auditor-sync} and the replication mechanism driven by the exchange operator. @@ -1151,7 +1147,7 @@ mechanism driven by the exchange operator. @subsection Ingres replication of the exchange production database -Ingres operation should be done using the @code{auditor-ingres} user --- or +Ingres operation should be done using the @code{auditor-ingres} user — or depending on the setup parts of the operation may be done by the @code{postgres} user directly. @@ -1164,10 +1160,10 @@ that asynchronous replication should suffice. The resulting auditor database should be treated as read-only on the auditor side. The @code{taler-exchange-dbinit} tool can be used to setup the schema, or -the schema can be replicated using Postgres's standard mechanisms. The same +the schema can be replicated using Postgres’s standard mechanisms. The same applies for schema upgrades: if logical replication is used (which does not replicate schema changes), @code{taler-exchange-dbinit} can be used to migrate -the schema(s) in both the ingres and production copies of the exchange's +the schema(s) in both the ingres and production copies of the exchange’s database as well. On the exchange side, a database user must be created that has the right @@ -1181,7 +1177,7 @@ $ echo "CREATE PUBLICATION $NAME FOR ALL TABLES;" | psql taler-exchange @end example The exchange must share the password of the publication with the auditor. A -good @code{$NAME} relates to the auditor's buisness unit name. A secure tunnel +good @code{$NAME} relates to the auditor’s buisness unit name. A secure tunnel must be setup between the exchange and the auditor, for example using SSH or Wireguard. @@ -1204,7 +1200,7 @@ Postgres configuaration: wal_level= logical @end example -Next, the @code{postgres} user of the auditor's system must first initialize the +Next, the @code{postgres} user of the auditor’s system must first initialize the local tables: @example @@ -1214,7 +1210,7 @@ $ taler-config -s exchangedb-postgres -o CONFIG -V "postgres:///taler-ingress" $ taler-exchange-dbinit @end example -To complete the replication, the @code{postgres} user of the auditor's +To complete the replication, the @code{postgres} user of the auditor’s system must subscribe: @example @@ -1231,7 +1227,7 @@ For details, we refer to the Postgres manual. Depending on the replication method used, the exchange may perform unexpected changes to the schema or perform @code{UPDATE}, @code{DELETE} or @code{DROP} operations on the tables. Hence, the auditor cannot rely upon the -exchange's primary copy to respect schema constraints, especially as we +exchange’s primary copy to respect schema constraints, especially as we have to presume that the exchange could act maliciously. Furthermore, it is unclear to what degree Postgres database replication mechanisms are robust against a malicious master database. Thus, the auditor should @@ -1246,20 +1242,20 @@ process, from its actual operational data. Using @code{taler-auditor-sync} as the @code{sync} user, the auditor should -make a second "safe" copy of the exchange's ingres database. +make a second “safe” copy of the exchange’s ingres database. @code{taler-auditor-sync} basically reads from one exchange database and inserts all records found into a second exchange database. If the source database violates invariants, the tool halts with an error. This way, records violating invariants are never even copied, and in particular schema changes and -deletions or updates are not propagated into the auditor's production +deletions or updates are not propagated into the auditor’s production database. While @code{taler-auditor-sync} could in theory be run directly against the -exchange's production system, this is likely a bad idea due to the high +exchange’s production system, this is likely a bad idea due to the high latency from the network between auditor and exchange operator. Thus, we -recommend first making an "untrusted" ingress copy of the exchange's +recommend first making an “untrusted” ingress copy of the exchange’s production database using standard Postgres tooling, and then using -@code{taler-auditor-sync} to create a second "safe" copy. The "safe" copy used +@code{taler-auditor-sync} to create a second “safe” copy. The “safe” copy used by the production system should also run under a different UID. Before @code{taler-auditor-sync} can be used, the target database must be @@ -1291,11 +1287,11 @@ $ taler-auditor-sync -s src.conf -d dst.cfg -t When the exchange performs garbage collection to @code{DELETE} obsolete records, this change should be automatically replicated to the auditors untrusted -ingress database. However, as @code{taler-auditor-sync} tries to be "safe", -it will not replicate those deletions to the auditor's production database. +ingress database. However, as @code{taler-auditor-sync} tries to be “safe”, +it will not replicate those deletions to the auditor’s production database. Thus, it is necessary to (occasonally) run @code{taler-exchange-dbinit -g} on -the auditor's production database to garbage collect old data in the -auditor's production copy. We note that this does not have to be done +the auditor’s production database to garbage collect old data in the +auditor’s production copy. We note that this does not have to be done at the same time when the exchange runs its garbage collection. @node Operation,Auditor implementation guide,Deployment,Top @@ -1321,7 +1317,7 @@ at the same time when the exchange runs its garbage collection. The @code{taler-auditor-httpd} runs the required REST API for the auditor. The service must have @code{INSERT} (and @code{SELECT}) rights on the -@code{deposit_confirmations} table in the auditor's database. We expect that in +@code{deposit_confirmations} table in the auditor’s database. We expect that in future versions additional rights may be required. For now, we recommend simply running the @code{taler-auditor-httpd} under the @@ -1371,7 +1367,7 @@ anymore), this is not recommended in a production setup. @section Reading the report -The auditor's report needs to be read carefully, as it includes +The auditor’s report needs to be read carefully, as it includes several categories of failures of different severity: @@ -1437,14 +1433,14 @@ completing a @code{taler-audit} run against the old schema @item migrating the exchange schema (@code{taler-exchange-dbinit}) of the master database, possibly the ingres database and the -auditor's production copy +auditor’s production copy @item migrating the auditor database (@code{taler-auditor-dbinit}) @item -resuming database replication between the exchange's master -database and the auditor's ingres copy +resuming database replication between the exchange’s master +database and the auditor’s ingres copy @item resuming @code{taler-auditor-sync} @@ -1489,7 +1485,7 @@ For more information, see Revocations in the exchange operator manual. If all denominations of an exchange are revoked, the exchange includes logic to wire back all returned funds to the bank accounts from which they originate. If some denominations remain operational, wallets will generally -exchange old coins of revoked denominations for new coins -- while providing +exchange old coins of revoked denominations for new coins – while providing additional information to demonstrate that these coins were not forged from the compromised private key but obtained via a legitimate withdraw operation. @@ -1498,12 +1494,12 @@ the compromised private key but obtained via a legitimate withdraw operation. @section Failures -Most audit failures are handled by the auditor's regular reporting functionality, +Most audit failures are handled by the auditor’s regular reporting functionality, creating a (hopefully descriptive) PDF report detailing the problems found. However, there is one category of errors where this is not possible, which -concerns arithmetic overflows for amounts. Taler's specification limits amount -values to at most 2^52. If, during the auditor's calculations, amounts are +concerns arithmetic overflows for amounts. Taler’s specification limits amount +values to at most 2^52. If, during the auditor’s calculations, amounts are encountered that exceed this threshold, the auditor will not generate a regular report, but instead write a log statement explaining where the problem happened and exit with a status code of @emph{42}. @@ -1535,15 +1531,15 @@ The auditor implementation is split into five main processes, called @code{taler-helper-auditor-XXX}. The split was done to realize the principle of 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 +exchange’s bank account, the other components only need access to the database. All auditor subsystems basically start their audit from a certain transaction index (@code{BIG SERIAL}) in the auditor database which identifies where the last audit concluded. They then check that the transactions claimed in the -exchange's database match up internally, including the cryptographic +exchange’s database match up internally, including the cryptographic signatures and also with respect to amounts adding up. The auditor also -calculates the exchange's profits and expected bank balances. Once all +calculates the exchange’s profits and expected bank balances. Once all existing transactions are processed, the auditor processes store the current checkpoint in its database and generate a JSON report. @@ -1552,22 +1548,22 @@ uses Jinja2 with a TeX template to convert the five individual JSON reports into LaTeX and then into PDF. @menu -* The auditor's database:: +* The auditor’s database:: * Invariants checked by the auditor:: * Testing the auditor:: @end menu -@node The auditor's database,Invariants checked by the auditor,,Auditor implementation guide +@node The auditor’s database,Invariants checked by the auditor,,Auditor implementation guide @anchor{taler-auditor-manual the-auditor-s-database}@anchor{34} -@section The auditor's database +@section The auditor’s database The database scheme used by the exchange looks as follows: @image{taler-auditor-figures/auditor-db,,,,png} -@node Invariants checked by the auditor,Testing the auditor,The auditor's database,Auditor implementation guide +@node Invariants checked by the auditor,Testing the auditor,The auditor’s database,Auditor implementation guide @anchor{taler-auditor-manual invariants-checked-by-the-auditor}@anchor{35} @section Invariants checked by the auditor @@ -1592,7 +1588,7 @@ pass where it might seem applicable. @subsection Invariants checked by the taler-helper-auditor-aggregation -This is from CodeBlau's analysis. A proper write-up is pending. +This is from CodeBlau’s analysis. A proper write-up is pending. CodeBlau reports the following checks: @@ -1704,7 +1700,7 @@ wire fee unavailable for given time @subsection Invariants checked by the taler-helper-auditor-coins -This is from CodeBlau's analysis. A proper write-up is pending. +This is from CodeBlau’s analysis. A proper write-up is pending. CodeBlau reports the following checks: @@ -1712,9 +1708,9 @@ CodeBlau reports the following checks: @item check that all denominations used by the exchange have been signed using -this auditor's key. All denominations encountered in the database that +this auditor’s key. All denominations encountered in the database that this auditor did not officially sign for are reported (but still included -in the audit as they obviously may impact the exchange's bank balance). +in the audit as they obviously may impact the exchange’s bank balance). Depending on the business situation, this may be normal (say if an exchange is changing auditors and newer denominations are no longer supported until their end-of-life by the current auditor). @@ -1810,7 +1806,7 @@ merchants by simply not reporting deposits to the auditor. @subsection Invariants checked by the taler-helper-auditor-reserves -This is from CodeBlau's analysis. A proper write-up is pending. +This is from CodeBlau’s analysis. A proper write-up is pending. CodeBlau reports the following checks: @@ -1872,11 +1868,11 @@ target account does not match origin account This auditor is special in that it is the only pass that is required to have -@emph{read-only} access to the exchange's bank account (privilege separation). Its -main role is to verify that the wire transfers in the exchange's database and +@emph{read-only} access to the exchange’s bank account (privilege separation). Its +main role is to verify that the wire transfers in the exchange’s database and those reported by the bank are identical. -This is from CodeBlau's analysis. A proper write-up is pending. +This is from CodeBlau’s analysis. A proper write-up is pending. CodeBlau reports the following checks: @@ -1938,7 +1934,7 @@ closing fee above total amount The main objective of the auditor is to detect inconsistencies. Thus, the @code{test-auditor.sh} script deliberately introduces various inconsistencies into -a synthetic exchange database. For this, an "normal" exchange database is +a synthetic exchange database. For this, an “normal” exchange database is first generated using the @code{taler-wallet-cli}. Then, various fields or rows of that database are manipulated, and the auditor is let loose on the modified database. Afterwards, the test verifies that the JSON contains values @@ -1951,13 +1947,13 @@ cover as many code paths as possible in both the exchange and the auditor. It should also ideally create all interesting possible variations of the exchange database fields (within the constraints of the database schema). -In general, @code{test-auditor.sh} runs the tests against an "old" database where +In general, @code{test-auditor.sh} runs the tests against an “old” database where some transactions are past the due-date (and hence the aggregator would trigger wire transfers), as well as a freshly generated exchange database where the auditor would not perform any transfers. Auditor interactions can be made before or after the aggregator, depending on what is being tested. -The current script also rudimentarily tests the auditor's resume logic, +The current script also rudimentarily tests the auditor’s resume logic, by re-starting the auditor once against a database that the auditor has already seen. diff --git a/texinfo/taler-bank.texi b/texinfo/taler-bank.texi index 15959e1a..1a90b590 100644 --- a/texinfo/taler-bank.texi +++ b/texinfo/taler-bank.texi @@ -21,7 +21,7 @@ @copying @quotation -GNU Taler 0.8.0pre0, Aug 03, 2021 +GNU Taler 0.8.2, Aug 08, 2021 GNU Taler team @@ -152,8 +152,8 @@ interface BankRegistrationRequest @{ password: string; @} @end example -@anchor{8}@w{ } @anchor{taler-bank-manual tsref-type-BankRegistrationRequest}@w{ } +@anchor{8}@w{ } @c %**end of body @bye diff --git a/texinfo/taler-developer-manual.texi b/texinfo/taler-developer-manual.texi index 26be432a..4896a6ff 100644 --- a/texinfo/taler-developer-manual.texi +++ b/texinfo/taler-developer-manual.texi @@ -21,7 +21,7 @@ @copying @quotation -GNU Taler 0.8.0pre0, Aug 03, 2021 +GNU Taler 0.8.2, Aug 08, 2021 GNU Taler team @@ -103,13 +103,13 @@ Wallet: [ ] build wallet @item -[ ] verify wallet works against 'test.taler.net' +[ ] verify wallet works against ‘test.taler.net’ @item [ ] tag repo. @item -[ ] upgrade 'demo.taler.net' to 'test.taler.net' +[ ] upgrade ‘demo.taler.net’ to ‘test.taler.net’ @item [ ] upload new wallet release to app store @@ -133,7 +133,7 @@ For exchange: @itemize - @item -[ ] check no compiler warnings at "-Wall" +[ ] check no compiler warnings at “-Wall” @item [ ] ensure Coverity static analysis passes @@ -142,10 +142,10 @@ For exchange: [ ] make check. @item -[ ] upgrade 'demo.taler.net' to 'test.taler.net' +[ ] upgrade ‘demo.taler.net’ to ‘test.taler.net’ @item -[ ] make dist, make check on result of 'make dist'. +[ ] make dist, make check on result of ‘make dist’. @item [ ] Change version number in configure.ac. @@ -178,7 +178,7 @@ For merchant (C backend): @itemize - @item -[ ] check no compiler warnings at "-Wall" +[ ] check no compiler warnings at “-Wall” @item [ ] ensure Coverity static analysis passes @@ -187,10 +187,10 @@ For merchant (C backend): [ ] make check. @item -[ ] upgrade 'demo.taler.net' to 'test.taler.net' +[ ] upgrade ‘demo.taler.net’ to ‘test.taler.net’ @item -[ ] make dist, make check on result of 'make dist'. +[ ] make dist, make check on result of ‘make dist’. @item [ ] Change version number in configure.ac. @@ -411,7 +411,7 @@ A complete list of all the existing repositories is currently found at Before you can obtain Git write access, you must sign the copyright agreement. As we collaborate closely with GNUnet, we use their -copyright agreement -- with the understanding that your contributions +copyright agreement – with the understanding that your contributions to GNU Taler are included in the assignment. You can find the agreement on the GNUnet site@footnote{https://gnunet.org/en/copyright.html}. Please sign and mail it to Christian Grothoff as he currently collects @@ -582,7 +582,7 @@ user can be switched to become active (see next section), and vice versa. Upgrading the @code{demo} environment should be done with care, and ideally be coordinated on the mailing list before. It is our goal for @code{demo} to always -run a "working version" that is compatible with various published wallets. +run a “working version” that is compatible with various published wallets. Before deploying on @code{demo}, the same version of all components @strong{must} be deployed @emph{and} tested on @code{int}. @@ -752,7 +752,7 @@ The WORKER is the config that that lives on a shell account on a localhost (tale The WORKER running buildbot-worker receives these commands by authenticating and communicating with the buildbot server using parameters that were specified when the worker was created in that shell account with the @code{buildbot-worker} command. @item -The buildbot server's master.cfg file contains FACTORY declarations which specify the commands that the WORKER will run on localhost. +The buildbot server’s master.cfg file contains FACTORY declarations which specify the commands that the WORKER will run on localhost. @item The FACTORY is tied to the WORKER in master.cfg by a BUILDER. @@ -770,7 +770,7 @@ Best Practices: @itemize - @item -When creating a new WORKER in the @code{master.cfg} file, leave a comment specifying the server and user account that this WORKER is called from. (At this time, taler.net is the only server used by this implementation, but it's still good practice.) +When creating a new WORKER in the @code{master.cfg} file, leave a comment specifying the server and user account that this WORKER is called from. (At this time, taler.net is the only server used by this implementation, but it’s still good practice.) @item Create a worker from a shell account with this command: @code{buildbot-worker create-worker <workername> localhost <username> <password>} @@ -872,7 +872,7 @@ $ buildbot-worker start worker/ @section Tipping reserve top-up -Both 'test' and 'demo' setups get their tip reserve topped up +Both ‘test’ and ‘demo’ setups get their tip reserve topped up by a Buildbot worker. The following steps get the reserve topper prepared. @@ -893,7 +893,7 @@ $ buildbot-worker start worker/ @section Producing auditor reports -Both 'test' and 'demo' setups get their auditor reports compiled +Both ‘test’ and ‘demo’ setups get their auditor reports compiled by a Buildbot worker. The following steps get the reports compiler prepared. @@ -1053,7 +1053,7 @@ For bootstrap, you will need to install GNU Recutils@footnote{https://www.gnu.org/software/recutils/}. For the exchange test cases to pass, @code{make install} must be run first. -Without it, test cases will fail because plugins can't be located. +Without it, test cases will fail because plugins can’t be located. @example $ ./bootstrap @@ -1139,21 +1139,21 @@ CI is done with Buildbot (@indicateurl{https://buildbot.net/}), and builds are triggered by the means of Git hooks. The results are published at @indicateurl{https://buildbot.taler.net/} . -In order to avoid downtimes, CI uses a "blue/green" deployment +In order to avoid downtimes, CI uses a “blue/green” deployment technique. In detail, there are two users building code on the system, -the "green" and the "blue" user; and at any given time, one is running +the “green” and the “blue” user; and at any given time, one is running Taler services and the other one is either building the code or waiting for that. There is also the possibility to trigger builds manually, but this is -only reserved to "admin" users. +only reserved to “admin” users. @node Internationalization,Android Apps,Continuous integration,Top @anchor{taler-developer-manual internationalization}@anchor{29} @chapter Internationalization -Internationalization (a.k.a "Translation") is handled with Weblate (@indicateurl{https://weblate.org}) via our instance at @indicateurl{https://weblate.taler.net/} . +Internationalization (a.k.a “Translation”) is handled with Weblate (@indicateurl{https://weblate.org}) via our instance at @indicateurl{https://weblate.taler.net/} . At this time, this system is still very new for Taler.net and this documentation may be incorrect and is certainly incomplete. @@ -1241,7 +1241,7 @@ Under @emph{https://weblate.taler.net/create/component/vcs/}: @strong{Repository push URL} - This is generally @code{git+ssh://git@@git.taler.net/<reponame>`} Check with @code{git remote -v}. @item -@strong{Repository browser} - This is the www URL of the Git repo's file browser. Example @code{https://git.taler.net/<repositoryname>.git/tree/@{@{filename@}@}?h=@{@{branch@}@}#n@{@{line@}@}} where @code{<repositoryname>} gets replaced but @code{@{@{filename@}@}} and other items in braces are actual variables in the string. +@strong{Repository browser} - This is the www URL of the Git repo’s file browser. Example @code{https://git.taler.net/<repositoryname>.git/tree/@{@{filename@}@}?h=@{@{branch@}@}#n@{@{line@}@}} where @code{<repositoryname>} gets replaced but @code{@{@{filename@}@}} and other items in braces are actual variables in the string. @item @strong{Merge style} - @emph{Rebase}, in line with GNU Taler development procedures @@ -1266,7 +1266,7 @@ Under @emph{https://weblate.taler.net/create/component/vcs/}: 4 - Choose the @emph{Component} you wish to contribute to. -5 - Find the language you want to translate into. Click "Translate" on that line. +5 - Find the language you want to translate into. Click “Translate” on that line. 6 - Find a phrase and translate it. @@ -1277,7 +1277,7 @@ You may also wish to refer to @indicateurl{https://docs.weblate.org/} . @section Translation Standards and Practices -By default, our Weblate instance is set to accept translations in English, French, German, Italian, Russian, Spanish, and Portuguese. If you want to contribute a translation in a different language, navigate to the @emph{Component} you want to translate for, and click "Start new translation" to begin. If you require a privilege upgrade, please contact a superuser with your request. +By default, our Weblate instance is set to accept translations in English, French, German, Italian, Russian, Spanish, and Portuguese. If you want to contribute a translation in a different language, navigate to the @emph{Component} you want to translate for, and click “Start new translation” to begin. If you require a privilege upgrade, please contact a superuser with your request. When asked, set the license to GPLv3 or later. @@ -1290,7 +1290,7 @@ Set commit/push to manual only. weblate.taler.net signs GPG commits with the GPG key CD33CE35801462FA5EB0B695F2664BF474BFE502, and the corresponding public key can be found at @indicateurl{https://weblate.taler.net/keys/}. -This means that contributions made through weblate will not be signed with the individual contributor's key when they are checked into the Git repository, but with the weblate key. +This means that contributions made through weblate will not be signed with the individual contributor’s key when they are checked into the Git repository, but with the weblate key. @node Android Apps,Code Coverage,Internationalization,Top @anchor{taler-developer-manual android-apps}@anchor{32} @@ -1331,7 +1331,7 @@ Cashier Their git repositories are mirrored at Gitlab@footnote{https://gitlab.com/gnu-taler/taler-android} to utilize their CI -and F-Droid@footnote{https://f-droid.org}'s Gitlab integration +and F-Droid@footnote{https://f-droid.org}’s Gitlab integration to publish automatic nightly builds@footnote{https://f-droid.org/docs/Publishing_Nightly_Builds/} for each change on the @code{master} branch. @@ -1381,7 +1381,7 @@ git unzip @end itemize -Then you can get the app's source code using git: +Then you can get the app’s source code using git: @example # Start by cloning the Android git repository @@ -1398,12 +1398,12 @@ The last command will return something like @code{compileSdkVersion 29}. So visit the Android Rebuilds@footnote{http://android-rebuilds.beuc.net/} project and look for that version of the Android SDK there. If the SDK version is not yet available as a free rebuild, -you can try to lower the @code{compileSdkVersion} in the app's @code{merchant-terminal/build.gradle} file. +you can try to lower the @code{compileSdkVersion} in the app’s @code{merchant-terminal/build.gradle} file. Note that this might break things or require you to also lower other versions such as @code{targetSdkVersion}. In our example, the version is @code{29} which is available, -so download the "SDK Platform" package of "Android 10.0.0 (API 29)" +so download the “SDK Platform” package of “Android 10.0.0 (API 29)” and unpack it: @example @@ -1436,8 +1436,8 @@ build-tools;29.0.3 Android SDK Build-Tools 29.0.3 @end table @end quotation -you can try changing the @code{buildToolsVersion} in the app's @code{merchant-terminal/build.gradle} file -to the latest "Android SDK build tools" version supported by the Android Rebuilds project. +you can try changing the @code{buildToolsVersion} in the app’s @code{merchant-terminal/build.gradle} file +to the latest “Android SDK build tools” version supported by the Android Rebuilds project. After the build finished successfully, you will find your APK in @code{merchant-terminal/build/outputs/apk/release/}. @@ -1447,7 +1447,7 @@ you will find your APK in @code{merchant-terminal/build/outputs/apk/release/}. @section Update translations -Translations are managed with Taler's weblate instance: +Translations are managed with Taler’s weblate instance: @indicateurl{https://weblate.taler.net/projects/gnu-taler/} To update translations, enter the taler-android git repository @@ -1513,7 +1513,7 @@ $ git tag -s $APP-$VERSION Nightly builds get published automatically (see above) after pushing code to the official repo. -Actual releases get picked up by F-Droid's official repository via git tags. +Actual releases get picked up by F-Droid’s official repository via git tags. So ensure that all releases get tagged properly. Some information for F-Droid official repository debugging: @@ -1613,22 +1613,22 @@ include files (very similar to GNUnet): @itemize * @item -if installed, must start with "@code{taler_}" (exception: platform.h), +if installed, must start with “@code{taler_}” (exception: platform.h), and MUST live in src/include/ @item -if NOT installed, must NOT start with "@code{taler_}" and +if NOT installed, must NOT start with “@code{taler_}” and MUST NOT live in src/include/ and SHOULD NOT be included from outside of their own directory @item -end in "_lib" for "simple" libraries +end in “_lib” for “simple” libraries @item -end in "_plugin" for plugins +end in “_plugin” for plugins @item -end in "_service" for libraries accessing a service, i.e. the exchange +end in “_service” for libraries accessing a service, i.e. the exchange @end itemize @item @@ -1661,22 +1661,22 @@ logging @item tools use their full name in GNUNET_log_setup -(i.e. 'taler-exchange-offline') and log using plain 'GNUNET_log'. +(i.e. ‘taler-exchange-offline’) and log using plain ‘GNUNET_log’. @item -pure libraries (without associated service) use 'GNUNET_log_from' -with the component set to their library name (without lib or '.so'), -which should also be their directory name (i.e. 'util') +pure libraries (without associated service) use ‘GNUNET_log_from’ +with the component set to their library name (without lib or ‘.so’), +which should also be their directory name (i.e. ‘util’) @item -plugin libraries (without associated service) use 'GNUNET_log_from' -with the component set to their type and plugin name (without lib or '.so'), -which should also be their directory name (i.e. 'exchangedb-postgres') +plugin libraries (without associated service) use ‘GNUNET_log_from’ +with the component set to their type and plugin name (without lib or ‘.so’), +which should also be their directory name (i.e. ‘exchangedb-postgres’) @item -libraries with associated service) use 'GNUNET_log_from' +libraries with associated service) use ‘GNUNET_log_from’ with the name of the service, which should also be their -directory name (i.e. 'exchange') +directory name (i.e. ‘exchange’) @item for tools with @code{-l LOGFILE}, its absence means write logs to stderr @@ -1718,14 +1718,14 @@ structs: @itemize * @item -structs that are 'packed' and do not contain pointers and are +structs that are ‘packed’ and do not contain pointers and are thus suitable for hashing or similar operations are distinguished -by adding a "P" at the end of the name. (NEW) Note that this +by adding a “P” at the end of the name. (NEW) Note that this convention does not hold for the GNUnet-structs (yet). @item structs that are used with a purpose for signatures, additionally -get an "S" at the end of the name. +get an “S” at the end of the name. @end itemize @item @@ -1745,7 +1745,7 @@ testcases @itemize * @item -must be called "test_module-under-test_case-description.c" +must be called “test_module-under-test_case-description.c” @end itemize @item @@ -1755,7 +1755,7 @@ performance tests @itemize * @item -must be called "perf_module-under-test_case-description.c" +must be called “perf_module-under-test_case-description.c” @end itemize @end itemize @@ -1841,7 +1841,7 @@ are useful: @code{pathlib} for path manipulation (part of the standard library) @item -@code{subprocess} for "shelling out" to other programs. Prefer @code{subprocess.run} +@code{subprocess} for “shelling out” to other programs. Prefer @code{subprocess.run} over the older APIs. @end itemize @@ -1945,14 +1945,14 @@ used in the user interface and help materials. Refreshing is the internal technical terminology for the protocol to give change for partially spent coins -@strong{Use instead}: "Obtaining change" +@strong{Use instead}: “Obtaining change” @item Coin Coins are an internal construct, the user should never be aware that their balance is represented by coins if different denominations. -@strong{Use instead}: "(Digital) Cash" or "(Wallet) Balance" +@strong{Use instead}: “(Digital) Cash” or “(Wallet) Balance” @item Consumer @@ -1967,7 +1967,7 @@ of the signed contract terms for an order. @strong{Avoid}. Generally events that relate to proposal downloads should not be shown to normal users, only developers. Instead, use -"communication with mechant failed" if a proposed order can't be downloaded. +“communication with mechant failed” if a proposed order can’t be downloaded. @item Anonymous E-Cash @@ -1975,14 +1975,14 @@ Should be generally avoided, since Taler is only anonymous for the customer. Also some people are scared of anonymity (which as a term is also way too absolute, as anonymity is hardly ever perfect). -@strong{Use instead}: "Privacy-preserving", "Privacy-friendly" +@strong{Use instead}: “Privacy-preserving”, “Privacy-friendly” @item Payment Replay The process of proving to the merchant that the customer is entitled to view a digital product again, as they already paid for it. -@strong{Use instead}: In the event history, "re-activated digital content purchase" +@strong{Use instead}: In the event history, “re-activated digital content purchase” could be used. (FIXME: this is still not nice.) @item Session ID @@ -2018,16 +2018,16 @@ Regulatory entity that certifies exchanges and oversees their operation. The entity/service that gives out digital cash in exchange for some other means of payment. -In some contexts, using "Issuer" could also be appropriate. +In some contexts, using “Issuer” could also be appropriate. When showing a balance breakdown, -we can say "100 Eur (issued by exchange.euro.taler.net)". -Sometimes we may also use the more generic term "Payment Service Provider" -when the concept of an "Exchange" is still unclear to the reader. +we can say “100 Eur (issued by exchange.euro.taler.net)”. +Sometimes we may also use the more generic term “Payment Service Provider” +when the concept of an “Exchange” is still unclear to the reader. @item Refund -A refund is given by a merchant to the customer (rather the customer's wallet) -and "undoes" a previous payment operation. +A refund is given by a merchant to the customer (rather the customer’s wallet) +and “undoes” a previous payment operation. @item Payment @@ -2035,12 +2035,12 @@ The act of sending digital cash to a merchant to pay for an order. @item Purchase -Used to refer to the "result" of a payment, as in "view purchase". -Use sparsingly, as the word doesn't fit for all payments, such as donations. +Used to refer to the “result” of a payment, as in “view purchase”. +Use sparsingly, as the word doesn’t fit for all payments, such as donations. @item Contract Terms -Partially machine-readable representation of the merchant's obligation after the +Partially machine-readable representation of the merchant’s obligation after the customer makes a payment. @item Merchant @@ -2049,7 +2049,7 @@ Party that receives a payment. @item Wallet -Also "Taler Wallet". Software component that manages the user's digital cash +Also “Taler Wallet”. Software component that manages the user’s digital cash and payments. @end table @@ -2078,7 +2078,7 @@ absolute time in contrast to @ref{4c,,relative time}. the @ref{4e,,exchange} combines multiple payments received by the same @ref{4f,,merchant} into one larger @ref{50,,wire transfer} to -the respective merchant's @ref{51,,bank} account +the respective merchant’s @ref{51,,bank} account @anchor{taler-developer-manual term-auditor}@anchor{52} @geindex auditor @@ -2200,7 +2200,7 @@ exchange to credit his bank account in the future using an a coin is dirty if its public key may be known to an entity other than the customer, thereby creating the danger of some entity being able to -link multiple transactions of coin's owner if the coin is not refreshed +link multiple transactions of coin’s owner if the coin is not refreshed @anchor{taler-developer-manual term-drain}@anchor{73} @geindex drain @@ -2210,7 +2210,7 @@ link multiple transactions of coin's owner if the coin is not refreshed @itemx drained a @ref{5e,,reserve} is being drained when a @ref{55,,wallet} is using the -reserve's private key to @ref{60,,withdraw} coins from it. This reduces +reserve’s private key to @ref{60,,withdraw} coins from it. This reduces the balance of the reserve. Once the balance reaches zero, we say that the reserve has been (fully) drained. Reserves that are not drained (which is the normal process) are @ref{5c,,closed} by the exchange. @@ -2219,7 +2219,7 @@ the reserve has been (fully) drained. Reserves that are not drained @item exchange -Taler's payment service operator. Issues electronic coins during +Taler’s payment service operator. Issues electronic coins during withdrawal and redeems them when they are deposited by merchants @anchor{taler-developer-manual term-expired}@anchor{74} @geindex expired @@ -2233,7 +2233,7 @@ Various operations come with time limits. In particular, denomination keys come with strict time limits for the various operations involving the coin issued under the denomination. The most important limit is the deposit expiration, which specifies until when wallets are allowed to -use the coin in deposit or refreshing operations. There is also a "legal" +use the coin in deposit or refreshing operations. There is also a “legal” expiration, which specifies how long the exchange keeps records beyond the deposit expiration time. This latter expiration matters for legal disputes in courts and also creates an upper limit for refreshing operations on @@ -2361,7 +2361,7 @@ a coin is owned by the entity that knows the private key of the coin @item planchet -precursor data for a @ref{62,,coin}. A planchet includes the coin's internal +precursor data for a @ref{62,,coin}. A planchet includes the coin’s internal secrets (coin private key, blinding factor), but lacks the RSA signature of the @ref{4e,,exchange}. When @ref{77,,withdrawing}, a @ref{55,,wallet} creates and persists a planchet before asking the exchange to sign it to @@ -2447,7 +2447,7 @@ contrast to @ref{4a,,absolute time}. accounting mechanism used by the exchange to track customer funds from incoming @ref{7a,,wire transfers}. A reserve is created whenever a customer wires money to the exchange using a well-formed public key -in the subject. The exchange then allows the customer's @ref{55,,wallet} +in the subject. The exchange then allows the customer’s @ref{55,,wallet} to @ref{60,,withdraw} up to the amount received in @ref{68,,fresh} @ref{57,,coins} from the reserve, thereby draining the reserve. If a reserve is not drained, the exchange eventually @ref{5b,,closes} it. @@ -2483,7 +2483,7 @@ denomination are subjected to recoup. @item sharing -users can share ownership of a @ref{62,,coin} by sharing access to the coin's +users can share ownership of a @ref{62,,coin} by sharing access to the coin's private key, thereby allowing all co-owners to spend the coin at any time. @anchor{taler-developer-manual term-spend}@anchor{56} @@ -2563,7 +2563,7 @@ the respective code base. @item wallet -software running on a customer's computer; withdraws, stores and +software running on a customer’s computer; withdraws, stores and spends coins @anchor{taler-developer-manual term-WebExtension}@anchor{9c} @geindex WebExtension @@ -2636,21 +2636,21 @@ developer. @strong{taler-config-generate} - tool to simplify Taler configuration generation @strong{taler-config-generate} -[@strong{-C} @emph{CURRENCY} | @strong{--currency=}@emph{CURRENCY}] -[@strong{-c} @emph{FILENAME} | @strong{--config=}@emph{FILENAME}] -[@strong{-e} | @strong{--exchange}] -[@strong{-f} @emph{AMOUNT} | @emph{--wirefee=}@emph{AMOUNT}] -[@strong{-h} | @strong{--help}] -[@strong{-J} @emph{JSON} | @strong{--wire-json-exchange=}@emph{JSON}] -[@strong{-j} @emph{JSON} | @strong{--wire-json-merchant=}@emph{JSON}] -[@strong{-L} @emph{LOGLEVEL} | @strong{--loglevel=}@emph{LOGLEVEL}] -[@strong{-m} | @strong{--merchant}] -[@strong{-t} | @strong{--trusted}] -[@strong{-v} | @strong{--version}] -[@strong{-w} @emph{WIREFORMAT} | @strong{--wire} @emph{WIREFORMAT}] -[@strong{--bank-uri}] -[@strong{--exchange-bank-account}] -[@strong{--merchant-bank-account}] +[@strong{-C} @emph{CURRENCY} | @strong{–currency=}@emph{CURRENCY}] +[@strong{-c} @emph{FILENAME} | @strong{–config=}@emph{FILENAME}] +[@strong{-e} | @strong{–exchange}] +[@strong{-f} @emph{AMOUNT} | @emph{–wirefee=}@emph{AMOUNT}] +[@strong{-h} | @strong{–help}] +[@strong{-J} @emph{JSON} | @strong{–wire-json-exchange=}@emph{JSON}] +[@strong{-j} @emph{JSON} | @strong{–wire-json-merchant=}@emph{JSON}] +[@strong{-L} @emph{LOGLEVEL} | @strong{–loglevel=}@emph{LOGLEVEL}] +[@strong{-m} | @strong{–merchant}] +[@strong{-t} | @strong{–trusted}] +[@strong{-v} | @strong{–version}] +[@strong{-w} @emph{WIREFORMAT} | @strong{–wire} @emph{WIREFORMAT}] +[@strong{–bank-uri}] +[@strong{–exchange-bank-account}] +[@strong{–merchant-bank-account}] @strong{taler-config-generate} can be used to generate configuration files for the Taler exchange or Taler merchants. @@ -2658,16 +2658,16 @@ for the Taler exchange or Taler merchants. @table @asis -@item @strong{-C} @emph{CURRENCY} | @strong{--currency=}@emph{CURRENCY} +@item @strong{-C} @emph{CURRENCY} | @strong{–currency=}@emph{CURRENCY} Which currency should we use in the configuration. -@item @strong{-c} @emph{FILENAME} | @strong{--config=}@emph{FILENAME} +@item @strong{-c} @emph{FILENAME} | @strong{–config=}@emph{FILENAME} Location where to write the generated configuration. Existing file will be updated, not overwritten. -@item @strong{-e} | @strong{--exchange} +@item @strong{-e} | @strong{–exchange} Generate configuration for a Taler exchange. @@ -2676,53 +2676,53 @@ Generate configuration for a Taler exchange. Setup wire transfer fees for the next 5 years for the exchange (for all wire methods). -@item @strong{-h} | @strong{--help} +@item @strong{-h} | @strong{–help} Shows this man page. -@item @strong{-J} @emph{JSON} | @strong{--wire-json-exchange=}@emph{JSON} +@item @strong{-J} @emph{JSON} | @strong{–wire-json-exchange=}@emph{JSON} Wire configuration to use for the exchange. -@item @strong{-j} @emph{JSON} | @strong{--wire-json-merchant=}@emph{JSON} +@item @strong{-j} @emph{JSON} | @strong{–wire-json-merchant=}@emph{JSON} Wire configuration to use for the merchant. -@item @strong{-L} @emph{LOGLEVEL} | @strong{--loglevel=}@emph{LOGLEVEL} +@item @strong{-L} @emph{LOGLEVEL} | @strong{–loglevel=}@emph{LOGLEVEL} Use LOGLEVEL for logging. Valid values are DEBUG, INFO, WARNING and ERROR. -@item @strong{-m} | @strong{--merchant} +@item @strong{-m} | @strong{–merchant} Generate configuration for a Taler merchant. -@item @strong{-t} | @strong{--trusted} +@item @strong{-t} | @strong{–trusted} Setup current exchange as trusted with current merchant. Generally only useful when configuring for testcases. -@item @strong{-v} | @strong{--version} +@item @strong{-v} | @strong{–version} Print version information. -@item @strong{-w} @emph{WIREFORMAT} | @strong{--wire} @emph{WIREFORMAT} +@item @strong{-w} @emph{WIREFORMAT} | @strong{–wire} @emph{WIREFORMAT} Specifies which wire format to use (i.e. “test” or “sepa”) -@item @strong{--bank-uri} +@item @strong{–bank-uri} Alternative to specify wire configuration to use for the exchange and merchant for the “test” wire method. Only useful if WIREFORMAT was set to “test”. Specifies the URI of the bank. -@item @strong{--exchange-bank-account} +@item @strong{–exchange-bank-account} Alternative to specify wire configuration to use for the exchange for the “test” wire method. Only useful if WIREFORMAT was set to “test”. Specifies the bank account number of the exchange. -@item @strong{--merchant-bank-account} +@item @strong{–merchant-bank-account} Alternative to specify wire configuration to use for the merchant for the “test” wire method. Only useful if WIREFORMAT was set to “test”. diff --git a/texinfo/taler-exchange.texi b/texinfo/taler-exchange.texi index b6104ffd..8872a3c0 100644 --- a/texinfo/taler-exchange.texi +++ b/texinfo/taler-exchange.texi @@ -21,7 +21,7 @@ @copying @quotation -GNU Taler 0.8.0pre0, Aug 03, 2021 +GNU Taler 0.8.2, Aug 08, 2021 GNU Taler team @@ -274,7 +274,7 @@ binary is the @code{taler-exchange-httpd}. @item Crypto-Helpers The @code{taler-exchange-secmod-rsa} and @code{taler-exchange-secmod-eddsa} -are two programs that are responsible for managing the exchange's +are two programs that are responsible for managing the exchange’s online signing keys. They must run on the same machine as the @code{taler-exchange-httpd} as the HTTP frontend communicates with the crypto helpers using UNIX Domain Sockets. @@ -293,7 +293,7 @@ Closer The @code{taler-exchange-closer} tool check that reserves are properly closed. If a customer wires funds to an exchange and then fails to withdraw them, the closer will (eventually) trigger a wire -transfer that sends the customer's funds back to the originating +transfer that sends the customer’s funds back to the originating wire account. @item @@ -334,7 +334,7 @@ the Python bank provides a bank that directly provides the wire adapter API. @item -For production, libeufin's Nexus component implements a wire +For production, libeufin’s Nexus component implements a wire adapter towards the traditional SEPA banking system with IBAN accounts. @end enumerate @@ -371,7 +371,7 @@ copy of the database. The exchange (and ideally also auditors) uses a long-term offline master siging key that identifies the operator and is used to authenticate critical -information, such as the exchange's bank account and the actual keys the +information, such as the exchange’s bank account and the actual keys the exchange uses online. Interactions with the offline system are performed using the @@ -430,7 +430,7 @@ expires or if they are informed about a key having been revoked. From a security point of view, the helpers are designed to @emph{only} make it -harder for an attacker who took control of the HTTP daemon's account to +harder for an attacker who took control of the HTTP daemon’s account to extract the private keys, limiting the attackers ability to creating signatures to the duration of their control of that account. @@ -450,8 +450,8 @@ The helper processes should be run under a user ID that is separate from that of the user running the main @code{taler-exchange-httpd} service. For security, it is important that helpers run under a different user ID than the main HTTP frontend, in fact ideally each helper should run under its own user ID. The -@code{taler-exchange-httpd} service's will securely communicate with the helpers -using UNIX domain sockets. To enable access to the keys, the service's user +@code{taler-exchange-httpd} service’s will securely communicate with the helpers +using UNIX domain sockets. To enable access to the keys, the service’s user must be in the group of the helper processes (and no other users should be in that group). @@ -890,9 +890,9 @@ denomination keys (signs electronic coins, see section Coins) security module keys (signs sign keys and denomination keys) @end itemize -Additionally, the exchange is sometimes concerned with the auditor's public +Additionally, the exchange is sometimes concerned with the auditor’s public key (to verify messages signed by auditors approved by the exchange operator) -and the merchant's public key (to verify refunds are authorized by the +and the merchant’s public key (to verify refunds are authorized by the merchant). Key options include: @@ -1009,7 +1009,7 @@ must then have the following options: @item @code{VALUE}: How much is the coin worth, the format is -CURRENCY:VALUE.FRACTION. For example, a 10 cent piece is "EUR:0.10". +CURRENCY:VALUE.FRACTION. For example, a 10 cent piece is “EUR:0.10”. @item @code{DURATION_WITHDRAW}: How long can a coin of this type be withdrawn? @@ -1128,7 +1128,7 @@ delayed. @section Terms of Service -The exchange has an endpoint "/terms" to return the terms of service +The exchange has an endpoint “/terms” to return the terms of service (in legal language) of the exchange operator. The wallet will show those terms of service to the user when the user is first withdrawing coins. Terms of service are optional for experimental deployments, @@ -1142,7 +1142,7 @@ in the @code{[exchange]} section: @itemize - @item -@code{TERMS_ETAG}: The current "Etag" to return for the terms of service. +@code{TERMS_ETAG}: The current “Etag” to return for the terms of service. This value must be changed whenever the terms of service are updated. A common value to use would be a version number. Note that if you change the @code{TERMS_ETAG}, you MUST also provide @@ -1156,7 +1156,7 @@ process. The @code{TERMS_DIR} directory structure must follow a particular layout. First, inside of @code{TERMS_DIR}, there should be sub-directories using -two-letter language codes like "en", "de", or "jp". Each of these +two-letter language codes like “en”, “de”, or “jp”. Each of these directories would then hold translations of the current terms of service into the respective language. Empty directories are permitted in case translations are not available. @@ -1178,7 +1178,7 @@ present, the exchange may show a warning on startup. @subsection Example -A sample file structure for a @code{TERMS_ETAG} of "v1" would be: +A sample file structure for a @code{TERMS_ETAG} of “v1” would be: @itemize - @@ -1205,7 +1205,7 @@ TERMS_DIR/de/v1.pdf TERMS_DIR/fr/v1.pdf @end itemize -If the user requests an HTML format with language preferences "fr" followed by "en", +If the user requests an HTML format with language preferences “fr” followed by “en”, the exchange would return @code{TERMS_DIR/en/v1.html} lacking an HTML version in French. @@ -1331,7 +1331,7 @@ The exchange must be informed about any auditor that is expected to provision it with auditor signatures. This is also done using the @code{taler-exchange-offline} tool on the offline system. First, the auditor must be configured and provide the exchange operator with its public key and -the URL of it's REST API. The exchange operator also needs a human-readable +the URL of it’s REST API. The exchange operator also needs a human-readable name that may be shown to users to identify the auditor. Given this information, the exchange operator can enable the auditor: @@ -1588,7 +1588,7 @@ helpful for diagnostics. While an exchange should use an external auditor to attest to regulators that -it is operating correctly, an exchange operator can also use the auditor's +it is operating correctly, an exchange operator can also use the auditor’s logic to perform internal checks. For this, an exchange operator can generally follow the auditor guide. However, instead of using @code{taler-auditor-sync}, an internal audit can and likely should be performed either directly against @@ -1634,14 +1634,14 @@ The database scheme used by the exchange looks as follows: This chapter describes how to run the Taler exchange benchmark. The benchmark can be used to measure the performance of the exchange by running a (possibly large) number of simulated clients against one Taler deployment with a bank, -exchange and auditor. For the bank, both a "fakebank" (@code{-f}) and a -"Pythonbank" deployment are currently supported. The +exchange and auditor. For the bank, both a “fakebank” (@code{-f}) and a +“Pythonbank” deployment are currently supported. The @code{taler-exchange-benchmark} program can launch all required services and clients, or only launch the parallel clients (@code{-m}), for example for distributed testing over a network. For each @emph{parallel} (@code{-p}) client, a number of @emph{reserves} (@code{-r}) is first established by -@strong{transferring} money from a "user" account (42) to the Exchange's account +@strong{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 @strong{withdraw} a @emph{number of coins} (@code{-n}) from the reserve and @strong{deposit} them. Additionally, a @emph{fraction} (@code{-R}) of the dirty coins will then be @@ -1661,7 +1661,7 @@ You can run a first simple benchmark using: @cartouche @quotation Note FIXME-TTN/CG: these instructions are incomplete and untested for the -current iteration of the code... +current iteration of the code… @end quotation @end cartouche diff --git a/texinfo/taler-merchant-api-tutorial.texi b/texinfo/taler-merchant-api-tutorial.texi index e0acd921..a0b32006 100644 --- a/texinfo/taler-merchant-api-tutorial.texi +++ b/texinfo/taler-merchant-api-tutorial.texi @@ -21,7 +21,7 @@ @copying @quotation -GNU Taler 0.8.0pre0, Aug 03, 2021 +GNU Taler 0.8.2, Aug 08, 2021 GNU Taler team @@ -453,7 +453,7 @@ the merchant’s obligations under the contract. @cartouche @quotation Note You do not need to keep querying to notice changes -to the order's transaction status. The endpoints +to the order’s transaction status. The endpoints support long polling, simply specify a @code{timeout_ms} query parameter with how long you want to wait at most for the order status to change to @code{paid}. @@ -551,8 +551,8 @@ from the QR code). The merchant backend then updates the session ID of the existing order to the current session ID of the browser. When the payment status for the -"new" unpaid order is checked (or already in long-polling), the backend -detects that for the browser's @emph{session ID} and @emph{fulfillment URL} there is an +“new” unpaid order is checked (or already in long-polling), the backend +detects that for the browser’s @emph{session ID} and @emph{fulfillment URL} there is an existing paid contract. It then tells the browser to immediately redirect to the fulfillment URL where the already paid article is available. @@ -1020,8 +1020,8 @@ render fields that they do not understand as a key-value list. @printindex ge -@anchor{taler-merchant-api-tutorial The-Taler-Order-Format}@w{ } @anchor{c}@w{ } +@anchor{taler-merchant-api-tutorial The-Taler-Order-Format}@w{ } @c %**end of body @bye diff --git a/texinfo/taler-merchant.texi b/texinfo/taler-merchant.texi index 23e70812..5c5f9e5b 100644 --- a/texinfo/taler-merchant.texi +++ b/texinfo/taler-merchant.texi @@ -21,7 +21,7 @@ @copying @quotation -GNU Taler 0.8.0pre0, Aug 03, 2021 +GNU Taler 0.8.2, Aug 08, 2021 GNU Taler team @@ -303,10 +303,9 @@ merchant’s signing keys and bank account information are encapsulated within the Taler backend. A typical deployment will additionally include a full-blown Web server (like -Apache or Nginx). Such a Web server would be responsible for TLS termination -and access control to the @code{/private/} API endpoints of the merchant backend. -Please carefully review the section on @ref{9,,Secure setup} before -deploying a Taler merchant backend to production. +Apache or Nginx). Such a Web server would be responsible for TLS termination and +access control to the @code{/private/} and @code{/management/} API endpoints of the +merchant backend. Please carefully review the section on @ref{9,,Secure setup} before deploying a Taler merchant backend to production. @node Terminology,Installation,Introduction,Top @anchor{taler-merchant-manual terminology}@anchor{a} @@ -348,7 +347,7 @@ the main Taler configuration (accepted currency, exchanges and auditors). To receive payments, an instance must have configured one or more bank @emph{accounts}. The backend does not have accounts for users, and instances are -also not really 'accounts'. So whenever we use the term @emph{account}, it is about +also not really ‘accounts’. So whenever we use the term @emph{account}, it is about a bank account of a merchant. @node Inventory,Orders and Contracts,Accounts,Terminology @@ -447,7 +446,7 @@ decade), contract information is deleted. The Taler backend can be used to verify that the exchange correctly wired all of the funds to the merchant. However, the backend does not have access to the -incoming wire transfers of the merchant's bank account. Thus, merchants must +incoming wire transfers of the merchant’s bank account. Thus, merchants must manually provide the backend with wire @emph{transfer} data that specifies the wire transfer subject and the amount that was received. Given this information, the backend can detect and report any irregularities that might arise. @@ -465,7 +464,7 @@ backend can detect and report any irregularities that might arise. Taler does not only allow a Website to be paid, but also to make voluntary, non-contractual payments to visitors, called @emph{tips}. Such tips could be -granted as a reward for filling in surveys or watching advertisements. For +granted as a reward for filling in surveys or watching advertizements. For tips, there is no contract, tips are always voluntary actions by the Web site that do not arise from a contractual obligation. Before a Web site can create tips, it must establish a reserve. Once a reserve has been @@ -621,7 +620,7 @@ shared object libraries (@code{.so} files) visible to the various installed programs. There is no need to actually run a GNUnet peer to use the Taler merchant -backend -- all the merchant needs from GNUnet is a number of headers and +backend – all the merchant needs from GNUnet is a number of headers and libraries! @node Installing the GNU Taler exchange,Installing the GNU Taler merchant backend,Installing GNUnet,Generic instructions for installation from source @@ -649,7 +648,7 @@ which requires you to run the last step as @code{root}. You have to specify previous step. There is no need to actually run a Taler exchange to use the Taler merchant -backend -- all the merchant needs from the Taler exchange is a few headers and +backend – all the merchant needs from the Taler exchange is a few headers and libraries! @node Installing the GNU Taler merchant backend,,Installing the GNU Taler exchange,Generic instructions for installation from source @@ -1290,7 +1289,7 @@ that section, the following options need to be configured: @item The @code{AUDITOR_BASE_URL} option specifies the auditor’s base URL. -For example, to use the Taler demonstrator's auditor, specify: +For example, to use the Taler demonstrator’s auditor, specify: @example $ taler-config -s MERCHANT-AUDITOR-demo \ @@ -1299,7 +1298,7 @@ $ taler-config -s MERCHANT-AUDITOR-demo \ @end example @item -The @code{AUDITOR_KEY} option specifies the auditor's public key +The @code{AUDITOR_KEY} option specifies the auditor’s public key in base32 encoding. For the Taler demonstrator, use: @example @@ -1429,7 +1428,7 @@ and use TLS for improved network privacy, see @ref{9,,Secure setup}. @chapter Instance setup -Before using the backend, you must at least configure the "default" instance. +Before using the backend, you must at least configure the “default” instance. @menu * KUDOS Accounts:: @@ -1478,7 +1477,7 @@ IBAN, the corresponding @code{payto://}-URI is simply @code{payto://iban/$IBAN} With the knowledge of the @code{payto://}-URI, instances can be configured by POSTing -a request to @code{POST /private/instances}. To create a first instance, +a request to @code{/management/instances}. To create a first instance, create a file @code{instance.json} with an InstanceConfigurationMessage @example @@ -1500,7 +1499,7 @@ create a file @code{instance.json} with an InstanceConfigurationMessage In the text above, you must replace @code{$PAYTO_URI} with your actual @code{payto://}-URI. Also, be sure to replace @code{KUDOS} with the fiat currency if the setup is for an actual bank. The @code{name} field will be shown as the name of -your shop. The @code{address} field is expected to contain your shop's physical +your shop. The @code{address} field is expected to contain your shop’s physical address. The various defaults specify defaults for transaction fees your shop is willing to cover, how long offers made to the customer are valid, and how long the exchange has before it must wire the funds to your bank @@ -1510,7 +1509,7 @@ For details, see the contract terms specification. You can then create the instance using: @example -$ wget --post-file=instance.json http://localhost:8888/private/instances +$ wget --post-file=instance.json http://localhost:8888/management/instances @end example The base URL for the instance will then be @@ -1556,9 +1555,9 @@ $ taler-config -s MERCHANT -o SERVE -V UNIX $ taler-config -s MERCHANT -o UNIXPATH -V /some/path/here.sock @end example -Do not use a UNIX domain socket path in "/tmp": systemd (or other init -systems) may give Web servers a private "/tmp" thereby hiding UNIX domain -sockets created by other users/processes in "/tmp". +Do not use a UNIX domain socket path in “/tmp”: systemd (or other init +systems) may give Web servers a private “/tmp” thereby hiding UNIX domain +sockets created by other users/processes in “/tmp”. If UNIX domain sockets are for some reason not possible, you @emph{may} use a host-based firewall to block access to the TCP port of the merchant backend, @@ -1632,19 +1631,20 @@ setup access control! @section Access control -All endpoints with @code{/private/} in the URL must be restricted to authorized users -of the respective instance. Specifically, the HTTP server must be configured -to only allow access to @code{$BASE_URL/private/} to the authorized users of the -default instance, and to @code{$BASE_URL/instances/$ID/private/} to the -authorized users of the instance @code{$ID}. +All endpoints with @code{/private/} in the URL must be restricted to authorized +users of the respective instance. Specifically, the HTTP server must be +configured to only allow access to @code{$BASE_URL/private/} and +@code{$BASE_URL/management/} to the authorized users of the default instance, and +to @code{$BASE_URL/instances/$ID/private/} to the authorized users of the instance +@code{$ID}. How access control is done (TLS client authentication, HTTP basic or digest authentication, etc.) is completely up to the merchant and does not matter to the Taler merchant backend. -Note that all of the other endpoints (without @code{/private/}) are expected to be -fully exposed to the Internet, and wallets may have to interact with those -endpoints directly without client authentication. +Note that all of the other endpoints (without @code{/private/} or @code{/management/}) +are expected to be fully exposed to the Internet, and wallets may have to +interact with those endpoints directly without client authentication. @menu * Nginx: Nginx<2>. @@ -1667,6 +1667,12 @@ location ~ /private/ @{ @} proxy_pass ...; // as above @} +location /management/ @{ + if ($http_authorization !~ "(?i)ApiKey SECURITYTOKEN") @{ + return 401; + @} + proxy_pass ...; // as above +@} @end example Here, @code{SECURITYTOKEN} should be replaced with the actual shared secret. Note @@ -1698,6 +1704,12 @@ location /private/ @{ @} proxy_pass ...; # as above @} +location /management/ @{ + if ($http_authorization !~ "(?i)ApiKey MASTERTOKEN") @{ + return 401; + @} + proxy_pass ...; # as above +@} location ~ /private/ @{ return 401; # access to instances not explicitly configured is forbidden @} @@ -1721,6 +1733,7 @@ Then, you can restrict to an access control token using: RewriteEngine On RewriteCond "%@{HTTP:AUTHORIZATION@}" "!=SECURITYTOKEN" RewriteRule "(.+)/private/" "-" [F] +RewriteRule "/management/" "-" [F] ProxyPass "unix:/some/path/here.sock|http://example.com/" </Location> @@ -1729,7 +1742,7 @@ ProxyPass "unix:/some/path/here.sock|http://example.com/" Here, @code{SECURITYTOKEN} should be replaced with the actual shared secret. Note that the @code{(.+)} ensures that the above matches all endpoints that include the string @code{/private/}. If you only run a single instance, you could simply -specify @code{/private/} without the @code{~} to only configure the access policy for +specify @code{/private/} without the @code{(.+)} to only configure the access policy for the default instance. If you are running different instances on the same backend, you @@ -1757,6 +1770,7 @@ ProxyPass ... # as above RewriteEngine On RewriteCond "%@{HTTP:AUTHORIZATION@}" "!=MASTERTOKEN" RewriteRule "/private/" "-" [F] +RewriteRule "/management/" "-" [F] RewriteRule "(.+)/private/" "-" [F] # reject all others ProxyPass ... # as above @@ -1832,7 +1846,7 @@ process to hold open file handles for all of these files. You may want to increase the @code{ulimit} of the @code{taler-merchant-httpd} process if you have templates for many languages. -The backend determines the MIME type based on the file's extension. The list +The backend determines the MIME type based on the file’s extension. The list of supported extensions is hard-coded and includes common text and image formats. @@ -1932,7 +1946,7 @@ You now need to make a wire transfer to the exchange’s bank account using the given wire transfer subject. Make your wire transfer and (optionally) check at -“@indicateurl{https://exchange/reserves/QPE24X}...” whether your transfer has arrived at the +“@indicateurl{https://exchange/reserves/QPE24X}…” whether your transfer has arrived at the exchange. Once the funds have arrived, you can start to use the reserve for @@ -1951,8 +1965,7 @@ every other week to ensure one is always ready. When your frontend has reached the point where a client is supposed to receive a tip, it needs to first authorize the tip. For this, the frontend must use -the @code{POST /private/reserves/$RESERVE_PUB/authorize-tip} -API of the backend. To authorize a +a POST to @code{/private/reserves/$RESERVE_PUB/authorize-tip}. To authorize a tip, the frontend has to provide the following information in the body of the POST request: @@ -1990,7 +2003,7 @@ misconfigured instances or a lack of remaining funds for tipping. The wallet will POST a JSON object to the shop’s -@code{POST /tips/$TIP_ID/pickup} handler. +@code{/tips/$TIP_ID/pickup} handler. The frontend must then forward this request to the backend. The response generated by the backend can then be forwarded directly to the wallet. @@ -2203,13 +2216,13 @@ start. The @code{taler-merchant-benchmark} tool will automatically launch and configure the exchange, (Python) bank and other tools required for the benchmark. However, the configuration file must be provided and have consistent options set. The -options that require special care include the exchange's public key (which +options that require special care include the exchange’s public key (which must match the private key in the file specified by the configuration), the currency (which must be consistent across the file), the denomination structure (which must enable payments in the range of 100ths of the unit currency (often called cents)). Furthermore, the benchmark will set the -Exchange bank account password to be "x", so the configuration must also -specify "x" for the passphrase. Finally, the bank must be configured to allow +Exchange bank account password to be “x”, so the configuration must also +specify “x” for the passphrase. Finally, the bank must be configured to allow for substantial debt least the transactions by the benchmark run out of digital cash. @@ -2341,10 +2354,10 @@ rsa_keysize = 1024 @end example -Note that the public key must match the exchange's +Note that the public key must match the exchange’s private key and that the Postgres database must exist before launching the benchmark. You also -will need to ensure that the Exchange's +will need to ensure that the Exchange’s details are set up. For details, see the Exchange Operator Manual. @@ -2413,7 +2426,7 @@ options: @item @code{--tracks-number=TN} Instructs the tool to perform @emph{TN} tracking operations. Note that the @strong{total} amount of operations will be two -times @emph{TN}, since "one" tracking operation accounts for +times @emph{TN}, since “one” tracking operation accounts for @code{/track/transaction} and @code{/track/transfer}. This command should only be used to see if the operation ends without problems, as no actual measurement of performance is provided (despite of the |