[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-docs] branch master updated: clarifications based on discussion w
[taler-docs] branch master updated: clarifications based on discussion with Florian
Mon, 04 Jan 2021 19:25:28 +0100
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository docs.
The following commit(s) were added to refs/heads/master by this push:
new 9b55859 clarifications based on discussion with Florian
new 97fb8a1 Merge branch 'master' of git+ssh://git.taler.net/docs
9b55859 is described below
Author: Christian Grothoff <firstname.lastname@example.org>
AuthorDate: Mon Jan 4 19:25:19 2021 +0100
clarifications based on discussion with Florian
design-documents/011-auditor-db-sync.rst | 48 ++++++++++++++++++++++++--------
1 file changed, 37 insertions(+), 11 deletions(-)
diff --git a/design-documents/011-auditor-db-sync.rst
index 71d83bd..bf8f9a5 100644
@@ -48,8 +48,13 @@ Requirements
tables due to a CASCADE from expired denomination keys).
* The synchronization mechanism should raise an alert if the exchange violates
constraints (unexpected schema changes, deletion/motification on append-only
- tables) and then NOT replicate those changes. It may then soft-fail until the
- exchange has rectified the problem.
+ tables) and then NOT replicate those changes. The auditor's internal
+ helper may then soft-fail (log and exit) until the exchange has rectified the
+ problem (by manual, human intervention resulting in an exchange master
+ that again maintains the required invariants).
+ After the corrected master database has been again synchronized with the
+ primary copy of the auditor, the auditor's helper is resumed and can
+ copy the (now valid) database records into the auditor's internal version.
* A good solution would work independently of the specific database used.
@@ -60,24 +65,34 @@ Proposed Solution
approproate for the exchange database setup, synchronous
or asynchronous) to make a 1:1 copy of the exchange database
at the auditor. This should work for any full-featured
- modern database. The copy cannot be trusted, as constraint
+ modern database. This "ingress" copy cannot be trusted, as constraint
violations or deletions would also be replicated.
-* Use helper process to SELECT against the local copy (by
+* Use helper process to SELECT against the local "ingress" copy (by
SERIAL ID => make sure all append-only tables have one!)
- to copy append-only tables to 2nd auditor-controlled copy
- of the database. Order (or transactionally group) SELECT
+ to copy append-only tables to a second, "trusted" and fully
+ auditor-controlled copy of the database.
+ Order (or transactionally group) SELECT
statements to ensure foreign key constraints are maintained.
For mutable tables (basically, only current reserve balance)
do not make another copy, but do have logic to recompute mutable
tables from other data *if* we need to recover from backup.
* On schema migration, halt exchange, once auditor DB has
- synchronized, update all DB schema, then resume DB synchronization
- and then restart exchange.
-* For GC, simply run GC logic also on auditor's "secure" copy.
+ synchronized, update all DB schema (the "ingress" DB schema
+ may be update automatically when the exchange DB schema is
+ migrated, but the "trusted" DB of the auditor must most likely
+ be manually migrated), then finally resume "ingress" to "trusted"
+ helper-based DB synchronization and restart the exchange.
+* For GC, simply run GC logic also on auditor's "trusted" copy.
(The synchronization mechanism will take care of the primary copy,
and the helper to copy should not be disturbed by the DELETE operations
+* 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
+ malicious parties in mind.
+* The canonical Postgres synchronization between exchange and the
+ auditor's "ingress" database must use transport security.
@@ -114,7 +129,18 @@ Drawbacks
the order in which new entries are to be copied. It may also
be that simply running "big" transactions across all tables
is the answer, to be investigated what performs better.
+* A malicious exchange could theoretically send expensive transactions
+ to the auditor via the replication mechanism (possibly ones that
+ it did not even execute locally itself) to DoS the "ingres"
+ database. This would be noticed primarily by load
+ monitoring or even the auditor lagging unusually far behind the
+ exchange's transaction history. We believe this is acceptable,
+ as it would imply highly visible malicious exchange behavior for
+ virtually no significant gain.
+* The proposed solution does not create a transactional, synchronous
+ write-only log as suggested by CodeBlau (see audit report, Section 9.4).
+ We believe doing so would be overly costly, both in terms of
+ complexity and performance, for limited gains.
Discussion / Q&A
To stop receiving notification emails like this one, please contact
|[Prev in Thread]
||[Next in Thread]|
- [taler-docs] branch master updated: clarifications based on discussion with Florian,