diff options
| -rw-r--r-- | issues/add-read-only-mode.md | 14 | ||||
| -rw-r--r-- | issues/ed25519-clamping-behavior.md | 19 | ||||
| -rw-r--r-- | issues/error-handling.md | 2 | ||||
| -rw-r--r-- | issues/http-status-405.md | 19 | ||||
| -rw-r--r-- | issues/server-configuration.md | 19 |
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. |