summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2024-03-07 11:57:29 +0100
committerChristian Grothoff <christian@grothoff.org>2024-03-07 11:57:29 +0100
commitaf8c69dfe397ff4bed7abca98ed8f3b2ed70541b (patch)
tree4b5707dd8aa3a5ad6b67e9440f22bad88d8ea00b
parent76a0b43311a1dae141e6b903e9d465da3be19ae7 (diff)
downloaddocs-prebuilt.tar.gz
docs-prebuilt.tar.bz2
docs-prebuilt.zip
-rw-r--r--texinfo/challenger.texi32
-rw-r--r--texinfo/taler-auditor.texi204
-rw-r--r--texinfo/taler-developer-manual.texi242
-rw-r--r--texinfo/taler-exchange.texi114
-rw-r--r--texinfo/taler-merchant-api-tutorial.texi10
-rw-r--r--texinfo/taler-merchant.texi78
6 files changed, 340 insertions, 340 deletions
diff --git a/texinfo/challenger.texi b/texinfo/challenger.texi
index d336c6c4..53f57e43 100644
--- a/texinfo/challenger.texi
+++ b/texinfo/challenger.texi
@@ -10,9 +10,9 @@
@paragraphindent 0
@exampleindent 4
@finalout
-@dircategory Networking
+@dircategory Network applications
@direntry
-* Challenger: (challenger.info). OAuth2-based customer address validation service
+* GNU Taler Challenger: (challenger.info). Customer address validation service
@end direntry
@c %**end of header
@@ -23,7 +23,7 @@ GNU Taler 0.9.4, Mar 07, 2024
GNU Taler team
-Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+Copyright @copyright{} 2014-2024 Taler Systems SA (GPLv3+ or GFDL 1.3+)
@end quotation
@end copying
@@ -201,7 +201,7 @@ in a Postgres database by the Challenger service.
@chapter Installation
-In this guide's shell-session fragments, the command prompt shows two pieces
+In this guide’s shell-session fragments, the command prompt shows two pieces
of information:
@@ -247,7 +247,7 @@ backend:
@itemize -
@item
-"Sphinx RTD Theme" Python package aka @code{python3-sphinx-rtd-theme}
+“Sphinx RTD Theme” Python package aka @code{python3-sphinx-rtd-theme}
on Debian-based systems (for GNUnet documentation support, can be
omitted if GNUnet is configured with @code{--disable-documentation})
@@ -344,7 +344,7 @@ In any case, if @code{make check} fails, please consider filing a
bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.
There is no need to actually run a GNUnet peer or a Taler exchange to use
-Challenger -- all Challenger needs from GNUnet and Taler are a number of
+Challenger – all Challenger needs from GNUnet and Taler are a number of
headers and libraries!
After installing GNUnet, unpack the GNU Taler exchange tarball,
@@ -763,7 +763,7 @@ setup and configure the legal conditions.
@section Terms of Service
-The service has an endpoint "/terms" to return the terms of service (in legal
+The service has an endpoint “/terms” to return the terms of service (in legal
language) of the service operator. Client software show these terms of
service to the user when the user is first interacting with the service.
Terms of service are optional for experimental deployments, if none are
@@ -777,7 +777,7 @@ in the configuration file for the service:
@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
@@ -794,7 +794,7 @@ process.
@section Privacy Policy
-The service has an endpoint "/pp" to return the terms privacy policy (in legal
+The service has an endpoint “/pp” to return the terms privacy policy (in legal
language) of the service operator. Clients should show the privacy policy to
the user when the user explicitly asks for it, but it should not be shown by
default. Privacy policies are optional for experimental deployments, if none
@@ -808,7 +808,7 @@ in the configuration file for the service:
@itemize -
@item
-@code{PRIVACY_ETAG}: The current "Etag" to return for the privacy policy.
+@code{PRIVACY_ETAG}: The current “Etag” to return for the privacy policy.
This value must be changed whenever the privacy policy is
updated. A common value to use would be a version number.
Note that if you change the @code{PRIVACY_ETAG}, you MUST also provide
@@ -829,7 +829,7 @@ The @code{TERMS_DIR} and @code{PRIVACY_DIR} directory structures must follow a
particular layout. You may use the same directory for both the terms of
service and the privacy policy, as long as you use different ETAGs. Inside of
the directory, there should be sub-directories using two-letter language codes
-like "en", "de", or "jp". Each of these directories would then hold
+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.
@@ -837,7 +837,7 @@ Then, inside each language directory, files with the name of the value set as
the @code{TERMS_ETAG} or @code{PRIVACY_ETAG} must be provided. The extension of each
of the files should be typical for the respective mime type. The set of
supported mime types is currently hard-coded in the service, and includes
-".epub", ".html", ".md", ".pdf" and ".txt" files. If other files are present,
+“.epub”, “.html”, “.md”, “.pdf” and “.txt” files. If other files are present,
the service may show a warning on startup.
@menu
@@ -850,7 +850,7 @@ the service may show a warning on startup.
@subsection Example
-A sample file structure for a @code{TERMS_ETAG} of "tos-v0" would be:
+A sample file structure for a @code{TERMS_ETAG} of “tos-v0” would be:
@itemize -
@@ -886,8 +886,8 @@ TERMS_DIR/de/tos-v0.epub
TERMS_DIR/de/tos-v0.md
@end itemize
-If the user requests an HTML format with language preferences "fr" followed by
-"en", the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
+If the user requests an HTML format with language preferences “fr” followed by
+“en”, the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
French.
@node Generating the Legal Terms,Adding translations,Legal policies directory layout,Configuration Fundamentals
@@ -1336,7 +1336,7 @@ The template is instantiated using the following information:
@itemize *
@item
-restrictions: Object; map of keys (names of the fields of the address to be entered by the user) to objects with a "regex" (string) containing an extended Posix regular expression for allowed address field values, and a "hint"/"hint_i18n" giving a human-readable explanation to display if the value entered by the user does not match the regex. Keys that are not mapped to such an object have no restriction on the value provided by the user. See "ADDRESS_RESTRICTIONS" in the challenger configuration.
+restrictions: Object; map of keys (names of the fields of the address to be entered by the user) to objects with a “regex” (string) containing an extended Posix regular expression for allowed address field values, and a “hint”/”hint_i18n” giving a human-readable explanation to display if the value entered by the user does not match the regex. Keys that are not mapped to such an object have no restriction on the value provided by the user. See “ADDRESS_RESTRICTIONS” in the challenger configuration.
@item
fix_address: boolean; indicates if the given address cannot be changed
diff --git a/texinfo/taler-auditor.texi b/texinfo/taler-auditor.texi
index e6bc3370..82ead846 100644
--- a/texinfo/taler-auditor.texi
+++ b/texinfo/taler-auditor.texi
@@ -10,7 +10,7 @@
@paragraphindent 0
@exampleindent 4
@finalout
-@dircategory Networking
+@dircategory Network applications
@direntry
* GNU Taler Auditor: (taler-auditor.info). External audit for Taler Exchange operation
@end direntry
@@ -23,7 +23,7 @@ GNU Taler 0.9.4, Mar 07, 2024
GNU Taler team
-Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+Copyright @copyright{} 2014-2024 Taler Systems SA (GPLv3+ or GFDL 1.3+)
@end quotation
@end copying
@@ -99,7 +99,7 @@ Configuration
* Configuration format::
* Initial configuration::
* Keys::
-* Configuring the auditor's REST endpoint::
+* Configuring the auditor’s REST endpoint::
* Bank account::
* Database::
* Legal conditions for using the service::
@@ -137,7 +137,7 @@ Operation
Auditor implementation guide
-* The auditor's database::
+* The auditor’s database::
* Invariants checked by the auditor::
* Testing the auditor::
@@ -220,7 +220,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
@@ -232,9 +232,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.
@@ -242,7 +242,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:
@@ -268,7 +268,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
@@ -289,8 +289,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:
@@ -322,7 +322,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}.
@@ -342,7 +342,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}
@@ -388,7 +388,7 @@ Python3 module @code{jinja2}
@itemize -
@item
-"Sphinx RTD Theme" Python package aka @code{python3-sphinx-rtd-theme}
+“Sphinx RTD Theme” Python package aka @code{python3-sphinx-rtd-theme}
on Debian-based systems (for GNUnet documentation support, can be
omitted if GNUnet is configured with @code{--disable-documentation})
@@ -646,22 +646,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 `offline' machine
+offline — manages the offline key, on a separate `offline' machine
@end itemize
@end quotation
@@ -681,10 +681,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
@@ -701,16 +701,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
@@ -742,7 +742,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.
@@ -750,7 +750,7 @@ This section discusses configuration options related to the auditor.
* Configuration format::
* Initial configuration::
* Keys::
-* Configuring the auditor's REST endpoint::
+* Configuring the auditor’s REST endpoint::
* Bank account::
* Database::
* Legal conditions for using the service::
@@ -865,7 +865,7 @@ BASE_URL = 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:
@@ -877,14 +877,14 @@ BASE_URL = https://exchange.example.com/
MASTER_PUBLIC_KEY = $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{12}@anchor{taler-auditor-manual keys}@anchor{13}
@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 `offline' (and backed up adequately). As with the exchange's
+a particular exchange’s denomination keys. This key can and should
+be kept `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.
@@ -926,9 +926,9 @@ You can set this configuration value using:
PUBLIC_KEY = $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{14}@anchor{taler-auditor-manual configuring-the-auditor-s-rest-endpoint}@anchor{15}
-@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.
@@ -954,7 +954,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{16}@anchor{taler-auditor-manual bank-account}@anchor{17}
@section Bank account
@@ -997,14 +997,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
@@ -1050,7 +1050,7 @@ setup and configure the legal conditions.
@section Terms of Service
-The service has an endpoint "/terms" to return the terms of service (in legal
+The service has an endpoint “/terms” to return the terms of service (in legal
language) of the service operator. Client software show these terms of
service to the user when the user is first interacting with the service.
Terms of service are optional for experimental deployments, if none are
@@ -1064,7 +1064,7 @@ in the configuration file for the service:
@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
@@ -1081,7 +1081,7 @@ process.
@section Privacy Policy
-The service has an endpoint "/pp" to return the terms privacy policy (in legal
+The service has an endpoint “/pp” to return the terms privacy policy (in legal
language) of the service operator. Clients should show the privacy policy to
the user when the user explicitly asks for it, but it should not be shown by
default. Privacy policies are optional for experimental deployments, if none
@@ -1095,7 +1095,7 @@ in the configuration file for the service:
@itemize -
@item
-@code{PRIVACY_ETAG}: The current "Etag" to return for the privacy policy.
+@code{PRIVACY_ETAG}: The current “Etag” to return for the privacy policy.
This value must be changed whenever the privacy policy is
updated. A common value to use would be a version number.
Note that if you change the @code{PRIVACY_ETAG}, you MUST also provide
@@ -1116,7 +1116,7 @@ The @code{TERMS_DIR} and @code{PRIVACY_DIR} directory structures must follow a
particular layout. You may use the same directory for both the terms of
service and the privacy policy, as long as you use different ETAGs. Inside of
the directory, there should be sub-directories using two-letter language codes
-like "en", "de", or "jp". Each of these directories would then hold
+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.
@@ -1124,7 +1124,7 @@ Then, inside each language directory, files with the name of the value set as
the @code{TERMS_ETAG} or @code{PRIVACY_ETAG} must be provided. The extension of each
of the files should be typical for the respective mime type. The set of
supported mime types is currently hard-coded in the service, and includes
-".epub", ".html", ".md", ".pdf" and ".txt" files. If other files are present,
+“.epub”, “.html”, “.md”, “.pdf” and “.txt” files. If other files are present,
the service may show a warning on startup.
@menu
@@ -1137,7 +1137,7 @@ the service may show a warning on startup.
@subsection Example
-A sample file structure for a @code{TERMS_ETAG} of "tos-v0" would be:
+A sample file structure for a @code{TERMS_ETAG} of “tos-v0” would be:
@itemize -
@@ -1173,8 +1173,8 @@ TERMS_DIR/de/tos-v0.epub
TERMS_DIR/de/tos-v0.md
@end itemize
-If the user requests an HTML format with language preferences "fr" followed by
-"en", the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
+If the user requests an HTML format with language preferences “fr” followed by
+“en”, the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
French.
@node Generating the Legal Terms,Adding translations,Legal policies directory layout,Configuration
@@ -1264,7 +1264,7 @@ restart the service.
@anchor{taler-auditor-manual wallets}@anchor{24}
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.
@@ -1272,7 +1272,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::
@@ -1286,13 +1286,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
@@ -1302,7 +1302,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.
@@ -1340,7 +1340,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
@@ -1375,21 +1375,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
-`exchange''s database in-house. This should be performed in two steps
+`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.
@@ -1405,7 +1405,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.
@@ -1418,10 +1418,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
@@ -1435,7 +1435,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.
@@ -1458,7 +1458,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
@@ -1474,7 +1474,7 @@ CONFIG = "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
@@ -1491,7 +1491,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
@@ -1506,20 +1506,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
@@ -1557,11 +1557,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
@@ -1587,7 +1587,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
@@ -1637,7 +1637,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:
@@ -1703,14 +1703,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}
@@ -1755,7 +1755,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.
@@ -1764,12 +1764,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 `42'.
@@ -1801,15 +1801,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.
@@ -1818,22 +1818,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{3b}
-@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{3c}
@section Invariants checked by the auditor
@@ -1858,7 +1858,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:
@@ -1970,7 +1970,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:
@@ -1978,9 +1978,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).
@@ -2076,7 +2076,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:
@@ -2138,11 +2138,11 @@ target account does not match origin account
This auditor is special in that it is the only pass that is required to have
-`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
+`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:
@@ -2204,7 +2204,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
@@ -2217,13 +2217,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-developer-manual.texi b/texinfo/taler-developer-manual.texi
index 1468879c..a71c9399 100644
--- a/texinfo/taler-developer-manual.texi
+++ b/texinfo/taler-developer-manual.texi
@@ -10,7 +10,7 @@
@paragraphindent 0
@exampleindent 4
@finalout
-@dircategory Networking
+@dircategory Network applications
@direntry
* GNU Taler Development: (taler-developer-manual.info). Manual for GNU Taler contributors
@end direntry
@@ -23,7 +23,7 @@ GNU Taler 0.9.4, Mar 07, 2024
GNU Taler team
-Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+Copyright @copyright{} 2014-2024 Taler Systems SA (GPLv3+ or GFDL 1.3+)
@end quotation
@end copying
@@ -112,15 +112,15 @@ overview:
exchange: core payment processing logic with a REST API, plus various
helper processes for interaction with banks and cryptographic
computations. Also includes the logic for the auditor and an
-in-memory "bank" API implementation for testing.
+in-memory “bank” API implementation for testing.
@item
-libeufin: implementation of the "bank" API using the EBICS protocol
+libeufin: implementation of the “bank” API using the EBICS protocol
used by banks in the EU. Allows an exchange to interact with
European banks.
@item
-deploymerization: implementation of the "bank" API on top of
+deploymerization: implementation of the “bank” API on top of
blockchains, specifically Bitcoin and Ethereum. Allows an exchange
to interact with crypto-currencies.
@@ -179,7 +179,7 @@ sending invoices or payments to other wallets.
@item
taler-merchant-demos: various demonstration services operated at
-'demo.taler.net', including a simple shop and a donation page.
+‘demo.taler.net’, including a simple shop and a donation page.
@end itemize
@end quotation
@@ -352,7 +352,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
@@ -625,7 +625,7 @@ $ curl -fsSL https://get.docker.com/rootless | sh
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.
Please use the demo upgrade checklist to make
sure everything is working.
Nginx is already configured to reach the services as exported by
@@ -727,7 +727,7 @@ taler-wallet-cli api 'runIntegrationTestV2' '@{"exchangeBaseUrl":"https://exchan
@subsection Wallets
-We consider the following published wallets to be "production wallets":
+We consider the following published wallets to be “production wallets”:
@itemize *
@@ -977,7 +977,7 @@ fulfillment page.
add product with 1 in stock and preview image
@item
- add "advanced" order with inventory product and a 2 minute wire delay
+ add “advanced” order with inventory product and a 2 minute wire delay
@item
claim order, check available stock goes down in inventory
@@ -1145,7 +1145,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.
@@ -1163,7 +1163,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>}
@@ -1287,7 +1287,7 @@ The results are then published at @code{https://lcov.taler.net/}.
@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.
@@ -1451,7 +1451,7 @@ Bank-integrated withdrawal
@itemize *
@item
-webext: "Continue with Mobile Wallet" flow
+webext: “Continue with Mobile Wallet” flow
@end itemize
@item
@@ -1468,10 +1468,10 @@ Currency conversion withdrawal
@end itemize
@item
-Peer push payments ("Send Money")
+Peer push payments (“Send Money”)
@item
-Peer pull payments ("Receive Money")
+Peer pull payments (“Receive Money”)
@item
Deposit into bank account
@@ -1499,7 +1499,7 @@ on survey
directly initiated via merchant SPA
@item
-webext: "Pay with Mobile Wallet" flow
+webext: “Pay with Mobile Wallet” flow
@end itemize
@item
@@ -1633,7 +1633,7 @@ Add Taler Bank Revenue API
Check bank transfer list (for wire transfer of previously paid+wired order)
@item
-Check order payment status goes to "final" automatically
+Check order payment status goes to “final” automatically
@end itemize
@item
@@ -1854,10 +1854,10 @@ For exchange:
@itemize -
@item
- no compiler warnings at "-Wall" with gcc
+ no compiler warnings at “-Wall” with gcc
@item
- no compiler warnings at "-Wall" with clang
+ no compiler warnings at “-Wall” with clang
@item
ensure Coverity static analysis passes
@@ -1866,7 +1866,7 @@ For exchange:
make check.
@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.
@@ -1881,7 +1881,7 @@ For exchange:
verify dist builds from source
@item
- upgrade 'demo.taler.net'
+ upgrade ‘demo.taler.net’
@item
run demo upgrade checklist
@@ -1890,13 +1890,13 @@ For exchange:
tag repo.
@item
- use 'deployment.git/packaging/*-docker/' to build Debian and Ubuntu packages
+ use ‘deployment.git/packaging/*-docker/’ to build Debian and Ubuntu packages
@item
- upload packages to 'deb.taler.net' (note: only Florian/Christian can sign)
+ upload packages to ‘deb.taler.net’ (note: only Florian/Christian can sign)
@item
- change 'demo.taler.net' deployment to use new tag.
+ change ‘demo.taler.net’ deployment to use new tag.
@item
Upload triplet to ftp-upload.gnu.org/incoming/ftp or /incoming/alpha
@@ -1908,10 +1908,10 @@ For merchant (C backend):
@itemize -
@item
- no compiler warnings at "-Wall" with gcc
+ no compiler warnings at “-Wall” with gcc
@item
- no compiler warnings at "-Wall" with clang
+ no compiler warnings at “-Wall” with clang
@item
ensure Coverity static analysis passes
@@ -1920,7 +1920,7 @@ For merchant (C backend):
make check.
@item
- make dist, make check on result of 'make dist'.
+ make dist, make check on result of ‘make dist’.
@item
update SPA (prebuilt branch)
@@ -1935,7 +1935,7 @@ For merchant (C backend):
verify dist builds from source
@item
- upgrade 'demo.taler.net'
+ upgrade ‘demo.taler.net’
@item
run demo upgrade checklist
@@ -1944,13 +1944,13 @@ For merchant (C backend):
tag repo.
@item
- use 'deployment.git/packaging/*-docker/' to build Debian and Ubuntu packages
+ use ‘deployment.git/packaging/*-docker/’ to build Debian and Ubuntu packages
@item
- upload packages to 'deb.taler.net' (note: only Florian/Christian can sign)
+ upload packages to ‘deb.taler.net’ (note: only Florian/Christian can sign)
@item
- change 'demo.taler.net' deployment to use new tag.
+ change ‘demo.taler.net’ deployment to use new tag.
@item
Upload triplet to ftp-upload.gnu.org/incoming/ftp or /incoming/alpha
@@ -1962,10 +1962,10 @@ For sync:
@itemize -
@item
- no compiler warnings at "-Wall" with gcc
+ no compiler warnings at “-Wall” with gcc
@item
- no compiler warnings at "-Wall" with clang
+ no compiler warnings at “-Wall” with clang
@item
ensure Coverity static analysis passes
@@ -1974,7 +1974,7 @@ For sync:
make check.
@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.
@@ -1986,7 +1986,7 @@ For sync:
verify dist builds from source
@item
- upgrade 'demo.taler.net'
+ upgrade ‘demo.taler.net’
@item
run demo upgrade checklist
@@ -1995,13 +1995,13 @@ For sync:
tag repo.
@item
- use 'deployment.git/packaging/*-docker/' to build Debian and Ubuntu packages
+ use ‘deployment.git/packaging/*-docker/’ to build Debian and Ubuntu packages
@item
- upload packages to 'deb.taler.net' (note: only Florian/Christian can sign)
+ upload packages to ‘deb.taler.net’ (note: only Florian/Christian can sign)
@item
- change 'demo.taler.net' deployment to use new tag.
+ change ‘demo.taler.net’ deployment to use new tag.
@item
Upload triplet to ftp-upload.gnu.org/incoming/ftp or /incoming/alpha
@@ -2013,7 +2013,7 @@ For taler-mdb:
@itemize -
@item
- no compiler warnings at "-Wall" with gcc
+ no compiler warnings at “-Wall” with gcc
@item
ensure Coverity static analysis passes
@@ -2028,10 +2028,10 @@ For taler-mdb:
tag repo.
@item
- use 'deployment.git/packaging/*-docker/' to build Debian and Ubuntu packages
+ use ‘deployment.git/packaging/*-docker/’ to build Debian and Ubuntu packages
@item
- upload packages to 'deb.taler.net' (note: only Florian/Christian can sign)
+ upload packages to ‘deb.taler.net’ (note: only Florian/Christian can sign)
@item
Upload triplet to ftp-upload.gnu.org/incoming/ftp or /incoming/alpha
@@ -2043,10 +2043,10 @@ For taler-twister:
@itemize -
@item
- no compiler warnings at "-Wall" with gcc
+ no compiler warnings at “-Wall” with gcc
@item
- no compiler warnings at "-Wall" with clang
+ no compiler warnings at “-Wall” with clang
@item
ensure Coverity static analysis passes
@@ -2055,7 +2055,7 @@ For taler-twister:
make check.
@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.
@@ -2067,7 +2067,7 @@ For taler-twister:
verify dist builds from source
@item
- upgrade 'demo.taler.net'
+ upgrade ‘demo.taler.net’
@item
run demo upgrade checklist
@@ -2091,7 +2091,7 @@ For libeufin:
build libeufin
@item
- upgrade 'demo.taler.net'
+ upgrade ‘demo.taler.net’
@item
run demo upgrade checklist
@@ -2106,13 +2106,13 @@ For libeufin:
tag repo.
@item
- use 'deployment.git/packaging/*-docker/' to build Debian and Ubuntu packages
+ use ‘deployment.git/packaging/*-docker/’ to build Debian and Ubuntu packages
@item
- upload packages to 'deb.taler.net' (note: only Florian/Christian can sign)
+ upload packages to ‘deb.taler.net’ (note: only Florian/Christian can sign)
@item
- change 'demo.taler.net' deployment to use new tag.
+ change ‘demo.taler.net’ deployment to use new tag.
@item
Upload triplet to ftp-upload.gnu.org/incoming/ftp or /incoming/alpha
@@ -2124,13 +2124,13 @@ For Python merchant frontend:
@itemize -
@item
- upgrade 'demo.taler.net'
+ upgrade ‘demo.taler.net’
@item
run demo upgrade checklist
@item
- change 'demo.taler.net' deployment to use new tag.
+ change ‘demo.taler.net’ deployment to use new tag.
@end itemize
Wallet-core:
@@ -2154,13 +2154,13 @@ Wallet-core:
tag repo.
@item
- use 'deployment.git/packaging/*-docker/' to build Debian and Ubuntu packages
+ use ‘deployment.git/packaging/*-docker/’ to build Debian and Ubuntu packages
@item
- upload packages to 'deb.taler.net' (note: only Florian/Christian can sign)
+ upload packages to ‘deb.taler.net’ (note: only Florian/Christian can sign)
@item
- change 'demo.taler.net' deployment to use new tag.
+ change ‘demo.taler.net’ deployment to use new tag.
@item
Upload triplet to ftp-upload.gnu.org/incoming/ftp or /incoming/alpha
@@ -2332,7 +2332,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
@@ -2423,21 +2423,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,iOS Apps,Continuous integration,Top
@anchor{taler-developer-manual internationalization}@anchor{42}
@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.
@@ -2525,7 +2525,7 @@ Under `https://weblate.taler.net/create/component/vcs/':
`Repository push URL' - This is generally @code{git+ssh://git@@git.taler.net/<reponame>`} Check with @code{git remote -v}.
@item
-`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.
+`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
`Merge style' - `Rebase', in line with GNU Taler development procedures
@@ -2550,7 +2550,7 @@ Under `https://weblate.taler.net/create/component/vcs/':
4 - Choose the `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.
@@ -2561,7 +2561,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 `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 `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.
@@ -2574,7 +2574,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 iOS Apps,Android Apps,Internationalization,Top
@anchor{taler-developer-manual ios-apps}@anchor{4b}
@@ -2619,7 +2619,7 @@ and the
wallet-core repo@footnote{https://git.taler.net/wallet-core.git}.
Have all 3 local repos (wallet-core, quickjs-tart, and this one) adjacent at
-the same level (e.g. in a "GNU_Taler" folder)
+the same level (e.g. in a “GNU_Taler” folder)
Taler.xcworkspace expects the QuickJS framework sub-project to be at
@code{../quickjs-tart/QuickJS-rt.xcodeproj}.
@@ -2631,12 +2631,12 @@ $ make embedded
$ open packages/taler-wallet-embedded/dist
@end example
-then drag or move its product "taler-wallet-core-qjs.mjs"
+then drag or move its product “taler-wallet-core-qjs.mjs”
into your quickjs-tart folder right at the top level.
-Open Taler.xcworkspace, and set scheme / target to Taler_Wallet. Build&run...
+Open Taler.xcworkspace, and set scheme / target to Taler_Wallet. Build&run…
-Don't open QuickJS-rt.xcodeproj or TalerWallet.xcodeproj and build anything
+Don’t open QuickJS-rt.xcodeproj or TalerWallet.xcodeproj and build anything
there - all needed libraries and frameworks will be built automatically from
Taler.xcworkspace.
@@ -2679,7 +2679,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.
@@ -2729,7 +2729,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
@@ -2746,12 +2746,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
@@ -2784,8 +2784,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/}.
@@ -2795,7 +2795,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
@@ -2861,7 +2861,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:
@@ -2963,22 +2963,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
@@ -3011,22 +3011,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
@@ -3068,14 +3068,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
@@ -3095,7 +3095,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
@@ -3105,7 +3105,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
@@ -3191,7 +3191,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
@@ -3309,21 +3309,21 @@ used in the user interface and help materials.
Refreshing is the internal technical terminology for the protocol to
give change for partially spent coins
-`Use instead': "Obtaining change"
+`Use instead': “Obtaining change”
@item Charge
Charge has two opposite meanings (charge to a credit card vs. charge a battery).
This can confuse users.
-`Use instead': "Obtain", "Credit", "Debit", "Withdraw", "Top up"
+`Use instead': “Obtain”, “Credit”, “Debit”, “Withdraw”, “Top up”
@item Coin
Coins are an internal construct, the user should never be aware that their balance
is represented by coins of different denominations.
-`Use instead': "(Digital) Cash" or "(Wallet) Balance"
+`Use instead': “(Digital) Cash” or “(Wallet) Balance”
@item Consumer
@@ -3338,7 +3338,7 @@ of the signed contract terms for an order.
`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
@@ -3346,14 +3346,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).
-`Use instead': "Privacy-preserving", "Privacy-friendly"
+`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.
-`Use instead': In the event history, "re-activated digital content purchase"
+`Use instead': In the event history, “re-activated digital content purchase”
could be used. (FIXME: this is still not nice.)
@item Session ID
@@ -3389,16 +3389,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
@@ -3406,12 +3406,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
@@ -3420,7 +3420,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
@@ -3449,7 +3449,7 @@ absolute time in contrast to @ref{6c,,relative time}.
the @ref{6e,,exchange} combines multiple payments received by the
same @ref{6f,,merchant} into one larger @ref{70,,wire transfer} to
-the respective merchant's @ref{71,,bank} account
+the respective merchant’s @ref{71,,bank} account
@anchor{taler-developer-manual term-auditor}@anchor{72}
@geindex auditor
@@ -3535,7 +3535,7 @@ exchange to credit his bank account in the future using an
a @ref{76,,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{83}
@geindex drain
@@ -3550,7 +3550,7 @@ their regular business account
@item empty
a @ref{7a,,reserve} is being emptied when a @ref{74,,wallet} is using the
-reserve's private key to @ref{7c,,withdraw} coins from it. This reduces
+reserve’s private key to @ref{7c,,withdraw} coins from it. This reduces
the balance of the reserve. Once the balance reaches zero, we say that
the reserve has been (fully) emptied. Reserves that are not emptied
(which is the normal process) are @ref{79,,closed} by the exchange.
@@ -3559,7 +3559,7 @@ the reserve has been (fully) emptied. Reserves that are not emptied
@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{84}
@geindex expired
@@ -3570,7 +3570,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
@@ -3685,7 +3685,7 @@ a coin is owned by the entity that knows the private key of the coin
@item planchet
-precursor data for a @ref{76,,coin}. A planchet includes the coin's internal
+precursor data for a @ref{76,,coin}. A planchet includes the coin’s internal
secrets (coin private key, blinding factor), but lacks the RSA signature
of the @ref{6e,,exchange}. When @ref{7c,,withdrawing}, a @ref{74,,wallet}
creates and persists a planchet before asking the exchange to sign it to
@@ -3775,7 +3775,7 @@ contrast to @ref{6a,,absolute time}.
accounting mechanism used by the exchange to track customer funds
from incoming @ref{70,,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{74,,wallet}
+in the subject. The exchange then allows the customer’s @ref{74,,wallet}
to @ref{7c,,withdraw} up to the amount received in @ref{88,,fresh}
@ref{76,,coins} from the reserve, thereby emptying the reserve. If a
reserve is not emptied, the exchange will eventually @ref{79,,close} it.
@@ -3805,7 +3805,7 @@ denomination are subjected to recoup.
@item sharing
-users can share ownership of a @ref{76,,coin} by sharing access to the coin&#39;s
+users can share ownership of a @ref{76,,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{75}
@@ -3864,7 +3864,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{a2}
@geindex WebExtension
diff --git a/texinfo/taler-exchange.texi b/texinfo/taler-exchange.texi
index 8d722690..9cf2dac9 100644
--- a/texinfo/taler-exchange.texi
+++ b/texinfo/taler-exchange.texi
@@ -10,7 +10,7 @@
@paragraphindent 0
@exampleindent 4
@finalout
-@dircategory Networking
+@dircategory Network applications
@direntry
* GNU Taler Exchange: (taler-exchange.info). Taler payment service provider
@end direntry
@@ -23,7 +23,7 @@ GNU Taler 0.9.4, Mar 07, 2024
GNU Taler team
-Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+Copyright @copyright{} 2014-2024 Taler Systems SA (GPLv3+ or GFDL 1.3+)
@end quotation
@end copying
@@ -315,7 +315,7 @@ subsystem. Such intermediary system abstracts the native banking protocol by
exposing the `Taler Wire Gateway API'; this way, the exchange can conduct its
banking operations in a simplified and JSON-based style.
-When customers wire money to the exchange's bank account, the Taler Wire
+When customers wire money to the exchange’s bank account, the Taler Wire
Gateway API must notify the exchange about the incoming wire transfers. The
exchange then creates a `reserve' based on the subject of the wire
transfer. The wallet which knows the secret key matching the wire transfer
@@ -352,7 +352,7 @@ binary is the @code{taler-exchange-httpd}.
`Crypto-Helpers':
The @code{taler-exchange-secmod-rsa}, @code{taler-exchange-secmod-cs} and
@code{taler-exchange-secmod-eddsa}
-are three programs that are responsible for managing the exchange's
+are three 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.
@@ -371,7 +371,7 @@ excessively frequent transfers. The binary is the
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
@@ -411,7 +411,7 @@ process using libtalerfakebank. Note that this adapter is only
useful for tests, as all transaction data is kept in memory.
@item
-For production, `libeufin''s @code{libeufin-nexus} component
+For production, `libeufin'’s @code{libeufin-nexus} component
implements a wire adapter towards the traditional SEPA banking
system with IBAN accounts using the EBICS protocol.
@@ -444,7 +444,7 @@ computes the expected bank balance, revenue and risk exposure of the
exchange operator. The main binary is the @code{taler-auditor}.
Aside from the key setup procedures, the most critical setup for
deploying an auditor is providing the auditor with an up-to-date
-copy of the exchange's database.
+copy of the exchange’s database.
@end itemize
@node Key Types,Offline keys,Architecture overview,Introduction
@@ -470,14 +470,14 @@ denomination keys (signs digital coins)
security module keys (signs online message signing 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).
Most of the keys are managed fully automatically or configured as part of the
denomination configuration. Some configuration settings must be manually
-set with regards to the exchange's master key.
+set with regards to the exchange’s master key.
@node Offline keys,Online signing key security,Key Types,Introduction
@anchor{taler-exchange-manual offline-keys}@anchor{9}
@@ -486,7 +486,7 @@ set with regards to the exchange's master key.
The exchange (and ideally also its auditor(s)) 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
@@ -547,7 +547,7 @@ expires or if they are informed about a key having been revoked.
From a security point of view, the helpers are designed to `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.
@@ -567,7 +567,7 @@ 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. To get any
security benefit from this, 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
+under its own user ID. The @code{taler-exchange-httpd} service’s will securely
communicate with the helpers using UNIX domain sockets.
@node Configuration,,Setup,Online signing key security
@@ -594,7 +594,7 @@ try to mitigate against.
We recommend the setup of offline signing keys to be done on a second machine that
does not have Internet access.
-In this guide's shell-session fragments, the command prompt shows two pieces
+In this guide’s shell-session fragments, the command prompt shows two pieces
of information:
@@ -705,7 +705,7 @@ backend:
@itemize -
@item
-"Sphinx RTD Theme" Python package aka @code{python3-sphinx-rtd-theme}
+“Sphinx RTD Theme” Python package aka @code{python3-sphinx-rtd-theme}
on Debian-based systems (for GNUnet documentation support, can be
omitted if GNUnet is configured with @code{--disable-documentation})
@@ -802,7 +802,7 @@ In any case, if @code{make check} fails, please consider filing a
bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.
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!
After installing GNUnet, unpack the GNU Taler exchange tarball,
@@ -1216,7 +1216,7 @@ for generating configuration files under @code{deployment/netzbon/}.
@chapter Exchange Database Setup
-The access credentials for the exchange's database are configured in
+The access credentials for the exchange’s database are configured in
@code{/etc/taler/secrets/exchange-db.secret.conf}. Currently, only PostgreSQL is
supported as a database backend.
@@ -1401,7 +1401,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?
@@ -1561,10 +1561,10 @@ this offline signing machine are:
@itemize *
@item
-Generation of the exchange's offline master signing key.
+Generation of the exchange’s offline master signing key.
@item
-Secure storage of the exchange's offline master signing key.
+Secure storage of the exchange’s offline master signing key.
@item
Generation of certificates (signed with the offline master signing key) that will be imported by the exchange.
@@ -1660,7 +1660,7 @@ have two key pieces of information from that setup:
@itemize *
@item
-The username and password to access the exchange's account in the system.
+The username and password to access the exchange’s account in the system.
@item
The @code{payto://} URI of that account (see RFC 8905@footnote{https://www.rfc-editor.org/rfc/rfc8905}).
@@ -1785,7 +1785,7 @@ Such a wire gateway configuration can be tested with the following commands:
--section exchange-accountcredentials-1 --credit-history
@end example
-On success, you will see some of your account's transaction history (or an
+On success, you will see some of your account’s transaction history (or an
empty history), while on failure you should see an error message.
@node Legal Setup,KYC Configuration,Wire Gateway Setup,Top
@@ -1839,7 +1839,7 @@ setup and configure the legal conditions.
@section Terms of Service
-The service has an endpoint "/terms" to return the terms of service (in legal
+The service has an endpoint “/terms” to return the terms of service (in legal
language) of the service operator. Client software show these terms of
service to the user when the user is first interacting with the service.
Terms of service are optional for experimental deployments, if none are
@@ -1853,7 +1853,7 @@ in the configuration file for the service:
@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
@@ -1870,7 +1870,7 @@ process.
@section Privacy Policy
-The service has an endpoint "/pp" to return the terms privacy policy (in legal
+The service has an endpoint “/pp” to return the terms privacy policy (in legal
language) of the service operator. Clients should show the privacy policy to
the user when the user explicitly asks for it, but it should not be shown by
default. Privacy policies are optional for experimental deployments, if none
@@ -1884,7 +1884,7 @@ in the configuration file for the service:
@itemize -
@item
-@code{PRIVACY_ETAG}: The current "Etag" to return for the privacy policy.
+@code{PRIVACY_ETAG}: The current “Etag” to return for the privacy policy.
This value must be changed whenever the privacy policy is
updated. A common value to use would be a version number.
Note that if you change the @code{PRIVACY_ETAG}, you MUST also provide
@@ -1905,7 +1905,7 @@ The @code{TERMS_DIR} and @code{PRIVACY_DIR} directory structures must follow a
particular layout. You may use the same directory for both the terms of
service and the privacy policy, as long as you use different ETAGs. Inside of
the directory, there should be sub-directories using two-letter language codes
-like "en", "de", or "jp". Each of these directories would then hold
+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.
@@ -1913,7 +1913,7 @@ Then, inside each language directory, files with the name of the value set as
the @code{TERMS_ETAG} or @code{PRIVACY_ETAG} must be provided. The extension of each
of the files should be typical for the respective mime type. The set of
supported mime types is currently hard-coded in the service, and includes
-".epub", ".html", ".md", ".pdf" and ".txt" files. If other files are present,
+“.epub”, “.html”, “.md”, “.pdf” and “.txt” files. If other files are present,
the service may show a warning on startup.
@menu
@@ -1926,7 +1926,7 @@ the service may show a warning on startup.
@subsection Example
-A sample file structure for a @code{TERMS_ETAG} of "tos-v0" would be:
+A sample file structure for a @code{TERMS_ETAG} of “tos-v0” would be:
@itemize -
@@ -1962,8 +1962,8 @@ TERMS_DIR/de/tos-v0.epub
TERMS_DIR/de/tos-v0.md
@end itemize
-If the user requests an HTML format with language preferences "fr" followed by
-"en", the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
+If the user requests an HTML format with language preferences “fr” followed by
+“en”, the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
French.
@node Generating the Legal Terms,Adding translations,Legal policies directory layout,Legal Setup
@@ -2076,7 +2076,7 @@ Wallet receives money via P2P payments over a threshold
Merchant receives money over a threshold
@item
-Reserve is "opened" for invoicing (`planned feature')
+Reserve is “opened” for invoicing (`planned feature')
@end itemize
@end quotation
@@ -2275,7 +2275,7 @@ specific backend.
The Challenger service for address validation supports OAuth2.0, but does not
have a static AUTHORIZE_URL. Instead, the AUTHORIZE_URL must be enabled by the client
-using a special authenticated request to the Challenger's @code{/setup} endpoint.
+using a special authenticated request to the Challenger’s @code{/setup} endpoint.
The exchange supports this by appending @code{#setup} to the AUTHORIZE_URL (note
that fragments are illegal in OAuth2.0 URLs). Be careful to quote the URL,
as @code{#} is otherwise interpreted as the beginning of a comment by the
@@ -2640,7 +2640,7 @@ via a management HTTP API.
@item
The offline signing system validates this request and signs it.
Additionally, the offline signing system signs policy messages
-to configure the exchange's bank accounts and associated fees.
+to configure the exchange’s bank accounts and associated fees.
@item
The messages generated by the offline signing system are uploaded
@@ -2799,7 +2799,7 @@ 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 (using @code{taler-auditor-offline setup}) and the
-URL of it's REST API. The exchange operator also needs a human-readable name
+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. For more information on
how to setup and operate an auditor, see
manpages/taler-auditor-offline.1 and taler-auditor-manual.
@@ -2886,11 +2886,11 @@ which staff has access to the AML operations:
upload < aml.json
@end example
-The above commands would add an AML officer with the given "Legal Name" with
-read-write (rw) access to the AML officer database. Using "ro" instead of
-"rw" would grant read-only access to the data, leaving out the ability to
+The above commands would add an AML officer with the given “Legal Name” with
+read-write (rw) access to the AML officer database. Using “ro” instead of
+“rw” would grant read-only access to the data, leaving out the ability to
actually make AML decisions. Once AML access has been granted, the AML
-officer can use the SPA to review cases and (with "rw" access) take AML
+officer can use the SPA to review cases and (with “rw” access) take AML
decisions.
Access rights can be revoked at any time using:
@@ -2951,8 +2951,8 @@ KYC_AML_TRIGGER = taler-exchange-kyc-aml-pep-trigger.sh
The given program will be given the KYC attributes in JSON format on standard
input, and must return 0 to continue without AML and non-zero to flag the
account for manual review. To disable this trigger, simply leave the option to
-its default value of '[/usr/bin/]true'. To flag all new users for manual
-review, simply set the program to '[/usr/bin/]false'.
+its default value of ‘[/usr/bin/]true’. To flag all new users for manual
+review, simply set the program to ‘[/usr/bin/]false’.
@node AML Forms,,AML Triggers,AML Configuration
@anchor{taler-exchange-manual aml-forms}@anchor{4a}
@@ -2987,7 +2987,7 @@ See DD 54 dynamic forms.
@cartouche
@quotation Attention
do not remove a form the list if it has been used. Otherwise you
-won't be able to see the information save in the exchange database.
+won’t be able to see the information save in the exchange database.
@end quotation
@end cartouche
@@ -3040,7 +3040,7 @@ Show the status of the manual withdrawal operation.
$ taler-wallet-cli transactions
@end example
-At this point, a bank transfer to the exchange's bank account
+At this point, a bank transfer to the exchange’s bank account
needs to be made with the correct subject / remittance information
as instructed by the wallet after the first step. With the
above configuration, it should take about 5 minutes after the
@@ -3088,10 +3088,10 @@ $ taler-wallet-cli transactions
@end example
If the transaction failed, fix any open issue(s) with the exchange and
-run the "run-pending" command.
+run the “run-pending” command.
The wallet can also track if the exchange wired the money to the merchant
-account. The "deposit group id" can be found in the output of the
+account. The “deposit group id” can be found in the output of the
transactions list.
@example
@@ -3198,7 +3198,7 @@ disks of the system.
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
@@ -3480,7 +3480,7 @@ user to understand the error
debug: Bool; true if we are running in debug mode and are allowed to return HTML with potentially sensitive information
@item
-server_response: Object; could be NULL; this includes the (malformed) OAuth2 server response, it should be shown to the use if "debug" is true
+server_response: Object; could be NULL; this includes the (malformed) OAuth2 server response, it should be shown to the use if “debug” is true
@end itemize
@end quotation
@@ -3516,7 +3516,7 @@ message: String; additional error message elaborating on what was bad about the
@section oauth2-conversion-failure
-Converting the KYC data into the exchange's internal
+Converting the KYC data into the exchange’s internal
format failed (HTTP 502 Bad Gateway).
This template is instantiated using the following information:
@@ -3723,7 +3723,7 @@ user to understand the error
debug: Bool; true if we are running in debug mode and are allowed to return HTML with potentially sensitive information
@item
-server_response: Object; could be NULL; this includes the (malformed) OAuth2 server response, it should be shown to the use if "debug" is true
+server_response: Object; could be NULL; this includes the (malformed) OAuth2 server response, it should be shown to the use if “debug” is true
@end itemize
@end quotation
@@ -3873,7 +3873,7 @@ $ dropdb talercheck; createdb talercheck
$ taler-unified-setup.sh -emwt -c $CONF -f -u exchange-account-1
@end example
-libeufin is GNU Taler's adapter to the core banking system using the EBICS
+libeufin is GNU Taler’s adapter to the core banking system using the EBICS
banking protocol standard. It uses a Postgres database to persist data and is
thus much slower than fakebank. If your GNU Taler deployment uses libeufin in
production, it likely makes sense to benchmark with libeufin. When using the
@@ -3913,8 +3913,8 @@ $ time taler-bank-benchmark -c "$CONF" -r 40 -p 1 -P1 -u exchange-account-2
@end example
For each `parallel' (@code{-p}) client, a number of `reserves' (@code{-r}) is first
-established by `transferring' money from a "user" account (42) to the
-Exchange's account with the respective reserve public key as wire subject.
+established by `transferring' money from a “user” account (42) to the
+Exchange’s account with the respective reserve public key as wire subject.
Processing is then handled by `parallel' (@code{-P}) service workers.
@node taler-exchange-benchmark,taler-aggregator-benchmark,taler-bank-benchmark,Benchmarking
@@ -3943,8 +3943,8 @@ $ taler-exchange-benchmark -c "$CONF".edited -u exchange-account-2 -L WARNING -n
@end example
For each `parallel' (@code{-p}) client, a number of `reserves' (@code{-r}) is first
-established by `transferring' money from a "user" account (42) to the
-Exchange's account with the respective reserve public key as wire subject.
+established by `transferring' money from a “user” account (42) to the
+Exchange’s account with the respective reserve public key as wire subject.
Next, the client will `withdraw' a `number of coins' (@code{-n}) from the
reserve and `deposit' them. Additionally, a `fraction' (@code{-R}) of the dirty
coins will then be subject to `refreshing'. For some deposits, the auditor
@@ -3988,11 +3988,11 @@ as soon as there is no more pending work).
@item
We should have some summary with the inventory of services that should be
-running. Systemd by default doesn't show this nicely. Maybe suggest running
-"systemd list-dependencies taler-exchange.target"?
+running. Systemd by default doesn’t show this nicely. Maybe suggest running
+“systemd list-dependencies taler-exchange.target”?
@item
-What happens when the TWG doesn't like one particular outgoing transaction?
+What happens when the TWG doesn’t like one particular outgoing transaction?
How to recover from that as a sysadmin when it happens in practice?
@end itemize
diff --git a/texinfo/taler-merchant-api-tutorial.texi b/texinfo/taler-merchant-api-tutorial.texi
index f8fe8ce5..adca56f5 100644
--- a/texinfo/taler-merchant-api-tutorial.texi
+++ b/texinfo/taler-merchant-api-tutorial.texi
@@ -10,7 +10,7 @@
@paragraphindent 0
@exampleindent 4
@finalout
-@dircategory Networking
+@dircategory Network applications
@direntry
* GNU Taler Merchant API: (taler-merchant-api-tutorial.info). Tutorial for using the merchant backend API
@end direntry
@@ -23,7 +23,7 @@ GNU Taler 0.9.4, Mar 07, 2024
GNU Taler team
-Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+Copyright @copyright{} 2014-2024 Taler Systems SA (GPLv3+ or GFDL 1.3+)
@end quotation
@end copying
@@ -449,7 +449,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}.
@@ -547,8 +547,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 `session ID' and `fulfillment URL' there is an
+“new” unpaid order is checked (or already in long-polling), the backend
+detects that for the browser’s `session ID' and `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.
diff --git a/texinfo/taler-merchant.texi b/texinfo/taler-merchant.texi
index 4ae98856..aee6ee73 100644
--- a/texinfo/taler-merchant.texi
+++ b/texinfo/taler-merchant.texi
@@ -10,7 +10,7 @@
@paragraphindent 0
@exampleindent 4
@finalout
-@dircategory Networking
+@dircategory Network applications
@direntry
* GNU Taler Merchant: (taler-merchant.info). Backend for merchants accepting Taler payments
@end direntry
@@ -23,7 +23,7 @@ GNU Taler 0.9.4, Mar 07, 2024
GNU Taler team
-Copyright @copyright{} 2014-2022 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+Copyright @copyright{} 2014-2024 Taler Systems SA (GPLv3+ or GFDL 1.3+)
@end quotation
@end copying
@@ -356,7 +356,7 @@ shop a request is intended for. Each instance has its own base URL in the
REST API of the merchant backend (@code{/instances/$INSTANCE/}). Each instance
can use its own bank accounts and keys for signing contracts. All major
accounting functionality is separate per instance. Access to each instance is
-controlled via a bearer token (to be set in the HTTP "Authorization" header).
+controlled via a bearer token (to be set in the HTTP “Authorization” header).
All instances share the same `database', top-level HTTP(S) address and the
main Taler configuration (especially the accepted `currency' and `exchanges').
@@ -364,12 +364,12 @@ main Taler configuration (especially the accepted `currency' and `exchanges').
@cartouche
@quotation Note
-This documentation does not use the term "user" or "username" in
+This documentation does not use the term “user” or “username” in
conjunction with instances as that might create confusion between
instances with paying customers using the system. We also do not use the
-term "account" in conjunction with instances, as that might cause
+term “account” in conjunction with instances, as that might cause
confusion with bank accounts. That said, conceptually it is of course
-acceptable to consider instances to be the "users" or "accounts" of a
+acceptable to consider instances to be the “users” or “accounts” of a
merchant backend and the bearer token is equivalent to a passphrase.
@end quotation
@end cartouche
@@ -387,7 +387,7 @@ To receive payments, an instance must have configured one or more bank
ideally also provide the address and credentials of an HTTP service
implementing the Taler Bank Revenue HTTP API. Given such a service, the GNU Taler merchant
backend can automatically reconcile wire transfers from the exchange to the
-merchant's bank account with the orders that are being settled.
+merchant’s bank account with the orders that are being settled.
This documentation exclusively uses the term `account' for the bank
accounts of a merchant or shop that may be associated with an instance.
@@ -512,13 +512,13 @@ in cases where the point-of-sale of a merchant is offline (and thus cannot
setup an order), or even in cases where a simple static QR code is desired to
accept payments or donations.
-When generating a template, the "summary" text of the contract and the
-"amount" to be paid by the customer can be fixed or left for the customer to
+When generating a template, the “summary” text of the contract and the
+“amount” to be paid by the customer can be fixed or left for the customer to
specify. If the customer is expected to provide either or both of these
values, the template link (or QR code) can specify a default value. For
-example, a cafeteria with a fixed price lunch may use a "lunch" template with
-both values fixed to the lunch price and the "lunch" product, a bakery might
-fix the summary to "baked goods" but allow the customer to enter the amount
+example, a cafeteria with a fixed price lunch may use a “lunch” template with
+both values fixed to the lunch price and the “lunch” product, a bakery might
+fix the summary to “baked goods” but allow the customer to enter the amount
based on the total price of the items being bought, and a charity may allow
donating an arbitrary amount and summary message while also suggesting default
values.
@@ -542,7 +542,7 @@ standard is described in RFC 6238@footnote{https://www.rfc-editor.org/rfc/rfc623
For GNU Taler merchant backends, OTP devices are used as a way to assure a
merchant without network connectivity that a customer made a digital
payment. The idea is described in depth in our SUERF Policy Brief@footnote{https://www.suerf.org/suer-policy-brief/69851/practical-offline-payments-using-one-time-passcodes}.
-To use this method, a merchant must configure the OTP device's shared secret
+To use this method, a merchant must configure the OTP device’s shared secret
in the merchant backend, and then associate the OTP device with a
@ref{10,,Templates}. Once the customer has paid, they are given a list of OTP
codes which must be shown to the merchant who can check that at least one of
@@ -561,7 +561,7 @@ payment.
The Taler backend can be used to verify that the exchange correctly wired all
of the funds to the merchant. However, if no Taler Bank Revenue HTTP API was provided for the respective bank account,
the backend does not have access to the incoming wire transfers of the
-merchant's bank account. In this case, merchants should manually provide the
+merchant’s bank account. In this case, merchants should manually provide the
backend with wire `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.
@@ -756,7 +756,7 @@ backend:
@itemize -
@item
-"Sphinx RTD Theme" Python package aka @code{python3-sphinx-rtd-theme}
+“Sphinx RTD Theme” Python package aka @code{python3-sphinx-rtd-theme}
on Debian-based systems (for GNUnet documentation support, can be
omitted if GNUnet is configured with @code{--disable-documentation})
@@ -853,7 +853,7 @@ In any case, if @code{make check} fails, please consider filing a
bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.
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!
After installing GNUnet, unpack the GNU Taler exchange tarball,
@@ -874,7 +874,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!
Please note that unlike most packages, if you want to run the @code{make check}
@@ -1465,16 +1465,16 @@ This is concern can be addressed using a properly configured
In order to setup an instance, you need the merchant backend to already be
-running, and you must either have the credentials for the "default" instance,
+running, and you must either have the credentials for the “default” instance,
or no instance must be configured at all yet.
To start, point your browser to @code{$PROTO://backend.$DOMAIN_NAME/}, replacing
-"$PROTO" with "https" or (rarely) "http" and "$DOMAIN_NAME" with your
+“$PROTO” with “https” or (rarely) “http” and “$DOMAIN_NAME” with your
organizations DNS domain or subdomain.
@cartouche
@quotation Note
-The label "backend" here is also just a suggestion, your administrator
+The label “backend” here is also just a suggestion, your administrator
can in principle choose any name.
@end quotation
@end cartouche
@@ -1512,7 +1512,7 @@ InstanceConfigurationMessage:
@end example
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 address. 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 account. Those
@@ -1569,7 +1569,7 @@ the left of the page. The following page should be shown:
@image{taler-merchant-figures/no_default_account_yet,,,,png}
-Click on the blue "+" sign on the top right of the page to add a new
+Click on the blue “+” sign on the top right of the page to add a new
bank account. The following page should appear:
@image{taler-merchant-figures/enter_instance_details,,,,png}
@@ -1697,15 +1697,15 @@ SERVE = unix
UNIXPATH = "/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 `may' use a
host-based firewall to block access to the TCP port of the merchant backend,
but this is `not recommended'. If you do need a TCP socket, you should
-instead strongly consider using the "BIND_TO" option to at least bind it only
-to "localhost".
+instead strongly consider using the “BIND_TO” option to at least bind it only
+to “localhost”.
@node Reverse proxy configuration,Access control,Using UNIX domain sockets,Secure setup
@anchor{taler-merchant-manual id10}@anchor{35}@anchor{taler-merchant-manual reverse-proxy-configuration}@anchor{2a}
@@ -1778,8 +1778,8 @@ users of the default instance, and to @code{$BASE_URL/instances/$ID/private/} to
the authorized users of the instance @code{$ID}.
By default, the GNU Taler merchant backend simply requires the respective
-HTTP requests to include an "Authorization" header with a "Bearer" token
-set to the respective shared secret which must begin with "secret-token:"
+HTTP requests to include an “Authorization” header with a “Bearer” token
+set to the respective shared secret which must begin with “secret-token:”
(following RFC 8959).
Note that all of the other endpoints (without @code{/private/})
@@ -1873,7 +1873,7 @@ setup and configure the legal conditions.
@section Terms of Service
-The service has an endpoint "/terms" to return the terms of service (in legal
+The service has an endpoint “/terms” to return the terms of service (in legal
language) of the service operator. Client software show these terms of
service to the user when the user is first interacting with the service.
Terms of service are optional for experimental deployments, if none are
@@ -1887,7 +1887,7 @@ in the configuration file for the service:
@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
@@ -1904,7 +1904,7 @@ process.
@section Privacy Policy
-The service has an endpoint "/pp" to return the terms privacy policy (in legal
+The service has an endpoint “/pp” to return the terms privacy policy (in legal
language) of the service operator. Clients should show the privacy policy to
the user when the user explicitly asks for it, but it should not be shown by
default. Privacy policies are optional for experimental deployments, if none
@@ -1918,7 +1918,7 @@ in the configuration file for the service:
@itemize -
@item
-@code{PRIVACY_ETAG}: The current "Etag" to return for the privacy policy.
+@code{PRIVACY_ETAG}: The current “Etag” to return for the privacy policy.
This value must be changed whenever the privacy policy is
updated. A common value to use would be a version number.
Note that if you change the @code{PRIVACY_ETAG}, you MUST also provide
@@ -1939,7 +1939,7 @@ The @code{TERMS_DIR} and @code{PRIVACY_DIR} directory structures must follow a
particular layout. You may use the same directory for both the terms of
service and the privacy policy, as long as you use different ETAGs. Inside of
the directory, there should be sub-directories using two-letter language codes
-like "en", "de", or "jp". Each of these directories would then hold
+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.
@@ -1947,7 +1947,7 @@ Then, inside each language directory, files with the name of the value set as
the @code{TERMS_ETAG} or @code{PRIVACY_ETAG} must be provided. The extension of each
of the files should be typical for the respective mime type. The set of
supported mime types is currently hard-coded in the service, and includes
-".epub", ".html", ".md", ".pdf" and ".txt" files. If other files are present,
+“.epub”, “.html”, “.md”, “.pdf” and “.txt” files. If other files are present,
the service may show a warning on startup.
@menu
@@ -1960,7 +1960,7 @@ the service may show a warning on startup.
@subsection Example
-A sample file structure for a @code{TERMS_ETAG} of "tos-v0" would be:
+A sample file structure for a @code{TERMS_ETAG} of “tos-v0” would be:
@itemize -
@@ -1996,8 +1996,8 @@ TERMS_DIR/de/tos-v0.epub
TERMS_DIR/de/tos-v0.md
@end itemize
-If the user requests an HTML format with language preferences "fr" followed by
-"en", the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
+If the user requests an HTML format with language preferences “fr” followed by
+“en”, the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
French.
@node Generating the Legal Terms,Adding translations,Legal policies directory layout,Customization
@@ -2240,7 +2240,7 @@ to increase the @code{ulimit} of the @code{taler-merchant-httpd} process if you
many static files. Note that Mustach templates do not increase the number of
open files.
-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.