diff options
| -rw-r--r-- | design-documents/010-exchange-helpers.rst | 6 | ||||
| -rw-r--r-- | design-documents/011-auditor-db-sync.rst | 8 | ||||
| -rw-r--r-- | manpages/sync-config.1.rst | 2 | ||||
| -rw-r--r-- | manpages/taler-config.1.rst | 2 | ||||
| -rw-r--r-- | taler-auditor-manual.rst | 28 | ||||
| -rw-r--r-- | taler-developer-manual.rst | 2 | ||||
| -rw-r--r-- | taler-exchange-manual.rst | 10 | ||||
| -rw-r--r-- | taler-exchange-setup-guide.rst | 2 | ||||
| -rw-r--r-- | taler-merchant-manual.rst | 22 |
9 files changed, 41 insertions, 41 deletions
diff --git a/design-documents/010-exchange-helpers.rst b/design-documents/010-exchange-helpers.rst index e67fca4e..a12b4a20 100644 --- a/design-documents/010-exchange-helpers.rst +++ b/design-documents/010-exchange-helpers.rst @@ -13,7 +13,7 @@ Motivation We want to provide an additional layer of protection for the private online signing keys used by the exchange. The exchange is network-facing, includes an -HTTP server, Postgres interaction, JSON parser and quite a bit of other logic +HTTP server, PostgreSQL interaction, JSON parser and quite a bit of other logic which may all be theoretically vulnerable to remote exploitation. Thus, it would be good from a security perspective to protect the private online signing keys via an additional layer of protection. @@ -89,7 +89,7 @@ Exchange design considerations: exchange. This simplifies the exchange, and we already needed the exchange operator to start four processes to operate an exchange. So this number simply increases to six (not even counting the - Postgres database and a reverse HTTP proxy for TLS termination). + PostgreSQL database and a reverse HTTP proxy for TLS termination). * Each exchange thread will create its own connection to the helpers, and will block while waiting on the helper to create a signature. This keeps the exchange logic simple and similar to the existing in-line signing calls. @@ -108,7 +108,7 @@ New exchange endpoints: sign based on that file, and then upload the resulting signature back to the exchange. For this, master signatures will be POSTed to the exchange to the ``/keys`` endpoint. - The exchange will keep those signatures in the Postgres database. + The exchange will keep those signatures in the PostgreSQL database. * A new endpoint (``/auditors``) will also allow adding/removing auditors (POST, DELETE) using requests signed with the offline master private key. Once an auditor has been added, the respective auditor signatures on exchange diff --git a/design-documents/011-auditor-db-sync.rst b/design-documents/011-auditor-db-sync.rst index f8229b63..d49503d2 100644 --- a/design-documents/011-auditor-db-sync.rst +++ b/design-documents/011-auditor-db-sync.rst @@ -89,9 +89,9 @@ Proposed Solution * The auditor's "ingress" database should be well isolated from the rest of the auditor's system and database (different user accounts). The reason is that we should not - assume that the Postgres replication code is battle-tested with + assume that the PostgreSQL replication code is battle-tested with malicious parties in mind. -* The canonical Postgres synchronization between exchange and the +* The canonical PostgreSQL synchronization between exchange and the auditor's "ingress" database must use transport security. The above solution does not gracefully handle mutable tables on which @@ -148,10 +148,10 @@ A good order for replicating the tables should be: Alternatives ============ -* Copy the Postgres WAL, filter it for "illegal" operations +* Copy the PostgreSQL WAL, filter it for "illegal" operations and then apply it at the auditor end. Disadvantages: WAL filtering is not a common operation (format documented?), - this would be highly Postgres-specific, and would require + this would be highly PostgreSQL-specific, and would require complex work to write the filter. Also unsure how one could later recover gracefully from transient errors (say where the exchange recified a bogus DELETE). diff --git a/manpages/sync-config.1.rst b/manpages/sync-config.1.rst index 14c61a02..c7dd9eab 100644 --- a/manpages/sync-config.1.rst +++ b/manpages/sync-config.1.rst @@ -35,7 +35,7 @@ Description **-b** *BACKEND* \| **--supported-backend=**\ \ *BACKEND* Tests whether the specified *BACKEND* is supported by the current installation. The backend must match the name of a plugin, i.e. "namestore_postgres" for - the Postgres database backend of the "NAMESTORE" service. If *BACKEND* is + the PostgreSQL database backend of the "NAMESTORE" service. If *BACKEND* is supported, sync-config will return a status code of 0 (success), otherwise 77 (unsupported). When this option is specified, no other options may be specified. Specifying this option together with other options will cause diff --git a/manpages/taler-config.1.rst b/manpages/taler-config.1.rst index 103c95ef..14a8959b 100644 --- a/manpages/taler-config.1.rst +++ b/manpages/taler-config.1.rst @@ -35,7 +35,7 @@ Description **-b** *BACKEND* \| **--supported-backend=**\ \ *BACKEND* Tests whether the specified *BACKEND* is supported by the current installation. The backend must match the name of a plugin, i.e. "namestore_postgres" for - the Postgres database backend of the "NAMESTORE" service. If *BACKEND* is + the PostgreSQL database backend of the "NAMESTORE" service. If *BACKEND* is supported, taler-config will return a status code of 0 (success), otherwise 77 (unsupported). When this option is specified, no other options may be specified. Specifying this option together with other options will cause diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst index cf3952f8..e7aecb84 100644 --- a/taler-auditor-manual.rst +++ b/taler-auditor-manual.rst @@ -65,7 +65,7 @@ all, the goal is to detect nerfarious activity of the exchange operator, which cannot be effectively done on a machine controlled by the exchange operator. -For this, every auditor needs to operate a Postgres database. The data +For this, every auditor needs to operate a PostgreSQL database. The data collected will include sensitive information about Taler users, including withdrawals made by consumers and income received by merchants. As a result, the auditor is expected to provide high confidentiality for the database. In @@ -118,7 +118,7 @@ third parties to verify one's own work. The Taler software stack for an auditor consists of the following components: -- DBMS: Postgres +- DBMS: PostgreSQL The auditor requires a DBMS to store a local copy of the transaction history for the Taler exchange, as well as for its own internal bookkeeping and checkpointing. @@ -128,7 +128,7 @@ components: concern that must be addressed manually. The software only verifies the content of a well-formed exchange database (well-formed with respect to SQL). For now, the GNU Taler reference implementation - only supports Postgres, but the code could be easily extended to + only supports PostgreSQL, but the code could be easily extended to support another DBMS. - The auditor Web service @@ -268,7 +268,7 @@ Additionally, there are two canonical system users of relevance (which your distribution would typically create for you): * www-data --- runs the HTTPS frontend (usually nginx or Apache) - * postgres --- runs the Postgres database + * postgres --- runs the PostgreSQL database Databases and users @@ -585,7 +585,7 @@ as illustrated in the following figure: .. image:: replication.png -First, the exchange should use standard Postgres replication features to +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 never replicates malicious changes using ``taler-auditor-sync``. Both @@ -595,7 +595,7 @@ We note that as a result of these steps, the auditor will have three databases: its own production primary database (as configured in ``auditordb-postgres``), its on production copy of the exchange's database (``exchangedb-postgress``), and a third, untrusted "ingres" copy of the -exchange database. The untrusted database should run as a separate Postgres +exchange database. The untrusted database should run as a separate PostgreSQL instance and is only accessed via ``taler-auditor-sync`` and the replication mechanism driven by the exchange operator. @@ -607,7 +607,7 @@ Ingres operation should be done using the ``auditor-ingres`` user --- or depending on the setup parts of the operation may be done by the ``postgres`` user directly. -The full copy can be obtained in various ways with Postgres. It is +The full copy can be obtained in various ways with PostgreSQL. It is possible to use log shipping with streaming replication as described in https://www.postgresql.org/docs/13/warm-standby.html, or to use logical replication, as described in @@ -616,7 +616,7 @@ that asynchronous replication should suffice. The resulting auditor database should be treated as read-only on the auditor side. The ``taler-exchange-dbinit`` tool can be used to setup the schema, or -the schema can be replicated using Postgres's standard mechanisms. The same +the schema can be replicated using PostgreSQL's standard mechanisms. The same applies for schema upgrades: if logical replication is used (which does not replicate schema changes), ``taler-exchange-dbinit`` can be used to migrate the schema(s) in both the ingres and production copies of the exchange's @@ -640,7 +640,7 @@ Wireguard. It is also necessary to edit ``main.cf`` of the exchange and on the auditor side to enable logical replication. If an exchange has multiple auditors, it should setup multiple ``egress`` accounts. The exchange must ensure that -the following lines are in the ``main.cf`` Postgres configuration (the port +the following lines are in the ``main.cf`` PostgreSQL configuration (the port may differ) to enable replication over the network: .. code-block:: @@ -650,7 +650,7 @@ may differ) to enable replication over the network: wal_level= logical Equally, the auditor must configure logical replication in the ``main.cf`` -Postgres configuration: +PostgreSQL configuration: .. code-block:: @@ -677,7 +677,7 @@ system must subscribe: $ echo "CREATE PUBLICATION $NAME FOR ALL TABLES;" | psql taler-exchange -For details, we refer to the Postgres manual. +For details, we refer to the PostgreSQL manual. .. note:: @@ -686,9 +686,9 @@ For details, we refer to the Postgres manual. ``DROP`` operations on the tables. Hence, the auditor cannot rely upon the exchange's primary copy to respect schema constraints, especially as we have to presume that the exchange could act maliciously. Furthermore, it - is unclear to what degree Postgres database replication mechanisms are + is unclear to what degree PostgreSQL database replication mechanisms are robust against a malicious master database. Thus, the auditor should - isolate its primary copy of the exchange database, including the Postgres + isolate its primary copy of the exchange database, including the PostgreSQL process, from its actual operational data. @@ -708,7 +708,7 @@ While ``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 latency from the network between auditor and exchange operator. Thus, we recommend first making an "untrusted" ingress copy of the exchange's -production database using standard Postgres tooling, and then using +production database using standard PostgreSQL tooling, and then using ``taler-auditor-sync`` to create a second "safe" copy. The "safe" copy used by the production system should also run under a different UID. diff --git a/taler-developer-manual.rst b/taler-developer-manual.rst index ae99e7a2..b7f2ac4e 100644 --- a/taler-developer-manual.rst +++ b/taler-developer-manual.rst @@ -504,7 +504,7 @@ prepared. Database schema versioning -------------------------- -The Postgres databases of the exchange and the auditor are versioned. +The PostgreSQL databases of the exchange and the auditor are versioned. See the 0000.sql file in the respective directory for documentation. Every set of changes to the database schema must be stored in a new diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst index 7beb7fb7..a9574479 100644 --- a/taler-exchange-manual.rst +++ b/taler-exchange-manual.rst @@ -63,7 +63,7 @@ etc.). This manual will not cover these aspects of operating a payment service provider. We will assume that you can operate a (high-availability, -high-assurance) Postgres database. Furthermore, we expect some moderate +high-assurance) PostgreSQL database. Furthermore, we expect some moderate familiarity with the compilation and installation of free software packages. You need to understand the cryptographic concepts of private and public keys and must be able to protect private keys stored in files @@ -181,9 +181,9 @@ components: The exchange requires a DBMS to stores the transaction history for the Taler exchange and aggregator, and a (typically separate) DBMS for the Taler auditor. For now, the GNU Taler reference implementation - only supports Postgres, but the code could be easily extended to + only supports PostgreSQL, but the code could be easily extended to support another DBMS. - .. index:: Postgres + .. index:: PostgreSQL - Auditor The auditor verifies that the transactions performed by the exchange @@ -787,7 +787,7 @@ they should use the same configuration file. For the most secure deployment, we recommend using separate users for each of these processes to minimize information disclosures should any of them be -compromised. The helpers do not need access to the Postgres database (and +compromised. The helpers do not need access to the PostgreSQL database (and thus also should not have it). The processes that require access to the bank account need to have a @@ -1066,4 +1066,4 @@ repetitions (i.e. if the operation failed the first time), total execution time (operating system and user space) and other details. Naturally, additional instrumentation (including using features of the -Postgres database itself) may help discover performance issues. +PostgreSQL database itself) may help discover performance issues. diff --git a/taler-exchange-setup-guide.rst b/taler-exchange-setup-guide.rst index 1cac1f9e..ab028ee1 100644 --- a/taler-exchange-setup-guide.rst +++ b/taler-exchange-setup-guide.rst @@ -164,7 +164,7 @@ to compartmentalize different parts of the system: * ``taler-exchange-closer``: closes idle reserves by triggering wire transfers that refund the originator. * ``taler-exchange-aggregator``: aggregates deposits into larger wire transfer requests. * ``taler-exchange-wire``: performs wire transfers with the bank (via LibEuFin/Nexus). -* ``postgres``: runs the Postgres database (from *postgres* package). +* ``postgres``: runs the PostgreSQL database (from *postgres* package). * ``www-data``: runs the frontend HTTPS service with the TLS keys (from *nginx* package). .. note:: diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst index 08663d50..f568ef15 100644 --- a/taler-merchant-manual.rst +++ b/taler-merchant-manual.rst @@ -66,7 +66,7 @@ special currency “KUDOS” and includes its own special bank. .. index:: back-office .. index:: backend .. index:: DBMS -.. index:: Postgres +.. index:: PostgreSQL The Taler software stack for a merchant consists of four main components: @@ -90,8 +90,8 @@ components: describes how to install and configure this backend. - A *DBMS* which stores the transaction history for the Taler backend. For now, the GNU Taler reference implementation only supports - Postgres, but the code could be easily extended to support another - DBMS. Please review the Postgres documentation for details on + PostgreSQL, but the code could be easily extended to support another + DBMS. Please review the PostgreSQL documentation for details on how to configure the database. The following image illustrates the various interactions of these key @@ -475,7 +475,7 @@ Backend options --------------- .. index:: DBMS -.. index:: Postgres +.. index:: PostgreSQL .. index:: UNIX domain socket .. index:: TCP .. index:: port @@ -596,7 +596,7 @@ For the ``postgres`` backend, you need to provide: This option specifies a postgres access path using the format ``postgres:///$DBNAME``, where ``$DBNAME`` is the name of the -Postgres database you want to use. Suppose ``$USER`` is the name of +PostgreSQL database you want to use. Suppose ``$USER`` is the name of the user who will run the backend process. Then, you need to first run: @@ -604,7 +604,7 @@ run: $ sudo -u postgres createuser -d $USER -as the Postgres database administrator (usually ``postgres``) to +as the PostgreSQL database administrator (usually ``postgres``) to grant ``$USER`` the ability to create new databases. Next, you should as ``$USER`` run: @@ -633,7 +633,7 @@ You can improve your security posture if you now REVOKE the rights to CREATE, DROP or ALTER tables from ``$USER``. However, if you do so, please be aware that you may have to temporarily GRANT those rights again when you update the merchant backend. For details on how to REVOKE or GRANT these rights, consult -the Postgres documentation. +the PostgreSQL documentation. Commands, like ``taler-merchant-dbinit``, that support the ``-l LOGFILE`` command-line option, send logging output to standard error by default. @@ -782,7 +782,7 @@ The following is an example for a complete backend configuration: CURRENCY = KUDOS Given the above configuration, the backend will use a database named -``donations`` within Postgres. +``donations`` within PostgreSQL. The backend will deposit the coins it receives to the exchange at https://exchange.demo.taler.net/, which has the master key @@ -1281,8 +1281,8 @@ merchant. Attempting to upgrade from or to a version in Git is not supported and may result in subtle data loss. To safely upgrade the merchant, you should first stop the existing -``taler-merchant-httpd`` process, backup your merchant database (see Postgres -manual), and then install the latest version of the code. +``taler-merchant-httpd`` process, backup your merchant database (see +PostgreSQL manual), and then install the latest version of the code. If you REVOKED database permissions, ensure that the rights to CREATE, DROP, and ALTER tables are GRANTed to ``$USER`` again. Then, run: @@ -1610,7 +1610,7 @@ A relatively minimal configuration could look like this: Note that the public key must match the exchange's -private key and that the Postgres database must +private key and that the PostgreSQL database must exist before launching the benchmark. You also will need to ensure that the Exchange's details are set up. |