aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-09-27 22:06:31 +0200
committerRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-09-27 22:06:31 +0200
commit0b0320d8f295394e2afc5f0cf012422e8625518b (patch)
treea32512c8d9ce63aa3b9fd92f58468c9e7a8edbb1
parent3981cdc68052c5084c28ade768b635d24242aa6d (diff)
imported issues
-rw-r--r--issues/add-read-only-mode.md14
-rw-r--r--issues/ed25519-clamping-behavior.md19
-rw-r--r--issues/error-handling.md2
-rw-r--r--issues/http-status-405.md19
-rw-r--r--issues/server-configuration.md19
5 files changed, 73 insertions, 0 deletions
diff --git a/issues/add-read-only-mode.md b/issues/add-read-only-mode.md
new file mode 100644
index 0000000..d87c244
--- /dev/null
+++ b/issues/add-read-only-mode.md
@@ -0,0 +1,14 @@
+# Add read-only mode
+Reported by: rgdd
+
+The process of shutting down a log will likely consist of at least two steps:
+1. Stop accepting new logging requests. Serve the final (co)signed tree heads
+for a while.
+2. Take the log offline.
+
+The first step requires some form of read-only mode. For example:
+- Disable all write endpoints (`add-leaf` and `add-cosignature`)
+- Implement a `StateManager` that serves fixed (co)signed tree heads.
+
+For inspiration we could look at certificate transparency:
+- https://github.com/google/certificate-transparency-go/tree/master/trillian/ctfe
diff --git a/issues/ed25519-clamping-behavior.md b/issues/ed25519-clamping-behavior.md
new file mode 100644
index 0000000..6e8fed7
--- /dev/null
+++ b/issues/ed25519-clamping-behavior.md
@@ -0,0 +1,19 @@
+# Ed25519 clamping behavior
+Reported by: rgdd
+
+If I recall correctly an Ed25519 signature has 3 bits that should always be
+zero. What happens if any of the 3 bits are not zero during signature
+verification? It probably depends on the implementation. I would expect that the
+signature is rejected. However, a possible behavior that I would not expect is
+that the three bits are zeroed ("fixed").
+
+We need the signature to be rejected; not fixed. Otherwise it is possible to
+replay a logged entry several times by enumerating the remaining bit patterns.
+Replays are bad for the log (overhead). Replays are also bad for the legitimate
+submitter because it will eat into their rate limit (DoS vector).
+
+It would be great if anyone could:
+- Confirm if I recall correctly. And if so, confirm if the behavior of
+`crypto/ed25519` is to reject signatures if any of the three bits are set.
+- After a quick look this might be the place to understand:
+https://cs.opensource.google/go/go/+/refs/tags/go1.16.4:src/crypto/ed25519/ed25519.go;l=208
diff --git a/issues/error-handling.md b/issues/error-handling.md
index afd04be..20eb97c 100644
--- a/issues/error-handling.md
+++ b/issues/error-handling.md
@@ -1,4 +1,6 @@
# Error handling
+Reported by: rgdd
+
- Some error messages are probably too verbose. We should take a pass over this
and ensure that they are masked appropriately. A production mode would be nice.
- For some reason our current error messages have one too many new lines. In
diff --git a/issues/http-status-405.md b/issues/http-status-405.md
new file mode 100644
index 0000000..3278f42
--- /dev/null
+++ b/issues/http-status-405.md
@@ -0,0 +1,19 @@
+# HTTP status 405, no Allow header
+Reported by: ln5
+
+When using HTTP GET for a POST endpoint or vice versa, HTTP status code 405 is
+returned by the server. According to RFC2616 an Allow header MUST be included in
+the response.
+
+```
+10.4.6 405 Method Not Allowed
+
+The method specified in the Request-Line is not allowed for the resource
+identified by the Request-URI. The response MUST include an Allow header
+containing a list of valid methods for the requested resource.
+```
+
+Find relevant places to start looking:
+```
+$ git grep StatusMethodNotAllowed
+```
diff --git a/issues/server-configuration.md b/issues/server-configuration.md
new file mode 100644
index 0000000..22fbf9a
--- /dev/null
+++ b/issues/server-configuration.md
@@ -0,0 +1,19 @@
+# Server configuration
+Reported by: ln5
+
+All server configuration is done via command-line arguments.
+
+This is good for configuration settings which last through the lifetime of an
+invocation of a log instance, i.e., from launch to Ctrl-C. Examples:
+- `--http_endpoint`
+- `--key`.
+
+It is less good for settings that change over time. Examples:
+- `--witnesses`
+
+Reading a configuration file at start and when receiving, say, SIGHUP, is an
+alternative.
+
+Implementing a "control port", typically a TCP endpoint, where an administrator
+can "program" the log instance is another alternative. Such an interface can
+also be used for diagnostics.