diff options
Diffstat (limited to 'texinfo')
| -rw-r--r-- | texinfo/challenger.texi | 6 | ||||
| -rw-r--r-- | texinfo/taler-auditor.texi | 6 | ||||
| -rw-r--r-- | texinfo/taler-developer-manual.texi | 2 | ||||
| -rw-r--r-- | texinfo/taler-exchange.texi | 118 | ||||
| -rw-r--r-- | texinfo/taler-merchant-api-tutorial.texi | 2 | ||||
| -rw-r--r-- | texinfo/taler-merchant.texi | 10 |
6 files changed, 72 insertions, 72 deletions
diff --git a/texinfo/challenger.texi b/texinfo/challenger.texi index 53f57e43..75e90760 100644 --- a/texinfo/challenger.texi +++ b/texinfo/challenger.texi @@ -19,7 +19,7 @@ @copying @quotation -GNU Taler 0.9.4, Mar 07, 2024 +GNU Taler 0.9.4, Apr 12, 2024 GNU Taler team @@ -447,10 +447,10 @@ would look like this for Ubuntu Lunar: deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ lunar taler-lunar @end example -For Ubuntu Jammy use this instead: +For Ubuntu Mantic use this instead: @example -deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ jammy taler-jammy +deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ mantic taler-mantic @end example The last line is crucial, as it adds the GNU Taler packages. diff --git a/texinfo/taler-auditor.texi b/texinfo/taler-auditor.texi index 82ead846..92fee90d 100644 --- a/texinfo/taler-auditor.texi +++ b/texinfo/taler-auditor.texi @@ -19,7 +19,7 @@ @copying @quotation -GNU Taler 0.9.4, Mar 07, 2024 +GNU Taler 0.9.4, Apr 12, 2024 GNU Taler team @@ -581,10 +581,10 @@ would look like this for Ubuntu Lunar: deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ lunar taler-lunar @end example -For Ubuntu Jammy use this instead: +For Ubuntu Mantic use this instead: @example -deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ jammy taler-jammy +deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ mantic taler-mantic @end example The last line is crucial, as it adds the GNU Taler packages. diff --git a/texinfo/taler-developer-manual.texi b/texinfo/taler-developer-manual.texi index a71c9399..1d333657 100644 --- a/texinfo/taler-developer-manual.texi +++ b/texinfo/taler-developer-manual.texi @@ -19,7 +19,7 @@ @copying @quotation -GNU Taler 0.9.4, Mar 07, 2024 +GNU Taler 0.9.4, Apr 12, 2024 GNU Taler team diff --git a/texinfo/taler-exchange.texi b/texinfo/taler-exchange.texi index 9cf2dac9..16f3a2d9 100644 --- a/texinfo/taler-exchange.texi +++ b/texinfo/taler-exchange.texi @@ -19,7 +19,7 @@ @copying @quotation -GNU Taler 0.9.4, Mar 07, 2024 +GNU Taler 0.9.4, Apr 12, 2024 GNU Taler team @@ -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, @@ -910,10 +910,10 @@ would look like this for Ubuntu Lunar: deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ lunar taler-lunar @end example -For Ubuntu Jammy use this instead: +For Ubuntu Mantic use this instead: @example -deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ jammy taler-jammy +deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ mantic taler-mantic @end example The last line is crucial, as it adds the GNU Taler packages. @@ -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,12 +3873,12 @@ $ 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 fakebank, @code{taler-unified-setup.sh} must be started with the @code{-ns} options -(starting libeufin-nexus and libeufin-sandbox) and be told to use the right +(starting libeufin-nexus and libeufin-bank) and be told to use the right exchange bank account from the configuration files via @code{-u exchange-account-2}. Note that @code{taler-unified-setup.sh} currently cannot reset a libeufin database, and also will not run if the database is already @@ -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 adca56f5..28b57ecc 100644 --- a/texinfo/taler-merchant-api-tutorial.texi +++ b/texinfo/taler-merchant-api-tutorial.texi @@ -19,7 +19,7 @@ @copying @quotation -GNU Taler 0.9.4, Mar 07, 2024 +GNU Taler 0.9.4, Apr 12, 2024 GNU Taler team diff --git a/texinfo/taler-merchant.texi b/texinfo/taler-merchant.texi index aee6ee73..8e7582b9 100644 --- a/texinfo/taler-merchant.texi +++ b/texinfo/taler-merchant.texi @@ -19,7 +19,7 @@ @copying @quotation -GNU Taler 0.9.4, Mar 07, 2024 +GNU Taler 0.9.4, Apr 12, 2024 GNU Taler team @@ -673,10 +673,10 @@ would look like this for Ubuntu Lunar: deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ lunar taler-lunar @end example -For Ubuntu Jammy use this instead: +For Ubuntu Mantic use this instead: @example -deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ jammy taler-jammy +deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ mantic taler-mantic @end example The last line is crucial, as it adds the GNU Taler packages. @@ -1195,12 +1195,12 @@ For the @code{postgres} backend, you need to specify: @example [merchantdb-postgres] -CONFIG = "postgres:///taler-merchant" +CONFIG = "postgres:///talermerchant" @end example This option specifies a PostgreSQL access path, typically using the format @code{postgres:///$DBNAME}, where @code{$DBNAME} is the name of the PostgreSQL -database you want to use (here, @code{taler-merchant} on the local machine). +database you want to use (here, @code{talermerchant} on the local machine). Suppose @code{$USER} is the name of the user who will run the backend process (usually @code{taler-merchant-httpd}). Then, you need to first run: |