diff options
Diffstat (limited to 'texinfo/taler-auditor.texi')
| -rw-r--r-- | texinfo/taler-auditor.texi | 189 |
1 files changed, 95 insertions, 94 deletions
diff --git a/texinfo/taler-auditor.texi b/texinfo/taler-auditor.texi index 570256fe..9a50ce32 100644 --- a/texinfo/taler-auditor.texi +++ b/texinfo/taler-auditor.texi @@ -21,7 +21,7 @@ @copying @quotation -GNU Taler 0.9.0, Jun 20, 2022 +GNU Taler 0.9.0, Jul 06, 2022 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} @@ -512,13 +512,13 @@ Sample configuration files for the HTTP reverse proxy can be found in To install the GNU Taler Ubuntu packages, first ensure that you have the right Ubuntu distribution. At this time, the packages are built for -Ubuntu 20.04 LTS (Focal Fossa). +Ubuntu 22.04 LTS (Jammy Jellyfish). A typical @code{/etc/apt/sources.list.d/taler.list} file for this setup would look like this: @example -deb https://deb.taler.net/apt/ubuntu/ focal-fossa main +deb https://deb.taler.net/apt/ubuntu/ jammy main @end example The last line is crucial, as it adds the GNU Taler packages. @@ -527,7 +527,8 @@ Next, you must import the Taler Systems SA public package signing key into your keyring and update the package lists: @example -# wget -O - https://taler.net/taler-systems.gpg.key | apt-key add - +# wget -O /etc/apt/trusted.gpg.d/taler-systems.asc \ + https://taler.net/taler-systems.gpg.key # apt update @end example @@ -579,22 +580,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 @@ -614,10 +615,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 PostgreSQL database +postgres — runs the PostgreSQL database @end itemize @end quotation @@ -634,16 +635,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 @@ -675,7 +676,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. @@ -684,7 +685,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:: @@ -833,7 +834,7 @@ $ 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 @code{taler-exchange-offline setup}) and the REST endpoint of the exchange and configure these: @@ -844,14 +845,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. @@ -892,9 +893,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. @@ -920,7 +921,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 @@ -963,14 +964,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 @@ -991,7 +992,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. @@ -999,7 +1000,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:: @@ -1013,13 +1014,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 @@ -1029,7 +1030,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. @@ -1067,7 +1068,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 @@ -1102,21 +1103,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 PostgreSQL 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 PostgreSQL instance and is only accessed via @code{taler-auditor-sync} and the replication mechanism driven by the exchange operator. @@ -1132,7 +1133,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. @@ -1145,10 +1146,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 PostgreSQL's standard mechanisms. The same +the schema can be replicated using PostgreSQL’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 @@ -1162,7 +1163,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 business unit name. A secure tunnel +good @code{$NAME} relates to the auditor’s business unit name. A secure tunnel must be setup between the exchange and the auditor, for example using SSH or Wireguard. @@ -1185,7 +1186,7 @@ PostgreSQL configuration: 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 @@ -1195,7 +1196,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 @@ -1212,7 +1213,7 @@ For details, we refer to the PostgreSQL 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 PostgreSQL database replication mechanisms are robust against a malicious master database. Thus, the auditor should @@ -1227,20 +1228,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 PostgreSQL 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 @@ -1272,11 +1273,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 @@ -1302,7 +1303,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 @@ -1352,7 +1353,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: @@ -1418,14 +1419,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} @@ -1470,7 +1471,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. @@ -1479,12 +1480,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}. @@ -1516,15 +1517,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. @@ -1533,22 +1534,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 @@ -1573,7 +1574,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: @@ -1685,7 +1686,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: @@ -1693,9 +1694,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). @@ -1791,7 +1792,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: @@ -1853,11 +1854,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: @@ -1919,7 +1920,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 @@ -1932,13 +1933,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. |