aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGeorg Koppen <gk@torproject.org>2021-06-11 09:50:59 +0000
committerRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-06-11 13:15:31 +0200
commitade8b8dacbeab225362a93f94fbc56e6c687bc0f (patch)
tree327444dda5d34cb6f3c7d884f958903913928a1f
parent66ebb55c6b281a8529445bc6c71eae6960acd903 (diff)
Add website use-case, too, to README.md
-rw-r--r--README.md22
1 files changed, 12 insertions, 10 deletions
diff --git a/README.md b/README.md
index 7d4d6e2..81db277 100644
--- a/README.md
+++ b/README.md
@@ -10,19 +10,21 @@ We abbreviate Signature Transparency Logging as _siglog_.
## How it works
Suppose that you develop software and publish binaries. You sign those binaries
-and make them available to users in a package repository. You are committed to
-distribute the same signed binaries to every user. That is an easy claim to
-make. However, word is cheap and sometimes things go wrong. How would you even
-know if your signing infrastructure got compromised? A few select users might
-already receive maliciously signed binaries that include a backdoor. This is
-where siglog can help by adding transparency in the future.
+and make them available to users in a package repository and on your website.
+You are committed to distribute the same signed binaries to every user. That is
+an easy claim to make. However, word is cheap and sometimes things go wrong.
+How would you even know if your signing infrastructure got compromised? A few
+select users might already receive maliciously signed binaries that include a
+backdoor. This is where siglog can help by adding transparency in the future.
For each binary you can log a signed checksum that corresponds to that binary.
If a signed checksum appears in the log that you did not expect: excellent, now
-you know that your signing infrastructure was compromised at some point. Anyone
-can also detect if a logged checksum is unaccounted for in your package
-repository by inspecting the log. In other words, the claim that the same
-binaries are published for everyone can be _verified_.
+you know that your signing infrastructure was compromised at some point. The
+same goes for binaries that show up for download on your website but don't have
+a corresponding log entry. Anyone can also detect if a logged checksum is
+unaccounted for in your package repository or a binary on your website is
+missing a corresponing log entry just by inspecting the log. In other words,
+the claim that the same binaries are published for everyone can be _verified_.
Adding signed checksums into a log is already an improvement without any
end-user enforcement. Honest mistakes can be detected. However, end-users need