taler/exchange
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

expand justifications / agree with append-only log

Browse Source
This commit is contained in:
Florian Dold 2020-07-01 21:27:27 +05:30 committed by Christian Grothoff
parent ee94ca0e22
commit 7ddd2dba25
No known key found for this signature in database
GPG Key ID: 939E6BE1E29FC3CC
1 changed files with 26 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
doc/audit/response-202005.tex
View File

@ -57,12 +57,17 @@ they have all been addressed.
\section{General remarks on the code} \section{General remarks on the code}
We understand that writing the code in another programming language may make We understand that writing the code in another programming language may make
certain checks for the auditor less work. However, other programming languages certain checks for the auditor less work to implement. However, our choice of C
also have disadvantages (from the complexity of the languages to the is based on the advantages that make it superior to contemporary languages for
complexity of the compilers to tool support). We believe creating a parallel our use case: relatively low complexity of the language (compared to C++);
implementation in other languages would provide advantages, especially with availability of mature compilers, static and dynamic analysis tools;
respect to avoiding ``the implementation is the specification''-style issues. predictable performance; access to stable and battle-tested libraries; and
However, given limited resources will not make this a priority. 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 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 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} \subsection{Reduce reliance on PostgreSQL}
Using other mechanisms beyond the database as a ``Plan B'' would create CodeBlau's suggestion to use an append-only transaction logging service in
serious availability and cost concerns, as now either mechanism may create addition to the PostgreSQL database is a reasonable suggestion for a
serialization issues and require database rollbacks. Also, any such production-grade deployment of GNU Taler, as it would allow partial disaster
append-only logging mechanism would itself have a similar complexity as the recovery even in the presence of an attacker that has gained write access to
primary database. Thus, we do not believe that the drastic complexity the exchange's database.
increase from the combined solution represents a valid security trade-off.
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} \end{document}