From db6ad1e00ea255fdae9306ab3133debcbd4d1732 Mon Sep 17 00:00:00 2001 From: Rasmus Dahlberg Date: Sun, 27 Mar 2022 22:48:48 +0200 Subject: update source of www.sigsum.org New template, font, colors, and logo. A few edits to text, chunking it up under a few different pages that can be navigated. --- hugo/content/_index.md | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) mode change 120000 => 100644 hugo/content/_index.md (limited to 'hugo/content/_index.md') diff --git a/hugo/content/_index.md b/hugo/content/_index.md deleted file mode 120000 index fe84005..0000000 --- a/hugo/content/_index.md +++ /dev/null @@ -1 +0,0 @@ -../../README.md \ No newline at end of file diff --git a/hugo/content/_index.md b/hugo/content/_index.md new file mode 100644 index 0000000..24879e2 --- /dev/null +++ b/hugo/content/_index.md @@ -0,0 +1,25 @@ +Sigsum logging brings transparency to signed checksums. This makes it possible +to detect malicious and unintended key-usage. In other words, no signature +accepted by an end-user goes unnoticed. + +> A new signature made with my key was just logged. +> Was that signature expected? + +Specific use-cases can be implemented on-top of the minimal building block that +Sigsum provides. Examples include transparency for executable binaries, TPM +quotes, and onion address rulesets. + +> Everyone gets the same binaries. +> Signed binary checksums become public in Sigsum logs. +> Each binary is locatable on a separate release page. +> An independent monitor can verify these claims. + +Sigsum is designed to be secure against a powerful attacker that controls: + + - The signer's secret key and infrastructure + - The log's secret key and infrastructure + - A threshold of so-called witnesses that cosign the log + +Any use-case that cannot tolerate a few minutes of logging latency is out of +scope. This and other aspects keep the Sigsum design simple, both with regards +to operations and end-user verification. -- cgit v1.2.3