[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-exchange] 83/152: expand justifications / agree with append-only
From: |
gnunet |
Subject: |
[taler-exchange] 83/152: expand justifications / agree with append-only log |
Date: |
Sun, 05 Jul 2020 20:47:19 +0200 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository exchange.
commit c43922a58d561eae8af23048336bdf56efddea9d
Author: Florian Dold <florian.dold@gmail.com>
AuthorDate: Wed Jul 1 21:27:27 2020 +0530
expand justifications / agree with append-only log
---
doc/audit/response-202005.tex | 38 ++++++++++++++++++++++++++------------
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/doc/audit/response-202005.tex b/doc/audit/response-202005.tex
index 922680ea..a32a5855 100644
--- a/doc/audit/response-202005.tex
+++ b/doc/audit/response-202005.tex
@@ -57,12 +57,17 @@ they have all been addressed.
\section{General remarks on the code}
We understand that writing the code in another programming language may make
-certain checks for the auditor less work. However, other programming languages
-also have disadvantages (from the complexity of the languages to the
-complexity of the compilers to tool support). We believe creating a parallel
-implementation in other languages would provide advantages, especially with
-respect to avoiding ``the implementation is the specification''-style issues.
-However, given limited resources will not make this a priority.
+certain checks for the auditor less work to implement. However, our choice of C
+is based on the advantages that make it superior to contemporary languages for
+our use case: relatively low complexity of the language (compared to C++);
+availability of mature compilers, static and dynamic analysis tools;
+predictable performance; access to stable and battle-tested libraries; and
+future-proofness due to portability to older systems as well as new platforms.
+
+We believe creating a parallel implementation in other languages would provide
+advantages, especially with respect to avoiding ``the implementation is the
+specification''-style issues. However, given limited resources will not make
+this a priority.
We disagree that all modern software development has embraced the idea that
memory errors are to be handled in ways other than terminating or restarting
@@ -214,11 +219,20 @@ exchange for production.
\subsection{Reduce reliance on PostgreSQL}
-Using other mechanisms beyond the database as a ``Plan B'' would create
-serious availability and cost concerns, as now either mechanism may create
-serialization issues and require database rollbacks. Also, any such
-append-only logging mechanism would itself have a similar complexity as the
-primary database. Thus, we do not believe that the drastic complexity
-increase from the combined solution represents a valid security trade-off.
+CodeBlau's suggestion to use an append-only transaction logging service in
+addition to the PostgreSQL database is a reasonable suggestion for a
+production-grade deployment of GNU Taler, as it would allow partial disaster
+recovery even in the presence of an attacker that has gained write access to
+the exchange's database.
+
+We are currently still investigating whether the transaction logging should be
+implemented directly by the exchange service, or via the database's extensible
+replication mechanism. Any implementation of such an append-only logging
+mechanism must be carefully designed to ensure it does not negatively impact
+the exchange's availability and does not interfere with serializability of
+database transactions. As such we believe that transaction logging can only be
+provided on a best-effort basis. Fortunately, even a best-effort append-only
+transaction log would serve to limit the financial damage incurred by the
+exchange in an active database compromise scenario.
\end{document}
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [taler-exchange] 116/152: update, (continued)
- [taler-exchange] 116/152: update, gnunet, 2020/07/05
- [taler-exchange] 121/152: update ECs, gnunet, 2020/07/05
- [taler-exchange] 120/152: more ECs, gnunet, 2020/07/05
- [taler-exchange] 124/152: fixed endianness in taler_sq_lib, gnunet, 2020/07/05
- [taler-exchange] 125/152: taler_error_codes.h auto generated from gnunet/gana.git as a submodule, gnunet, 2020/07/05
- [taler-exchange] 113/152: modify TALER_EXCHANGE_deposits_get() API to combine returned arguments into a struct (simplifies merchant later), gnunet, 2020/07/05
- [taler-exchange] 112/152: return fee as well, gnunet, 2020/07/05
- [taler-exchange] 64/152: update gana, gnunet, 2020/07/05
- [taler-exchange] 77/152: synchronize with latest GANA, gnunet, 2020/07/05
- [taler-exchange] 80/152: bump required version, gnunet, 2020/07/05
- [taler-exchange] 83/152: expand justifications / agree with append-only log,
gnunet <=
- [taler-exchange] 82/152: minor typo, gnunet, 2020/07/05
- [taler-exchange] 84/152: fix typo, gnunet, 2020/07/05
- [taler-exchange] 87/152: v8 bump, gnunet, 2020/07/05
- [taler-exchange] 89/152: ign, gnunet, 2020/07/05
- [taler-exchange] 94/152: modify TALER_EXCHANGE_deposits_get() API to combine returned arguments into a struct (simplifies merchant later), gnunet, 2020/07/05
- [taler-exchange] 99/152: sleep to ensure aggregator has work, gnunet, 2020/07/05
- [taler-exchange] 96/152: combine sections, gnunet, 2020/07/05
- [taler-exchange] 88/152: fix status code, gnunet, 2020/07/05
- [taler-exchange] 102/152: modify TALER_EXCHANGE_deposits_get() API to combine returned arguments into a struct (simplifies merchant later), gnunet, 2020/07/05
- [taler-exchange] 107/152: fix status code, gnunet, 2020/07/05