Hi
Your file format document is a great document:
https://git.glasklar.is/sigsum/core/sigsum-go/-/blob/main/doc/sigsum-proof.m...
I have some ideas for how to improve it; I may have mentioned these before but would like to summarize the ideas and ask for your feedback:
1) Suggest a filename extension
It seems some people use *.proof although *.sigsum-proof may be more advertizy. Or just *.sigsum?
2) Suggest a filename naming convention
It should also suggest that the common way to name a Sigsum proof file is to name it after the file it contains a proof for, and include an example like:
hello-2.1.3.tar.gz hello-2.1.3.tar.gz.proof
3) Specify a MIME media subtype. I suggest "text/sigsum-proof".
4) To be a clear MIME media subtype specification it should discuss character set encoding concerns. The document already refer to ASCII and I suggest making this even more explicit: Sigsum proof files MUST be 7-bit clear ASCII files and MUST NOT contain any byte with the high bit set.
5) Add a ABNF grammar describing the format.
6) Discuss how to handle non-compliant data. For example is a "#" comment line allowed? Is adding/removing whitespace allowed? CRLF vs CR vs LF vs NUL etc delimiters? Behaviour if the format doesn't comply with the grammar? "Applications MUST generate compliant data and MUST be able to parse compliant data, and SHOULD NOT use non-compliant data. A valid reasing for accepting non-compliant data is if the applications for some reason is unable to implement a strict parser."
7) Putting the text into an IETF draft would be useful, as a reference for the MIME media subtype registration and a file format reference. I'm sure you know the process, but I'm happy to put this together and submit it if you want.
8) Versioning... the following document makes me a little nervous that the file format is still in flux which is detrimental for deployment:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/proposals/2...
It may be useful to discuss if all file format versions are using the same filename extension, convention, MIME media sub-type, and if so any discussion how entities should behave when parsing and generating files. I think there are two options: 1) Pretend version 1 never existed and just remove all support for it. 2) Document that applications MUST generate version 2 format, and applications MUST handle both formats and MUST discard the short 'leaf' checksum.
/Simon
Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
- Suggest a filename extension
It seems some people use *.proof although *.sigsum-proof may be more advertizy. Or just *.sigsum?
Naming is somewhat hard... On one hand, I like the very explicit .sigsum-proof, but it would also be nice with something shorter.
- Suggest a filename naming convention
It should also suggest that the common way to name a Sigsum proof file is to name it after the file it contains a proof for, and include an example like:
hello-2.1.3.tar.gz hello-2.1.3.tar.gz.proof
Sounds reasonable as an example, but not sure it needs a stronger recommendation than that. And behavior of the sigsum-submit tool should be consistent with whatever convention is documented.
Also keep in mind that a proof could refer to other kinds of objects than named files, so this is a "special case", although a very common case.
Specify a MIME media subtype. I suggest "text/sigsum-proof".
To be a clear MIME media subtype specification it should discuss
character set encoding concerns. The document already refer to ASCII and I suggest making this even more explicit: Sigsum proof files MUST be 7-bit clear ASCII files and MUST NOT contain any byte with the high bit set.
Makes sense. To be explicit, does this mean that you suggest MIME type "text/sigsum-proof; charset=ascii" ?
- Add a ABNF grammar describing the format.
What concrete utility do you see? If we adopt ABNF, we should consider adding that also to https://git.glasklar.is/sigsum/project/documentation/-/blob/main/log.md.
- Discuss how to handle non-compliant data. For example is a "#"
comment line allowed? Is adding/removing whitespace allowed? CRLF vs CR vs LF vs NUL etc delimiters?
Besides possibly being more liberal regarding line end convention (see below), I see no reason to allow white space variations or comments, do you?
The intention of current spec and implementation is to require a single newline character (0xa) terminating each line. Changing that would be another change to the format.
But for a text/* content type, I would expect the local line end convention to be accepted, which in a networked setting means one would have to accept all line end variants. Which might be an argument against using a text/* type? But I don't know the fine details of the text/* expectations.
- Putting the text into an IETF draft would be useful, as a reference
for the MIME media subtype registration and a file format reference. I'm sure you know the process, but I'm happy to put this together and submit it if you want.
To me, an internet draft makes sense if and only if we intend to publish it as an (informational) RFC. Internet drafts are, by definition, not great references.
- Versioning... the following document makes me a little nervous that
the file format is still in flux which is detrimental for deployment:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/proposals/2...
Given the very preliminary deployment of version 1, I would like to think about that as optional for implementations, and that coming deployment should mandate version 2. I would expect sigsum to stick to version 2 until some "spicy signature" that is not specific to sigsum logs emerges (but we should not define MIME types in such a way that we completely rule out a hypothetical sigsum proof version 3).
So I think MIME registration or other standards action should ignore version 1, or document it as a historic variation. While our tools and libraries will support reading version 1 for as long as needed.
It may be useful to discuss if all file format versions are using the same filename extension, convention, MIME media sub-type, and if so any discussion how entities should behave when parsing and generating files. I think there are two options: 1) Pretend version 1 never existed and just remove all support for it. 2) Document that applications MUST generate version 2 format, and applications MUST handle both formats and MUST discard the short 'leaf' checksum.
How is this handled for other formats for which there are variations, e.g., multiple versions, or optional features? Are those reflected in the MIME type (or extension), or is it enough that the MIME type tells an implementation unambiguously how to extract information about version and features from the content data? Off the top of my head, having variation reflected in the MIME type would mainly be useful for content type negotiation like the Accept: header (which as far as I'm aware is rare in practice, and not obviously useful for the case of sigsum proofs).
Regards, /Niels
Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
- Suggest a filename extension
It seems some people use *.proof although *.sigsum-proof may be more advertizy. Or just *.sigsum?
Naming is somewhat hard... On one hand, I like the very explicit .sigsum-proof, but it would also be nice with something shorter.
Maybe canonical name *.sigsum-proof and a short form like *.ssp (SigSum Proof), *.prf (sigsum PRooF), *.spf (Sigsum ProoF), *.sps (Sigsum Proof Signature), *.sis (SIgsum Signature), *.ssi (Sigsum SIgnature), ...?
I think a three character extension would be nice. I'm currently considering doing some software release announcements with sigsum proofs for the artifacts, and the verification instructions and filename extension/convention are the primary unclear parts now.
- Suggest a filename naming convention
It should also suggest that the common way to name a Sigsum proof file is to name it after the file it contains a proof for, and include an example like:
hello-2.1.3.tar.gz hello-2.1.3.tar.gz.proof
Sounds reasonable as an example, but not sure it needs a stronger recommendation than that. And behavior of the sigsum-submit tool should be consistent with whatever convention is documented.
Also keep in mind that a proof could refer to other kinds of objects than named files, so this is a "special case", although a very common case.
Yes I am mostly looking for a style guide rather than any exclusionary requirement here. What I would dislike is if any of these starts to be common:
hello-2.1.3.tar.gz-proof hello-2.1.3.tar.gz-sigsum sigsum-hello-2.1.3.tar.gz hello-2.1.3-sigsum.tar.gz
I realize now that the sigsum-submit --help is already fairly clear:
If input files are provided on the command line, each file corresponds to one request, and result is written to a corresponding output file, based on these rules:
1. If there's exactly one input file, and the -o option is used, output is written to that file. Any existing file is overwritten.
2. For a request output, the suffix ".req" is added to the input file name.
3. For a proof output, if the input is a request, any ".req" suffix on the input file name is stripped. Then the suffix ".proof" is added.
4. If the --output-dir option is provided, any directory part of the input file name is stripped, and the output is written as a file in the specified output directory.
If a corresponding .proof file already exists, that proof is read and verified. If the proof is valid, the input file is skipped. If the proof is not valid, sigsum-submit exits with an error.
If a corresponding .req output file already exists, it is overwritten (TODO: Figure out if that is the proper behavior).
Specify a MIME media subtype. I suggest "text/sigsum-proof".
To be a clear MIME media subtype specification it should discuss
character set encoding concerns. The document already refer to ASCII and I suggest making this even more explicit: Sigsum proof files MUST be 7-bit clear ASCII files and MUST NOT contain any byte with the high bit set.
Makes sense. To be explicit, does this mean that you suggest MIME type "text/sigsum-proof; charset=ascii" ?
I think the MIME world is quite complex so it is hard to answer. My point is that there should be a MIME type like 'text/sigsum-proof' that has a well-defined (preferably ASCII-based) syntax associated with it.
Reading https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1 and https://datatracker.ietf.org/doc/html/rfc6657 makes me prefer to say that the charset parameter is not used because the format is ASCII.
- Add a ABNF grammar describing the format.
What concrete utility do you see? If we adopt ABNF, we should consider adding that also to https://git.glasklar.is/sigsum/project/documentation/-/blob/main/log.md.
My primary utility of doing that is to lock down the format so we won't have ten slightly different variants of it. And alignment with the MIME/IETF registration process.
- Discuss how to handle non-compliant data. For example is a "#"
comment line allowed? Is adding/removing whitespace allowed? CRLF vs CR vs LF vs NUL etc delimiters?
Besides possibly being more liberal regarding line end convention (see below), I see no reason to allow white space variations or comments, do you?
No. I was playing devils advocate.
The intention of current spec and implementation is to require a single newline character (0xa) terminating each line. Changing that would be another change to the format.
But for a text/* content type, I would expect the local line end convention to be accepted, which in a networked setting means one would have to accept all line end variants. Which might be an argument against using a text/* type? But I don't know the fine details of the text/* expectations.
https://datatracker.ietf.org/doc/html/rfc2046#section-4.1.1 says
The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence.
Apparently this doesn't prevent using text/plain on LF-delimited files, and that seems better than using application/sigsum-proof for what is essentially text anyway.
- Putting the text into an IETF draft would be useful, as a reference
for the MIME media subtype registration and a file format reference. I'm sure you know the process, but I'm happy to put this together and submit it if you want.
To me, an internet draft makes sense if and only if we intend to publish it as an (informational) RFC. Internet drafts are, by definition, not great references.
An Informational RFC would be nice, although strictly not required. Instead you could prepare a *.md file specifying things and then fill out this form:
https://www.iana.org/form/media-types
- Versioning... the following document makes me a little nervous that
the file format is still in flux which is detrimental for deployment:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/proposals/2...
Given the very preliminary deployment of version 1, I would like to think about that as optional for implementations, and that coming deployment should mandate version 2. I would expect sigsum to stick to version 2 until some "spicy signature" that is not specific to sigsum logs emerges (but we should not define MIME types in such a way that we completely rule out a hypothetical sigsum proof version 3).
So I think MIME registration or other standards action should ignore version 1, or document it as a historic variation. While our tools and libraries will support reading version 1 for as long as needed.
Okay - having versioning in the format specification is fine, it could simply say that anything except 'version=2' is undefined behaviour.
It may be useful to discuss if all file format versions are using the same filename extension, convention, MIME media sub-type, and if so any discussion how entities should behave when parsing and generating files. I think there are two options: 1) Pretend version 1 never existed and just remove all support for it. 2) Document that applications MUST generate version 2 format, and applications MUST handle both formats and MUST discard the short 'leaf' checksum.
How is this handled for other formats for which there are variations, e.g., multiple versions, or optional features? Are those reflected in the MIME type (or extension), or is it enough that the MIME type tells an implementation unambiguously how to extract information about version and features from the content data? Off the top of my head, having variation reflected in the MIME type would mainly be useful for content type negotiation like the Accept: header (which as far as I'm aware is rare in practice, and not obviously useful for the case of sigsum proofs).
I believe most formats specify one MIME type once and then do version rolling inside the format specifications. Introducing new MIME types for each new format version is more fragile, and usually doesn't give any advantages.
/Simon
On Tue, Jan 07, 2025 at 02:51:16PM +0100, Sigsum General wrote:
Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
- Suggest a filename extension
It seems some people use *.proof although *.sigsum-proof may be more advertizy. Or just *.sigsum?
I liked this initial *.sigsum suggestion, mainly because it makes it pretty obvious when looking at a filename that it's a "Sigsum thing".
Naming is somewhat hard... On one hand, I like the very explicit .sigsum-proof, but it would also be nice with something shorter.
Maybe canonical name *.sigsum-proof and a short form like *.ssp (SigSum Proof), *.prf (sigsum PRooF), *.spf (Sigsum ProoF), *.sps (Sigsum Proof Signature), *.sis (SIgsum Signature), *.ssi (Sigsum SIgnature), ...?
Here my preference would be the "Sigsum signature" variations, because I think it is easier for lay users to think of this as a "signature". It just happens to be a transparent signature, which is great!
I think a three character extension would be nice. I'm currently considering doing some software release announcements with sigsum proofs for the artifacts, and the verification instructions and filename extension/convention are the primary unclear parts now.
Nice -- what's you're timeline to not be blocked?
-Rasmus
Rasmus Dahlberg rgdd@glasklarteknik.se writes:
I think a three character extension would be nice. I'm currently considering doing some software release announcements with sigsum proofs for the artifacts, and the verification instructions and filename extension/convention are the primary unclear parts now.
Nice -- what's you're timeline to not be blocked?
What would you recommend to write in a release announcement when including Sigsum proofs for release artifacts?
Below is a template announcement for some imaginary software, where I added text about Sigsum. I appreciate everyone's word smithing of the Sigsum-related content. Bonus points if you manage to shorten the text rather than adding text.
These aren't the most user friendly instructions that I've encountered, so please separately consider what you can do to improve tooling to allow more user friendly commands to verify a proof.
Btw, I plan to use my OpenPGP authentication key (i.e., not the signature key) from my Gnuk hardware dongle, exported via GnuPG's SSH agent, for use by sigsum-submit --signing-key to create *.proof. Does anyone see a problem with this? I don't know how to make my OpenPGP signature key from the Gnuk available via the SSH agent easily, has anyone done that? I haven't thought through the flow here. The threat I'm worried about is if some remote SSH server abuse my setup to make me sign some blob that may later be submitted to the Sigsum transparency log as a release signature? Is there sufficient domain context separation happening here? It doesn't feel intuitively safe.
/Simon
... Here is the GNU inetutils home page: https://gnu.org/s/inetutils/
Here are the compressed sources: https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.gz (2.9MB) https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.xz (1.7MB)
Here are the GPG detached signatures: https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.gz.sig https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.xz.sig
Here is minimal source-only "git archive" sources: https://ftpmirror.gnu.org/inetutils/inetutils-v2.6-src.tar.gz (820kB)
Here are Sigsum Proofs: https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.gz.proof https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.xz.proof https://ftpmirror.gnu.org/inetutils/inetutils-v2.6-src.tar.gz.proof
Use a mirror for higher download bandwidth: https://www.gnu.org/order/ftp.html
Here are the SHA1 and SHA256 checksums:
ced45165aeda8a9584d291b81225d86be82e1a90 inetutils-2.6.tar.gz gra2UqTds+E0rwII1iW38faAJn3igu5Wau60BvaI+HI= inetutils-2.6.tar.gz a6576bacd408adf93017f44d35608f05c893c5d5 inetutils-2.6.tar.xz YuriPIWQhNnJci9Nu+NnddrLnPDbwVXaQ3AEnkl2OCM= inetutils-2.6.tar.xz
Verify the base64 SHA256 checksum with cksum -a sha256 --check from coreutils-9.2 or OpenBSD's cksum since 2007.
Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this:
gpg --verify inetutils-2.6.tar.gz.sig
The signature should match the fingerprint of the following key:
pub ed25519 2019-03-20 [SC] B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE uid Simon Josefsson simon@josefsson.org
If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command.
gpg --locate-external-key simon@josefsson.org
gpg --recv-keys 51722B08FE4745A2
wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=inetutils&dow...' | gpg --import -
As a last resort to find the key, you can try the official GNU keyring:
wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg gpg --keyring gnu-keyring.gpg --verify inetutils-2.6.tar.gz.sig
Use the .proof file to verify the Sigsum proof. These files are like signatures with extra transparency: you can cryptographically verify that every proof is logged in a public append-only log, so you can say with confidence what signatures exists. This helps to protect against secret (targetted and/or malicious) releases.
Our releases are Sigsum signed with the following public key:
cat <<EOF > inetutils-sigsum-key.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE EOF
You may use the following Sigsum verification policy:
cat <<EOF > inetutils-sigsum-trust-policy.txt log 154f49976b59ff09a123675f58cb3e346e0455753c3c3b15d465dcb4f6512b0b https://poc.sigsum.org/jellyfish witness poc.sigsum.org/nisse 1c25f8a44c635457e2e391d1efbca7d4c2951a0aef06225a881e46b98962ac6c witness rgdd.se/poc-witness 28c92a5a3a054d317c86fc2eeb6a7ab2054d6217100d0be67ded5b74323c5806 group demo-quorum-rule all poc.sigsum.org/nisse rgdd.se/poc-witness quorum demo-quorum-rule EOF
Run a command like this to verify downloaded artifacts:
sigsum-verify -k inetutils-sigsum-key.pub \ -p inetutils-sigsum-trust-policy.txt \ inetutils-2.6.tar.gz.proof < inetutils-2.6.tar.gz
You may learn more about Sigsum concepts and find instructions how to download the tools here: https://www.sigsum.org/getting-started/
This release is based on the inetutils git repository, available as
git clone https://git.savannah.gnu.org/git/inetutils.git
with commit 346d839db35faa4beb755edfa3b962c87005fcb5 tagged as v2.6.
For a summary of changes and contributors, see:
https://git.sv.gnu.org/gitweb/?p=inetutils.git;a=shortlog;h=v2.6
or run this command from a git-cloned inetutils directory:
git shortlog v2.5..v2.6
This release was bootstrapped with the following tools: Gnulib 2025-01-02 e7d6a9e033ff82d5bd7f001d6d1a17bd6cc9607c Autoconf 2.71 Automake 1.16.5 Bison 3.8.2 M4 1.4.19 Makeinfo 7.1.1 Help2man 1.49.2 Make 4.3 Gzip 1.13 Tar 1.34 Guix 831b94a1efcea8f793afc949b5123a6235c9bb1a
NEWS
* Noteworthy changes in release 2.6 (2025-01-07) [stable] ...
Simon Josefsson simon@josefsson.org writes:
Btw, I plan to use my OpenPGP authentication key (i.e., not the signature key) from my Gnuk hardware dongle, exported via GnuPG's SSH agent, for use by sigsum-submit --signing-key to create *.proof. Does anyone see a problem with this? I don't know how to make my OpenPGP signature key from the Gnuk available via the SSH agent easily, has anyone done that? I haven't thought through the flow here. The threat I'm worried about is if some remote SSH server abuse my setup to make me sign some blob that may later be submitted to the Sigsum transparency log as a release signature? Is there sufficient domain context separation happening here? It doesn't feel intuitively safe.
To answer domain separation: I think there's domain separation between sigsum leaf signatures and signatures involved in *proper* ssh public key user authentication. But the ssh-agent protocol lets the client sign arbitrary data, so if you expose the signing key via ssh-agent (and it sounds like you also do agent forwarding?) to an attacker, the attacker could sign and sigsum log anything on your behalf.
For that reason, it would be preferable to use separate keys for signing, and not expose that key via ssh-agent forwarding to remote machines.
The only good thing is that by monitoring the relevant sigsum logs, you can still discover such key misuse.
BTW, how do you get the auxilliary .proof files onto the GNU ftp servers? I've only used the ftp-upload machinery with triplets foo, foo.sig, foo.directive.asc, and additional signature-like files doesn't quite fit there? Do you upload an additional triplet foo.proof, foo.proof.sig, foo.proof.directive.asc, and then ignore (or delete) the foo.proof.sig file, or is there some easier way?
Regards, /Niels
Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
Simon Josefsson simon@josefsson.org writes:
Btw, I plan to use my OpenPGP authentication key (i.e., not the signature key) from my Gnuk hardware dongle, exported via GnuPG's SSH agent, for use by sigsum-submit --signing-key to create *.proof. Does anyone see a problem with this? I don't know how to make my OpenPGP signature key from the Gnuk available via the SSH agent easily, has anyone done that? I haven't thought through the flow here. The threat I'm worried about is if some remote SSH server abuse my setup to make me sign some blob that may later be submitted to the Sigsum transparency log as a release signature? Is there sufficient domain context separation happening here? It doesn't feel intuitively safe.
To answer domain separation: I think there's domain separation between sigsum leaf signatures and signatures involved in *proper* ssh public key user authentication. But the ssh-agent protocol lets the client sign arbitrary data, so if you expose the signing key via ssh-agent (and it sounds like you also do agent forwarding?) to an attacker, the attacker could sign and sigsum log anything on your behalf.
For that reason, it would be preferable to use separate keys for signing, and not expose that key via ssh-agent forwarding to remote machines.
The only good thing is that by monitoring the relevant sigsum logs, you can still discover such key misuse.
Ok great!
This makes me wonder a bit. How big is the benefit to use the same Sigsum private/public key for multiple continous releases?
Could I just generate a fresh key, sign, and then throw it away after posting the release announcement?
Should I do a Sigsum key rollover at the same frequency of PGP key rollover? Are there any recommendations about Sigsum key lifecycle management?
The only trustworthy way to discover the Sigsum public key used to sign my releases will be via PGP signed announcement e-mail. So the sigsum-related trust chains back to verifying a PGP e-mail. Sigsum can't really protect against someone stealing my PGP private key and fabricating hidden signed release announcements for a malicious version that is signed using a different Sigsum key, right? So I might as well use a different Sigsum private key for every release.
Maybe there is some low value in having "advanced" users be able to visually (or through 'cmp') compare the Sigsum public key fingerprint against a two year old release announcement to see if the same PGP key was used but the Sigsum key is different, to avoid being caught by the transparency log. I have a hard time imaging anyone going through that process regulary though.
I normally don't use the ssh-agent, and consider that threat as low, so I will probably use the SSH agent exported authentication key for my releases though.
BTW, how do you get the auxilliary .proof files onto the GNU ftp servers? I've only used the ftp-upload machinery with triplets foo, foo.sig, foo.directive.asc, and additional signature-like files doesn't quite fit there? Do you upload an additional triplet foo.proof, foo.proof.sig, foo.proof.directive.asc, and then ignore (or delete) the foo.proof.sig file, or is there some easier way?
I haven't tried this yet, but I'm hoping 'gnupload' will allow me to upload arbitrary files, or at least offer a way to remove any spurious *.proof.sig files.
/Simon
Regards, /Niels _______________________________________________ Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
Simon Josefsson simon@josefsson.org writes:
This makes me wonder a bit. How big is the benefit to use the same Sigsum private/public key for multiple continous releases?
Could I just generate a fresh key, sign, and then throw it away after posting the release announcement?
It's important that verifiers (users of the signed releases) and monitors agree on the sigsum public key. And monitors should keep an eye out for new signatures by that key more or less forever.
I imagine that would be easier to arrange with a long-lived key.
Should I do a Sigsum key rollover at the same frequency of PGP key rollover? Are there any recommendations about Sigsum key lifecycle management?
If practical, I think it would make sense to use the same key for PGP signing and for signing the corresponding Sigsum leaf. Both signatures express the same thing, i.e., that a certain blod is an authentic releaese. If you do that, users can skip PGP verification if they instead do sigsum verification.
The only trustworthy way to discover the Sigsum public key used to sign my releases will be via PGP signed announcement e-mail.
Bootstrapping is hard as usual. I guess most users (if they're not able to exhange keys with you in person or via some solid web of trust) will get pubkeys from some authentic-looking https web site, and hence depend on web-pki. (Some key-transparency machinery for release keys could be useful, but not so easy).
Regards, /Niels
On Tue, Jan 07, 2025 at 05:01:42PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg rgdd@glasklarteknik.se writes:
I think a three character extension would be nice. I'm currently considering doing some software release announcements with sigsum proofs for the artifacts, and the verification instructions and filename extension/convention are the primary unclear parts now.
Nice -- what's you're timeline to not be blocked?
What would you recommend to write in a release announcement when including Sigsum proofs for release artifacts?
Below is a template announcement for some imaginary software, where I added text about Sigsum. I appreciate everyone's word smithing of the Sigsum-related content. Bonus points if you manage to shorten the text rather than adding text.
These aren't the most user friendly instructions that I've encountered, so please separately consider what you can do to improve tooling to allow more user friendly commands to verify a proof.
What you have in the current template looks as good as it gets right now! What we discussed so far with Filippo to shrink it:
**Named trust policies.** So that you would only have to say here are my Sigsum key(s) and they should be used with "Debian's trust policy", "the builtin default policy", etc. A key-line might look like this:
sigsum_policy="builtin" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM1WpnEswJLPzvXJDiswowy48U+G+G1kmgwUE2eaRHZG
With the idea that it should be possible to specify either the default, or to override it by, e.g., using the policy an apt-package installed.
Or maybe saying nothing implies builtin, and there is a way to override it with the sigsum_policy option as shown above. This is all work in progress ideas that we have yet to hash out (but you might get the idea), so if you have any feedback or related ideas to explore shoot!
But basically, I'd like to not force the very long trust policy blurbs in everyones READMEs. And to have named trust policies to pick from.
**Better primer page for users.** So, basically something similar to www.so/getting-started; but targeted solely for users that want to use sigsum-verify rather than getting a full demo of the entire system.
We probably also want a primer page that can be linked for the type of verification Sigsum facilitates from a 3rd-party perspective; and we should probably have a separate page dedicated for release-signing. If we had that, you could probably get away with one sentence + link.
(I posted some more in-line comments further down in the template.)
Btw, I plan to use my OpenPGP authentication key (i.e., not the signature key) from my Gnuk hardware dongle, exported via GnuPG's SSH agent, for use by sigsum-submit --signing-key to create *.proof. Does anyone see a problem with this? I don't know how to make my OpenPGP signature key from the Gnuk available via the SSH agent easily, has anyone done that? I haven't thought through the flow here. The threat I'm worried about is if some remote SSH server abuse my setup to make me sign some blob that may later be submitted to the Sigsum transparency log as a release signature? Is there sufficient domain context separation happening here? It doesn't feel intuitively safe.
/Simon
... Here is the GNU inetutils home page: https://gnu.org/s/inetutils/
Here are the compressed sources: https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.gz (2.9MB) https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.xz (1.7MB)
Here are the GPG detached signatures: https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.gz.sig https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.xz.sig
Here is minimal source-only "git archive" sources: https://ftpmirror.gnu.org/inetutils/inetutils-v2.6-src.tar.gz (820kB)
Here are Sigsum Proofs: https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.gz.proof https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.xz.proof https://ftpmirror.gnu.org/inetutils/inetutils-v2.6-src.tar.gz.proof
Use a mirror for higher download bandwidth: https://www.gnu.org/order/ftp.html
Here are the SHA1 and SHA256 checksums:
ced45165aeda8a9584d291b81225d86be82e1a90 inetutils-2.6.tar.gz gra2UqTds+E0rwII1iW38faAJn3igu5Wau60BvaI+HI= inetutils-2.6.tar.gz a6576bacd408adf93017f44d35608f05c893c5d5 inetutils-2.6.tar.xz YuriPIWQhNnJci9Nu+NnddrLnPDbwVXaQ3AEnkl2OCM= inetutils-2.6.tar.xz
Verify the base64 SHA256 checksum with cksum -a sha256 --check from coreutils-9.2 or OpenBSD's cksum since 2007.
Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this:
gpg --verify inetutils-2.6.tar.gz.sig
The signature should match the fingerprint of the following key:
pub ed25519 2019-03-20 [SC] B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE uid Simon Josefsson simon@josefsson.org
If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command.
gpg --locate-external-key simon@josefsson.org
gpg --recv-keys 51722B08FE4745A2
wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=inetutils&dow...' | gpg --import -
As a last resort to find the key, you can try the official GNU keyring:
wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg gpg --keyring gnu-keyring.gpg --verify inetutils-2.6.tar.gz.sig
Use the .proof file to verify the Sigsum proof. These files are like signatures with extra transparency: you can cryptographically verify that every proof is logged in a public append-only log, so you can say with confidence what signatures exists. This helps to protect against secret (targetted and/or malicious) releases.
If you want some inspiration for why the above paragraph is true:
https://git.glasklar.is/rgdd/age-release-verify
I'd love to see a similar prototype for your use-case!
Our releases are Sigsum signed with the following public key:
cat <<EOF > inetutils-sigsum-key.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE EOF
You may use the following Sigsum verification policy:
cat <<EOF > inetutils-sigsum-trust-policy.txt log 154f49976b59ff09a123675f58cb3e346e0455753c3c3b15d465dcb4f6512b0b https://poc.sigsum.org/jellyfish
Jellyfish is a prototype log -- I'd recommend that you use seasalp, Glasklar's production log. See https://www.sigsum.org/services/.
witness poc.sigsum.org/nisse 1c25f8a44c635457e2e391d1efbca7d4c2951a0aef06225a881e46b98962ac6c witness rgdd.se/poc-witness 28c92a5a3a054d317c86fc2eeb6a7ab2054d6217100d0be67ded5b74323c5806
These test/prototype witnesses are not available for seasalp. Glasklar isn't running a stable witness yet (ln5 is working on fixing that the coming weeks; I'm also told a few other organizations are looking to start running witnesses). The witness cosignatures that you see on
https://seasalp.glasklar.is/get-tree-head
are all from Google TrustFabric's witness which runs from 15 different vantage points. I'd suggest using a majority policy (8/15 cosignatures). Such a policy for seasalp would look like this:
log 0ec7e16843119b120377a73913ac6acbc2d03d82432e2c36b841b09a95841f25 https://seasalp.glasklar.is
witness ArmoredWitness-falling-pond 54c4862caba4ef942fe1abc6afb65d63cba0a55d3e6313ff59154b8586d882e2 witness ArmoredWitness-weathered-rain 62db94aa7926e8b2ae0461e9ebf69cd2795c077eb1cfe63360f61d6fdbe1de52 witness ArmoredWitness-wispy-wood 456f659e0b0efa658e3a2895e2775a7c6754ae09d5842241bb603d649517068f witness ArmoredWitness-small-breeze 00166295237c618f42258e82deac2d66a9d0ff6b54e7be39fbb6b8d65b3b8143 witness ArmoredWitness-quiet-wood 9b71799be731b15fe9b54f37cd6f22f9499d3e3309dabcb588bf82e234844913 witness ArmoredWitness-morning-darkness 7ba003654674398b62dd70ab369a3f750a48670354d66f79125827514a0b9fbd witness ArmoredWitness-shy-wind 198bed2687bcf60fc246eae3583f2a9764287ece65aa1aa9f2b6b04a1628be1d witness ArmoredWitness-hidden-river dae934c7cc1f45ba898a3dfe1265d492a6c58405ddec143fc16f84a0f588e3a5 witness ArmoredWitness-autumn-wood eb085426da77b81b534ec99c0e987d90f4aa0e01d5cf31178212767b7dbe38a9 witness ArmoredWitness-snowy-sound 0b85b9d46ccbd1cfa78a19b04f8fc4359538390c9d82675e89d2433217aaad50 witness ArmoredWitness-throbbing-bird 98149a5d739b3baa777128f617531ce8b654d24502a7e151244cc5b7597667bc witness ArmoredWitness-rough-wind ea31934afb8632958de2fb37dd9bfabb8dc7961dea67a6ae4c57f1a1ca26eef7 witness ArmoredWitness-dry-sunset 03f38be7ab7f1081be393a9e69dd594d9a184a0eef36b0a1ab6f7a7f05beffc3 witness ArmoredWitness-nameless-firefly 075189980cc1388fa8686c7432028812de3182e257e219463f7cf28d49d573dd witness ArmoredWitness-floral-sky e90299398a4d39d030da888a0923ecf16786881ac12243db73c9f0cf2a2d80e6 group GoogleTrustFabric 8 ArmoredWitness-falling-pond ArmoredWitness-weathered-rain ArmoredWitness-wispy-wood ArmoredWitness-small-breeze ArmoredWitness-quiet-wood ArmoredWitness-morning-darkness ArmoredWitness-shy-wind ArmoredWitness-hidden-river ArmoredWitness-autumn-wood ArmoredWitness-snowy-sound ArmoredWitness-throbbing-bird ArmoredWitness-rough-wind ArmoredWitness-dry-sunset ArmoredWitness-nameless-firefly ArmoredWitness-floral-sky
quorum GoogleTrustFabric
This is not listed on www.sigsum.org yet. For the script I ran and did a bit of cut-and-paste from to extract the appropriate public keys, see:
https://www.rgdd.se/volatile/aw-config
-Rasmus
group demo-quorum-rule all poc.sigsum.org/nisse rgdd.se/poc-witness quorum demo-quorum-rule EOF
Run a command like this to verify downloaded artifacts:
sigsum-verify -k inetutils-sigsum-key.pub \ -p inetutils-sigsum-trust-policy.txt \ inetutils-2.6.tar.gz.proof < inetutils-2.6.tar.gz
You may learn more about Sigsum concepts and find instructions how to download the tools here: https://www.sigsum.org/getting-started/
This release is based on the inetutils git repository, available as
git clone https://git.savannah.gnu.org/git/inetutils.git
with commit 346d839db35faa4beb755edfa3b962c87005fcb5 tagged as v2.6.
For a summary of changes and contributors, see:
https://git.sv.gnu.org/gitweb/?p=inetutils.git;a=shortlog;h=v2.6
or run this command from a git-cloned inetutils directory:
git shortlog v2.5..v2.6
This release was bootstrapped with the following tools: Gnulib 2025-01-02 e7d6a9e033ff82d5bd7f001d6d1a17bd6cc9607c Autoconf 2.71 Automake 1.16.5 Bison 3.8.2 M4 1.4.19 Makeinfo 7.1.1 Help2man 1.49.2 Make 4.3 Gzip 1.13 Tar 1.34 Guix 831b94a1efcea8f793afc949b5123a6235c9bb1a
NEWS
- Noteworthy changes in release 2.6 (2025-01-07) [stable]
...
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
Use the .proof file to verify the Sigsum proof. These files are like signatures with extra transparency: you can cryptographically verify that every proof is logged in a public append-only log, so you can say with confidence what signatures exists. This helps to protect against secret (targetted and/or malicious) releases.
If you want some inspiration for why the above paragraph is true:
https://git.glasklar.is/rgdd/age-release-verify
I'd love to see a similar prototype for your use-case!
Neat!
Could that tool be extended to do the same for arbitrary release proofs, not only 'age'? Maybe call it be 'sigsum-release-verify'?
Could this functionality be built into 'sigsum-verify'?
Or could the functionality of 'sigsum-verify' be built into 'sigsum-release-verify'?
Having a small dedicated purpose tool similar to 'gpgv' but doing Sigsum signature verification against some trust policy and/or checking for hidden releases would be good for release announcement instructions.
It would be nice if users doesn't have to run two separate tools to do these checks, if they can be done quickly at the same time.
I suppose checking for hidden releases is an online operation?
Bonus points for a python or C client too :)
/Simon
On Tue, Jan 07, 2025 at 09:08:08PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
Use the .proof file to verify the Sigsum proof. These files are like signatures with extra transparency: you can cryptographically verify that every proof is logged in a public append-only log, so you can say with confidence what signatures exists. This helps to protect against secret (targetted and/or malicious) releases.
If you want some inspiration for why the above paragraph is true:
https://git.glasklar.is/rgdd/age-release-verify
I'd love to see a similar prototype for your use-case!
Neat!
Could that tool be extended to do the same for arbitrary release proofs, not only 'age'? Maybe call it be 'sigsum-release-verify'?
That's an interesting idea -- I think it would be extensible yes. The current prototype should already work for any GitHub release page, so I don't see why it wouldn't be possible to make this into a tool that knows how to fetch releases from various common APIs / release pages. And then it optionally hands over to a user-supplied script that does rebuilding (i.e., the actual rebuilding is not in scope of the tool).
Could this functionality be built into 'sigsum-verify'?
It could, yes. But it's a different type of verification (online and with linear overhead) so I think it probably deserves its own tool.
Or could the functionality of 'sigsum-verify' be built into 'sigsum-release-verify'?
That's actually what the prototype does right now -- it does sigsum-verify and checks (online) that there are no hidden releases.
Having a small dedicated purpose tool similar to 'gpgv' but doing Sigsum signature verification against some trust policy and/or checking for hidden releases would be good for release announcement instructions.
It would be nice if users doesn't have to run two separate tools to do these checks, if they can be done quickly at the same time.
As hinted on above, the problem is sigsum-release-verify would not be so efficient that it completes in reasonable time for every user that wants to install something. I think more of this as: I install something and ensure sigsum-verify is happy -> that means *someone else* that runs the more expensive sigsum-release-verify can tell if I'm being owned.
So it's detection after-the-fact rather than proactive prevention.
But I like the idea of still having something about how to run this verification in the release announcement, because that's what it's all about: *there's a claim, and it is possible to verify the claim*.
I suppose checking for hidden releases is an online operation?
Yes, correct!
Bonus points for a python or C client too :)
Hehe, I'm sure that will be available some day. Nothing that we're currently hacking on right now though, contributions welcome! :)
-Rasmus
Thanks for explaining! Sounds good. Could a tool like 'age-release-verify' be made independent of GitHub? For us who doesn't like to think too hard, could there be some documentation explaining exactly how the tool works? What requests are made to where, and how? How is it searching for hidden releases? Could all of the data be supplied on the command-line instead? Except, presumably, for the online Sigsum log queries that have no offline serialized artifact?
/Simon
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
On Tue, Jan 07, 2025 at 09:08:08PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
Use the .proof file to verify the Sigsum proof. These files are like signatures with extra transparency: you can cryptographically verify that every proof is logged in a public append-only log, so you can say with confidence what signatures exists. This helps to protect against secret (targetted and/or malicious) releases.
If you want some inspiration for why the above paragraph is true:
https://git.glasklar.is/rgdd/age-release-verify
I'd love to see a similar prototype for your use-case!
Neat!
Could that tool be extended to do the same for arbitrary release proofs, not only 'age'? Maybe call it be 'sigsum-release-verify'?
That's an interesting idea -- I think it would be extensible yes. The current prototype should already work for any GitHub release page, so I don't see why it wouldn't be possible to make this into a tool that knows how to fetch releases from various common APIs / release pages. And then it optionally hands over to a user-supplied script that does rebuilding (i.e., the actual rebuilding is not in scope of the tool).
Could this functionality be built into 'sigsum-verify'?
It could, yes. But it's a different type of verification (online and with linear overhead) so I think it probably deserves its own tool.
Or could the functionality of 'sigsum-verify' be built into 'sigsum-release-verify'?
That's actually what the prototype does right now -- it does sigsum-verify and checks (online) that there are no hidden releases.
Having a small dedicated purpose tool similar to 'gpgv' but doing Sigsum signature verification against some trust policy and/or checking for hidden releases would be good for release announcement instructions.
It would be nice if users doesn't have to run two separate tools to do these checks, if they can be done quickly at the same time.
As hinted on above, the problem is sigsum-release-verify would not be so efficient that it completes in reasonable time for every user that wants to install something. I think more of this as: I install something and ensure sigsum-verify is happy -> that means *someone else* that runs the more expensive sigsum-release-verify can tell if I'm being owned.
So it's detection after-the-fact rather than proactive prevention.
But I like the idea of still having something about how to run this verification in the release announcement, because that's what it's all about: *there's a claim, and it is possible to verify the claim*.
I suppose checking for hidden releases is an online operation?
Yes, correct!
Bonus points for a python or C client too :)
Hehe, I'm sure that will be available some day. Nothing that we're currently hacking on right now though, contributions welcome! :)
-Rasmus _______________________________________________ Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
What the tool does right now is basically this:
Locate all releases at: https://api.github.com/repos/FiloSottile/age/releases
The above API is documented here: https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28
Then what happens is that the tool downloads the respective release assets. In the case of age, some tarballs with binaries + .proofs.
Then the tool does sigsum-verify. So far nothing very exciting is happening, but it is now e.g. possible to notice if Filippo forgot to upload .proof files. Which he did, and which I noticed. Wink wink. :)
The tool is currently also shelling out for each asset, with the intent to rebuild the asset and ensure Filippo's binary is correct for the respective git tags. But that part is TODO, see this week's minutes:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/archive/202...
Okay, now the cool part. The tool downloads every entry from sigsum log(s), filtering on the keys Filippo use to create his .proof files. Finally, the tool computes the diff between what Filippo published on the release page and what checksums he signed and published in Sigsum. If there's something in the log that he didn't publish -> hidden release. Now you know, and you can conversate about it with filippo.
On Wed, Jan 08, 2025 at 02:09:21PM +0100, Sigsum General wrote:
Thanks for explaining! Sounds good. Could a tool like 'age-release-verify' be made independent of GitHub?
Yes, and I hope the above blurb helps describe how. Replace enumeration of GitHub's API with say GitLab's API, or even more plain listings like https://dist.system-transparency.org/st/. It doesn't matter where the data is downloaded from, as long as you know how to enumerate it.
For us who doesn't like to think too hard, could there be some documentation explaining exactly how the tool works? What requests are made to where, and how? How is it searching for hidden releases?
Yes -- I probably won't do it for the age-release-verify repository because it's a quick hacky prototype. But I'd like a more proper demo with such documentation, similar to www.sigsum.org/getting-started but focused on this particular use-case rather than just signed checksums.
Could all of the data be supplied on the command-line instead? Except, presumably, for the online Sigsum log queries that have no offline serialized artifact?
Yes, that's what I'm doing in this (slighly more documented) demo:
https://git.glasklar.is/rgdd/sshdt https://git.glasklar.is/rgdd/sshdt/-/blob/main/Makefile?ref_type=heads#L42
-Rasmus
/Simon
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
On Tue, Jan 07, 2025 at 09:08:08PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
Use the .proof file to verify the Sigsum proof. These files are like signatures with extra transparency: you can cryptographically verify that every proof is logged in a public append-only log, so you can say with confidence what signatures exists. This helps to protect against secret (targetted and/or malicious) releases.
If you want some inspiration for why the above paragraph is true:
https://git.glasklar.is/rgdd/age-release-verify
I'd love to see a similar prototype for your use-case!
Neat!
Could that tool be extended to do the same for arbitrary release proofs, not only 'age'? Maybe call it be 'sigsum-release-verify'?
That's an interesting idea -- I think it would be extensible yes. The current prototype should already work for any GitHub release page, so I don't see why it wouldn't be possible to make this into a tool that knows how to fetch releases from various common APIs / release pages. And then it optionally hands over to a user-supplied script that does rebuilding (i.e., the actual rebuilding is not in scope of the tool).
Could this functionality be built into 'sigsum-verify'?
It could, yes. But it's a different type of verification (online and with linear overhead) so I think it probably deserves its own tool.
Or could the functionality of 'sigsum-verify' be built into 'sigsum-release-verify'?
That's actually what the prototype does right now -- it does sigsum-verify and checks (online) that there are no hidden releases.
Having a small dedicated purpose tool similar to 'gpgv' but doing Sigsum signature verification against some trust policy and/or checking for hidden releases would be good for release announcement instructions.
It would be nice if users doesn't have to run two separate tools to do these checks, if they can be done quickly at the same time.
As hinted on above, the problem is sigsum-release-verify would not be so efficient that it completes in reasonable time for every user that wants to install something. I think more of this as: I install something and ensure sigsum-verify is happy -> that means *someone else* that runs the more expensive sigsum-release-verify can tell if I'm being owned.
So it's detection after-the-fact rather than proactive prevention.
But I like the idea of still having something about how to run this verification in the release announcement, because that's what it's all about: *there's a claim, and it is possible to verify the claim*.
I suppose checking for hidden releases is an online operation?
Yes, correct!
Bonus points for a python or C client too :)
Hehe, I'm sure that will be available some day. Nothing that we're currently hacking on right now though, contributions welcome! :)
-Rasmus _______________________________________________ Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
What the tool does right now is basically this:
Locate all releases at: https://api.github.com/repos/FiloSottile/age/releases
The above API is documented here: https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28
Then what happens is that the tool downloads the respective release assets. In the case of age, some tarballs with binaries + .proofs.
Then the tool does sigsum-verify. So far nothing very exciting is happening, but it is now e.g. possible to notice if Filippo forgot to upload .proof files. Which he did, and which I noticed. Wink wink. :)
The tool is currently also shelling out for each asset, with the intent to rebuild the asset and ensure Filippo's binary is correct for the respective git tags. But that part is TODO, see this week's minutes:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/archive/202...
Okay, now the cool part. The tool downloads every entry from sigsum log(s), filtering on the keys Filippo use to create his .proof files. Finally, the tool computes the diff between what Filippo published on the release page and what checksums he signed and published in Sigsum. If there's something in the log that he didn't publish -> hidden release. Now you know, and you can conversate about it with filippo.
Thank you! This helps to understand it.
But how would this work if I release two different projects with the same public key?
Don't you need the ability to enumerate all software releases made by the same public key, not just per project?
My plan has been to do a couple of releases and publish *.proof files for them. Maybe using the same public key is then not the best idea any more? And your approach suggests it is better to use a per-project private key, to allow this kind of "No hidden release" monitoring in a simple way?
Btw, my release artifacts will be reproducible, I already check that in a GitLab pipeline.
/Simon
Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
But how would this work if I release two different projects with the same public key?
Don't you need the ability to enumerate all software releases made by the same public key, not just per project?
In principle, you need a way to identify and verify the claim the signature is supposed to express. If you're happy with a general claim "this is some software package released by Simon", then you can use the same key. A monitor like the one Rasmus is describing then needs a way to locate all your releases, regardless of project.
But maybe you'd want to make a more precise claim like "this is the authentic version X release of project Y". You could still use a single signing key, if X and Y are included in the signed data (which they typically are, in a somewhat implicit way, embedded in the file name of the top-level directory in the signed tar file).
For the general case, I think it may be beneficial with one level of indirection: Make the claim explicit as some kind of manifest (including hashes and urls for the data relevant to the claim), sign and log that manifest, and provide a service that lets monitors and others look up manifest by the logged checksum. Probably not something you want to design at the moment, though.
But the important thing is that a monitor for your releases needs to know (i) the public key(s) you use when logging, and (ii) how to verify the claim that is implied by a logged entry, starting only from the keyhash and checksum in the entry itself.
My plan has been to do a couple of releases and publish *.proof files for them. Maybe using the same public key is then not the best idea any more? And your approach suggests it is better to use a per-project private key, to allow this kind of "No hidden release" monitoring in a simple way?
Using separate keys makes it easier to separate different types of claims. But if the set of projects is small (or rather, the various rules for how to locate corresponding data is small), I think it should work with a single key too.
Btw, my release artifacts will be reproducible, I already check that in a GitLab pipeline.
Cool! You may want to log reproducibility statements as well, separately from the releases themselves. I wrote down some thoughts about that on https://lists.system-transparency.org/mailman3/hyperkitty/list/st-discuss@li...
It's really nice that you are working out how to assemble our pieces into something working in pratice :-)
Regards, /Niels
On Thu, Jan 09, 2025 at 05:33:28PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
What the tool does right now is basically this:
Locate all releases at: https://api.github.com/repos/FiloSottile/age/releases
The above API is documented here: https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28
Then what happens is that the tool downloads the respective release assets. In the case of age, some tarballs with binaries + .proofs.
Then the tool does sigsum-verify. So far nothing very exciting is happening, but it is now e.g. possible to notice if Filippo forgot to upload .proof files. Which he did, and which I noticed. Wink wink. :)
The tool is currently also shelling out for each asset, with the intent to rebuild the asset and ensure Filippo's binary is correct for the respective git tags. But that part is TODO, see this week's minutes:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/archive/202...
Okay, now the cool part. The tool downloads every entry from sigsum log(s), filtering on the keys Filippo use to create his .proof files. Finally, the tool computes the diff between what Filippo published on the release page and what checksums he signed and published in Sigsum. If there's something in the log that he didn't publish -> hidden release. Now you know, and you can conversate about it with filippo.
Thank you! This helps to understand it.
But how would this work if I release two different projects with the same public key?
Don't you need the ability to enumerate all software releases made by the same public key, not just per project?
In theory I don't see why "sigsum-release-verify" couldn't pull releases from more than one release page. What would probably happen if you have the same key for more than one project is: once you start releasing something new, someone that doesn't know about it will notice a "hidden release" that you can explain by telling them about the new project. And there would no longer be any hidden releases once they reconfigure.
My plan has been to do a couple of releases and publish *.proof files for them. Maybe using the same public key is then not the best idea any more? And your approach suggests it is better to use a per-project private key, to allow this kind of "No hidden release" monitoring in a simple way?
I haven't thought enough about it yet -- I think both could work, but I'm not sure which one is easier. What do you think sounds easier?
Btw, my release artifacts will be reproducible, I already check that in a GitLab pipeline.
Awesome -- and you'll be releasing on a GitLab release page? Or where will the tarballs and .proof files be available? Perhaps we can adapt age-release-verify to a prototype that works for your dogfooding?
-Rasmus
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
Thank you! This helps to understand it.
But how would this work if I release two different projects with the same public key?
Don't you need the ability to enumerate all software releases made by the same public key, not just per project?
In theory I don't see why "sigsum-release-verify" couldn't pull releases from more than one release page. What would probably happen if you have the same key for more than one project is: once you start releasing something new, someone that doesn't know about it will notice a "hidden release" that you can explain by telling them about the new project. And there would no longer be any hidden releases once they reconfigure.
Oh. I'm not sure I can commit to this key life-cycle management myself. I am a bit too used to do "test" releases that involve full signatures and complete announcements, that look like the real things. I may have already pushed out "hidden releases" for my existing SSH public-key when I have tested your tools.
So maybe I have to generate a new personal private key used for Sigsum-based release signing, and only use it when I really want to commit to a particular release forever. That seems to match the semantics that your tool would be testing for.
My plan has been to do a couple of releases and publish *.proof files for them. Maybe using the same public key is then not the best idea any more? And your approach suggests it is better to use a per-project private key, to allow this kind of "No hidden release" monitoring in a simple way?
I haven't thought enough about it yet -- I think both could work, but I'm not sure which one is easier. What do you think sounds easier?
I fear there is no simple answer, this seems like a key management issue that is beyond what tools can help with.
Consider if I a co-maintainer wants to sign a new release, I wouldn't want to share my general-purpose private key with that person, but it may be reasonable to have a sigsum "no hidden release" per-project long-term private key and pass it around between maintainers, at least for as long as it is possible to keep it protected. On the other hand, then there would be no single person to Have A Conversation With in case of a hidden release, so this approach may be a bad idea.
Btw, my release artifacts will be reproducible, I already check that in a GitLab pipeline.
Awesome -- and you'll be releasing on a GitLab release page? Or where will the tarballs and .proof files be available? Perhaps we can adapt age-release-verify to a prototype that works for your dogfooding?
I am using many different workflows. Some projects use GitLab release pages, some uses GitLab but releases are pushed elsewhere, and some projects aren't using GitLab at all. Some produce the release artifacts in the GitLab pipeline, some don't.
But I'm happy to pick some project to use for experimentation, to iterate on this. Libntlm has been my typical toy project to experiment releases processes with. https://gitlab.com/gsasl/libntlm/-/releases
/Simon
Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
Oh. I'm not sure I can commit to this key life-cycle management myself. I am a bit too used to do "test" releases that involve full signatures and complete announcements, that look like the real things. I may have already pushed out "hidden releases" for my existing SSH public-key when I have tested your tools.
I think anything you submit to a sigsum log ought to be made available to third-party monitors (via a release page, or a service mapping checksum to data, or any other means) more or less forever.
Then it may still be somewhat reasonable to use the same key for signing other non-logged stuff; there's some domain separation by the sigsum signatures always signing the data "sigsum.org/v1/tree-leaf" NUL <checksum>.
So maybe I have to generate a new personal private key used for Sigsum-based release signing, and only use it when I really want to commit to a particular release forever. That seems to match the semantics that your tool would be testing for.
I think there should be some clear distinction between "test" releases and advertised releases. That could be in the signed data, e.g., name of the top-level directory in the tar file looking like "rcX or "test", or it could be a separate signing key. But preferably well documented and machine processable.
It could make sense to sigsum log all test releases and keep them available, to be able to detect if an attacker who has compromised your key sends users rogue "test" release. But you probably do not want an attacker to be able to substitute a test release when they expect an official advertised release? (Related to the general problem of downgrade attacks).
Regards, /Niels
On Mon, Jan 13, 2025 at 02:28:46PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
Thank you! This helps to understand it.
But how would this work if I release two different projects with the same public key?
Don't you need the ability to enumerate all software releases made by the same public key, not just per project?
In theory I don't see why "sigsum-release-verify" couldn't pull releases from more than one release page. What would probably happen if you have the same key for more than one project is: once you start releasing something new, someone that doesn't know about it will notice a "hidden release" that you can explain by telling them about the new project. And there would no longer be any hidden releases once they reconfigure.
Oh. I'm not sure I can commit to this key life-cycle management myself. I am a bit too used to do "test" releases that involve full signatures and complete announcements, that look like the real things. I may have already pushed out "hidden releases" for my existing SSH public-key when I have tested your tools.
Another option is to only use Sigsum *for you* to be able to verify what happens with your signing key. For example, you kindly ask folks to sigsum-verify, and what that facilitates is that only you can meaningfully run sigsum-monitor (or a more production-worthy tool in the future) that notifies *you* whenever there is a new sigsum signature.
Presumably, you (but nobody else) would know when you intended to sign something. So this would help you detect when your key is compromised, but it wouldn't help others to detect if you're signing secret stuff.
This is a perfectly good use of Sigsum as well -- no need to go all the way and make additional claims and involve "sigsum-release-verify".
So maybe I have to generate a new personal private key used for Sigsum-based release signing, and only use it when I really want to commit to a particular release forever. That seems to match the semantics that your tool would be testing for.
My plan has been to do a couple of releases and publish *.proof files for them. Maybe using the same public key is then not the best idea any more? And your approach suggests it is better to use a per-project private key, to allow this kind of "No hidden release" monitoring in a simple way?
I haven't thought enough about it yet -- I think both could work, but I'm not sure which one is easier. What do you think sounds easier?
I fear there is no simple answer, this seems like a key management issue that is beyond what tools can help with.
Yep, agreed.
Consider if I a co-maintainer wants to sign a new release, I wouldn't want to share my general-purpose private key with that person, but it may be reasonable to have a sigsum "no hidden release" per-project long-term private key and pass it around between maintainers, at least for as long as it is possible to keep it protected. On the other hand, then there would be no single person to Have A Conversation With in case of a hidden release, so this approach may be a bad idea.
I would probably make each co-maintainer have a separate sigsum key, just like each co-maintainer currently would have a separate PGP key. The sigsum-release-verify tool takes as input all (co-)maintainer keys, and can then pin-point who (which key) signed off a hidden release.
Wrt. "pass around the key approach" -- not ideal, but a silverlining is that you could at least detect when the key is compromised with Sigsum.
Btw, my release artifacts will be reproducible, I already check that in a GitLab pipeline.
Awesome -- and you'll be releasing on a GitLab release page? Or where will the tarballs and .proof files be available? Perhaps we can adapt age-release-verify to a prototype that works for your dogfooding?
I am using many different workflows. Some projects use GitLab release pages, some uses GitLab but releases are pushed elsewhere, and some projects aren't using GitLab at all. Some produce the release artifacts in the GitLab pipeline, some don't.
But I'm happy to pick some project to use for experimentation, to iterate on this. Libntlm has been my typical toy project to experiment releases processes with. https://gitlab.com/gsasl/libntlm/-/releases
If you can point me towards a GitLab release page (like the above) that has tarballs (or similar) + .proof, then I can try to best-effort adapt age-release-verify to work for that. Should be pretty quick unless I run into something unexpected when trying to use the GitLab API.
-Rasmus
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
On Mon, Jan 13, 2025 at 02:28:46PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
Thank you! This helps to understand it.
But how would this work if I release two different projects with the same public key?
Don't you need the ability to enumerate all software releases made by the same public key, not just per project?
In theory I don't see why "sigsum-release-verify" couldn't pull releases from more than one release page. What would probably happen if you have the same key for more than one project is: once you start releasing something new, someone that doesn't know about it will notice a "hidden release" that you can explain by telling them about the new project. And there would no longer be any hidden releases once they reconfigure.
Oh. I'm not sure I can commit to this key life-cycle management myself. I am a bit too used to do "test" releases that involve full signatures and complete announcements, that look like the real things. I may have already pushed out "hidden releases" for my existing SSH public-key when I have tested your tools.
Another option is to only use Sigsum *for you* to be able to verify what happens with your signing key. For example, you kindly ask folks to sigsum-verify, and what that facilitates is that only you can meaningfully run sigsum-monitor (or a more production-worthy tool in the future) that notifies *you* whenever there is a new sigsum signature.
Presumably, you (but nobody else) would know when you intended to sign something. So this would help you detect when your key is compromised, but it wouldn't help others to detect if you're signing secret stuff.
This is a perfectly good use of Sigsum as well -- no need to go all the way and make additional claims and involve "sigsum-release-verify".
I think the "no hidden releases" ability is actually one of few practical immediate things an end-user gets from Sigsum but doesn't get from PGP.
So I'll try to adapt my workflow to make this possible, but I'm not yet sure how to do this.
Maybe this is a non-issue. Can you show me how to search the Sigsum log for any signature made by this public-key:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE
If there aren't any, I didn't manage to push anything into the log, so I should be able to use this key for sigsum signing of release artifacts going forward. And be careful to never sign anything except properly released artifacts.
Otherwise I have to generate a new private-key for my Sigsum release signing.
Consider if I a co-maintainer wants to sign a new release, I wouldn't want to share my general-purpose private key with that person, but it may be reasonable to have a sigsum "no hidden release" per-project long-term private key and pass it around between maintainers, at least for as long as it is possible to keep it protected. On the other hand, then there would be no single person to Have A Conversation With in case of a hidden release, so this approach may be a bad idea.
I would probably make each co-maintainer have a separate sigsum key, just like each co-maintainer currently would have a separate PGP key. The sigsum-release-verify tool takes as input all (co-)maintainer keys, and can then pin-point who (which key) signed off a hidden release.
Wrt. "pass around the key approach" -- not ideal, but a silverlining is that you could at least detect when the key is compromised with Sigsum.
Right, agreed, passing private key around is bad, let's avoid that.
Btw, my release artifacts will be reproducible, I already check that in a GitLab pipeline.
Awesome -- and you'll be releasing on a GitLab release page? Or where will the tarballs and .proof files be available? Perhaps we can adapt age-release-verify to a prototype that works for your dogfooding?
I am using many different workflows. Some projects use GitLab release pages, some uses GitLab but releases are pushed elsewhere, and some projects aren't using GitLab at all. Some produce the release artifacts in the GitLab pipeline, some don't.
But I'm happy to pick some project to use for experimentation, to iterate on this. Libntlm has been my typical toy project to experiment releases processes with. https://gitlab.com/gsasl/libntlm/-/releases
If you can point me towards a GitLab release page (like the above) that has tarballs (or similar) + .proof, then I can try to best-effort adapt age-release-verify to work for that. Should be pretty quick unless I run into something unexpected when trying to use the GitLab API.
I will post links once I managed to iterate into actual releases of the projects I want to do this for. I think GitLab release pages, Savannah download area, and ftp.gnu.org distributions cover my use-cases.
/Simon
Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
Maybe this is a non-issue. Can you show me how to search the Sigsum log for any signature made by this public-key:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE
$ cat >jas.key ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE ^D $ cat >glasklar.policy log 0ec7e16843119b120377a73913ac6acbc2d03d82432e2c36b841b09a95841f25 https://seasalp.glasklar.is log 154f49976b59ff09a123675f58cb3e346e0455753c3c3b15d465dcb4f6512b0b https://poc.sigsum.org/jellyfish quorum none ^D $ go run ./cmd/sigsum-monitor/ --interval 5s -p glasklar.policy jas.key New c9e525b98f412ede185ff2ac5abf70920a2e63a6ae31c88b1138b85de328706b tree, size 33168 New 44ad38f8226ff9bd27629a41e55df727308d0a1cd8a2c31d3170048ac1dd22a1 tree, size 684 New 44ad38f8226ff9bd27629a41e55df727308d0a1cd8a2c31d3170048ac1dd22a1 leaves, count 0, total processed 512 New 44ad38f8226ff9bd27629a41e55df727308d0a1cd8a2c31d3170048ac1dd22a1 leaves, count 0, total processed 684 [...] ^C
I get no leaves matching your key. As you see, the monitor tooling is a bit rough. One feature in particular, that Rasmus has asked for, is a mode that exits as soon as it has read to the end of all logs, rather than waiting for more data to appear.
Alternatively, you could use a script looping over over the get-leaves endpoint to download all leaves, and then grep for the keyhash, which is
$ go run ./cmd/sigsum-key/ to-hash -k jas.key 7d57f39e21aafda397c1ec8d413694a7a77b3e86b7cefff4c7d9e87497b41499
The advantage of using the monitor is that it doesn't blindly trust the get-leaves responses: it also requests inclusion proofs and checks that the leaves are consistent with the log's signed tree head.
Regards, /Niels
On Tue, Jan 14, 2025 at 08:48:38AM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
On Mon, Jan 13, 2025 at 02:28:46PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
Thank you! This helps to understand it.
But how would this work if I release two different projects with the same public key?
Don't you need the ability to enumerate all software releases made by the same public key, not just per project?
In theory I don't see why "sigsum-release-verify" couldn't pull releases from more than one release page. What would probably happen if you have the same key for more than one project is: once you start releasing something new, someone that doesn't know about it will notice a "hidden release" that you can explain by telling them about the new project. And there would no longer be any hidden releases once they reconfigure.
Oh. I'm not sure I can commit to this key life-cycle management myself. I am a bit too used to do "test" releases that involve full signatures and complete announcements, that look like the real things. I may have already pushed out "hidden releases" for my existing SSH public-key when I have tested your tools.
Another option is to only use Sigsum *for you* to be able to verify what happens with your signing key. For example, you kindly ask folks to sigsum-verify, and what that facilitates is that only you can meaningfully run sigsum-monitor (or a more production-worthy tool in the future) that notifies *you* whenever there is a new sigsum signature.
Presumably, you (but nobody else) would know when you intended to sign something. So this would help you detect when your key is compromised, but it wouldn't help others to detect if you're signing secret stuff.
This is a perfectly good use of Sigsum as well -- no need to go all the way and make additional claims and involve "sigsum-release-verify".
I think the "no hidden releases" ability is actually one of few practical immediate things an end-user gets from Sigsum but doesn't get from PGP.
So I'll try to adapt my workflow to make this possible, but I'm not yet sure how to do this.
Maybe this is a non-issue. Can you show me how to search the Sigsum log for any signature made by this public-key:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE
If there aren't any, I didn't manage to push anything into the log, so I should be able to use this key for sigsum signing of release artifacts going forward. And be careful to never sign anything except properly released artifacts.
Otherwise I have to generate a new private-key for my Sigsum release signing.
Consider if I a co-maintainer wants to sign a new release, I wouldn't want to share my general-purpose private key with that person, but it may be reasonable to have a sigsum "no hidden release" per-project long-term private key and pass it around between maintainers, at least for as long as it is possible to keep it protected. On the other hand, then there would be no single person to Have A Conversation With in case of a hidden release, so this approach may be a bad idea.
I would probably make each co-maintainer have a separate sigsum key, just like each co-maintainer currently would have a separate PGP key. The sigsum-release-verify tool takes as input all (co-)maintainer keys, and can then pin-point who (which key) signed off a hidden release.
Wrt. "pass around the key approach" -- not ideal, but a silverlining is that you could at least detect when the key is compromised with Sigsum.
Right, agreed, passing private key around is bad, let's avoid that.
Btw, my release artifacts will be reproducible, I already check that in a GitLab pipeline.
Awesome -- and you'll be releasing on a GitLab release page? Or where will the tarballs and .proof files be available? Perhaps we can adapt age-release-verify to a prototype that works for your dogfooding?
I am using many different workflows. Some projects use GitLab release pages, some uses GitLab but releases are pushed elsewhere, and some projects aren't using GitLab at all. Some produce the release artifacts in the GitLab pipeline, some don't.
But I'm happy to pick some project to use for experimentation, to iterate on this. Libntlm has been my typical toy project to experiment releases processes with. https://gitlab.com/gsasl/libntlm/-/releases
If you can point me towards a GitLab release page (like the above) that has tarballs (or similar) + .proof, then I can try to best-effort adapt age-release-verify to work for that. Should be pretty quick unless I run into something unexpected when trying to use the GitLab API.
I will post links once I managed to iterate into actual releases of the projects I want to do this for. I think GitLab release pages, Savannah download area, and ftp.gnu.org distributions cover my use-cases.
Great! In the mean time I filed this:
https://git.glasklar.is/rgdd/age-release-verify/-/issues/1
-Rasmus
I extrapolated a README from the below, see:
https://git.glasklar.is/rgdd/age-release-verify
-Rasmus
On Wed, Jan 08, 2025 at 04:15:49PM +0100, Rasmus Dahlberg wrote:
What the tool does right now is basically this:
Locate all releases at: https://api.github.com/repos/FiloSottile/age/releases
The above API is documented here: https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28
Then what happens is that the tool downloads the respective release assets. In the case of age, some tarballs with binaries + .proofs.
Then the tool does sigsum-verify. So far nothing very exciting is happening, but it is now e.g. possible to notice if Filippo forgot to upload .proof files. Which he did, and which I noticed. Wink wink. :)
The tool is currently also shelling out for each asset, with the intent to rebuild the asset and ensure Filippo's binary is correct for the respective git tags. But that part is TODO, see this week's minutes:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/archive/202...
Okay, now the cool part. The tool downloads every entry from sigsum log(s), filtering on the keys Filippo use to create his .proof files. Finally, the tool computes the diff between what Filippo published on the release page and what checksums he signed and published in Sigsum. If there's something in the log that he didn't publish -> hidden release. Now you know, and you can conversate about it with filippo.
On Wed, Jan 08, 2025 at 02:09:21PM +0100, Sigsum General wrote:
Thanks for explaining! Sounds good. Could a tool like 'age-release-verify' be made independent of GitHub?
Yes, and I hope the above blurb helps describe how. Replace enumeration of GitHub's API with say GitLab's API, or even more plain listings like https://dist.system-transparency.org/st/. It doesn't matter where the data is downloaded from, as long as you know how to enumerate it.
For us who doesn't like to think too hard, could there be some documentation explaining exactly how the tool works? What requests are made to where, and how? How is it searching for hidden releases?
Yes -- I probably won't do it for the age-release-verify repository because it's a quick hacky prototype. But I'd like a more proper demo with such documentation, similar to www.sigsum.org/getting-started but focused on this particular use-case rather than just signed checksums.
Could all of the data be supplied on the command-line instead? Except, presumably, for the online Sigsum log queries that have no offline serialized artifact?
Yes, that's what I'm doing in this (slighly more documented) demo:
https://git.glasklar.is/rgdd/sshdt https://git.glasklar.is/rgdd/sshdt/-/blob/main/Makefile?ref_type=heads#L42
-Rasmus
/Simon
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
On Tue, Jan 07, 2025 at 09:08:08PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
Use the .proof file to verify the Sigsum proof. These files are like signatures with extra transparency: you can cryptographically verify that every proof is logged in a public append-only log, so you can say with confidence what signatures exists. This helps to protect against secret (targetted and/or malicious) releases.
If you want some inspiration for why the above paragraph is true:
https://git.glasklar.is/rgdd/age-release-verify
I'd love to see a similar prototype for your use-case!
Neat!
Could that tool be extended to do the same for arbitrary release proofs, not only 'age'? Maybe call it be 'sigsum-release-verify'?
That's an interesting idea -- I think it would be extensible yes. The current prototype should already work for any GitHub release page, so I don't see why it wouldn't be possible to make this into a tool that knows how to fetch releases from various common APIs / release pages. And then it optionally hands over to a user-supplied script that does rebuilding (i.e., the actual rebuilding is not in scope of the tool).
Could this functionality be built into 'sigsum-verify'?
It could, yes. But it's a different type of verification (online and with linear overhead) so I think it probably deserves its own tool.
Or could the functionality of 'sigsum-verify' be built into 'sigsum-release-verify'?
That's actually what the prototype does right now -- it does sigsum-verify and checks (online) that there are no hidden releases.
Having a small dedicated purpose tool similar to 'gpgv' but doing Sigsum signature verification against some trust policy and/or checking for hidden releases would be good for release announcement instructions.
It would be nice if users doesn't have to run two separate tools to do these checks, if they can be done quickly at the same time.
As hinted on above, the problem is sigsum-release-verify would not be so efficient that it completes in reasonable time for every user that wants to install something. I think more of this as: I install something and ensure sigsum-verify is happy -> that means *someone else* that runs the more expensive sigsum-release-verify can tell if I'm being owned.
So it's detection after-the-fact rather than proactive prevention.
But I like the idea of still having something about how to run this verification in the release announcement, because that's what it's all about: *there's a claim, and it is possible to verify the claim*.
I suppose checking for hidden releases is an online operation?
Yes, correct!
Bonus points for a python or C client too :)
Hehe, I'm sure that will be available some day. Nothing that we're currently hacking on right now though, contributions welcome! :)
-Rasmus _______________________________________________ Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
I extrapolated a README from the below, see:
I was inspired by that concept:
https://gitlab.com/debdistutils/sigsum-artifact-reproducer
It is a monitor track what my release SSH key has signed, and (hopefully) to continously over the coming years attempt to reproduce those release artifacts from git repository content.
There is one job "no-hidden-releases" that runs sigsum-monitor and looks for things signed by my SSH key. The job will fail if there are any unknown checksums in the log, suggesting existance of "hidden releases".
There are jobs "libtasn1-v4.20.0" and "inetutils-v2.6" that rebuild from git the release artifacts and compare those checksums with what's stored in the Sigsum log. The scripts to reproduce the artifacts should work in any encironment that has Guix for time travelling, and common tools like 'xxd', 'sha256sum' etc.
This is designed differently than your project above, and it isn't really a third-party monitor since someone other than me would have to audit the code and run it. But it is quite small and easy to audit.
This is designed on a per-user/key perspective rather than per-project perspective. I'm not sure how a monitor for a single project with releases signed by multiple people would look like, since those people could also sign other unrelated artifacts. Maintaining distinct per-user per-project private keys sounds horrible to me, but I would prefer the concept of a "project-specific" release artifact monitor rather than it being "maintainer-specific".
/Simon
Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
This is designed on a per-user/key perspective rather than per-project perspective. I'm not sure how a monitor for a single project with releases signed by multiple people would look like, since those people could also sign other unrelated artifacts.
There may be other ways, but I think this case needs an additional level of indirection.
The key owner would need to sign and publish claims, where at a minimum a claim is some machine-readable statement like "the artifact with sha256 hash xxx is an official artifact of the foo project". The key owner would sign such claims, and submit them to the log. And in addition, publish then in a way so that they can be retrieved by hash.
A monitor enumerates signatures of interest, retrieves each corresponding claim, and can then do further verification of claims about projects of interest to the monitor.
On the verifier side, one would need the artifact itself, the claim, and the sigsum proof for that claim. Which gets a bit more unwieldy. If we want to stick to the verifier story that it's an artifact with a "spicy signature", that means that we need to start thinking about bundling claim + proof. Defining a machine-readable claim format might be a can of worms, but I think it can be an important improvement over the current state where the closest thing we have to a claim is the filename of the signed artifact, for which the authenticity story is rather weak.
Regards, /Niels
Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
This is designed on a per-user/key perspective rather than per-project perspective. I'm not sure how a monitor for a single project with releases signed by multiple people would look like, since those people could also sign other unrelated artifacts.
There may be other ways, but I think this case needs an additional level of indirection.
The key owner would need to sign and publish claims, where at a minimum a claim is some machine-readable statement like "the artifact with sha256 hash xxx is an official artifact of the foo project". The key owner would sign such claims, and submit them to the log. And in addition, publish then in a way so that they can be retrieved by hash.
A monitor enumerates signatures of interest, retrieves each corresponding claim, and can then do further verification of claims about projects of interest to the monitor.
On the verifier side, one would need the artifact itself, the claim, and the sigsum proof for that claim. Which gets a bit more unwieldy. If we want to stick to the verifier story that it's an artifact with a "spicy signature", that means that we need to start thinking about bundling claim + proof. Defining a machine-readable claim format might be a can of worms, but I think it can be an important improvement over the current state where the closest thing we have to a claim is the filename of the signed artifact, for which the authenticity story is rather weak.
How do that approach protect against hidden releases?
Can't the key owner just sign a separate "hidden" claim that "artifact with SHA256 hash yyy is an official artifact of the foo project" and give that to a targeted user?
Since presumably in this situation the key owner is adding a lot of other unrelated signatures to the log, the problem seems to be that there is no way to enumerate and inspect all claims from the key owner. The key owner can deny things like "oh that was a signature for our private internal project bar that I cannot share any details on, but I assure you it is not related to foo".
Sigstore kind of "solves" this by allowing storing the data that is signed in the log too. I'm told they will stop support that though, so we need some better mechanism.
For me, the "no hidden releases" feature is the only feature of a transparency log that I'm able to explain to a user.
I can't seem to be able to get around the need for being able to somehow be able to download the checksumed content corresponding to ALL signatures from a particular key. If you cannot access the content for ALL signatures in the log, there is no way to protect against hidden releases, is there? The moment you upload a signature to the log for a checksum on some content that you later forget, all good properties seems lost. This means I have to very careful what I sign going forward, since any mistake will essentially make my current key untrustworthy.
It is okay if I make a mistake and sign some corrupt tarball: I can explain this situation if I still have the corrupt tarball. But if I run a set of commands to sign some artifact that I accidentally remove, then things are really bad for that key.
/Simon
Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
A monitor enumerates signatures of interest, retrieves each corresponding claim, and can then do further verification of claims about projects of interest to the monitor.
How do that approach protect against hidden releases?
Can't the key owner just sign a separate "hidden" claim that "artifact with SHA256 hash yyy is an official artifact of the foo project" and give that to a targeted user?
In this setting, *all* signed and logged claims by that key ought to be public, and a monitor should alert if the claim corresponding to a signed entry in the log isn't available for inspection.
I can't seem to be able to get around the need for being able to somehow be able to download the checksumed content corresponding to ALL signatures from a particular key.
I think that observation is absolutely right. That publication service is something the project or key holder needs to operate or rely on, separately from the sigsum logging.
It is okay if I make a mistake and sign some corrupt tarball: I can explain this situation if I still have the corrupt tarball. But if I run a set of commands to sign some artifact that I accidentally remove, then things are really bad for that key.
To reduce the risk for mistakes, when using your actual release signing key, it makes sense to ensure that the artifact is reliably archived, *before* signing and submitting it to the log. Maybe we can add some features to sigsum-submit to help, e.g., accept both a url and a local file as argument, and ensure that they are identical before signing, or maybe even upload directly with the archival service if we can define the conventions for that.
(And with indirection via signed claims, the primary importance is that the *claim* is properly archived. Messing up and losing artifacts referenced in the claim becomes a somewhat different story).
Regards, /Niels
Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
I can't seem to be able to get around the need for being able to somehow be able to download the checksumed content corresponding to ALL signatures from a particular key.
I think that observation is absolutely right. That publication service is something the project or key holder needs to operate or rely on, separately from the sigsum logging.
Thanks for confirming that, I wasn't certain.
I think there are ways to avoid this, by adding more logic to the log, just like Sigstore has. If it was possible to add a context separator tag to a submission, and that were stored in the log, a monitor could filter for only the relevant context tags.
It is okay if I make a mistake and sign some corrupt tarball: I can explain this situation if I still have the corrupt tarball. But if I run a set of commands to sign some artifact that I accidentally remove, then things are really bad for that key.
To reduce the risk for mistakes, when using your actual release signing key, it makes sense to ensure that the artifact is reliably archived, *before* signing and submitting it to the log. Maybe we can add some features to sigsum-submit to help, e.g., accept both a url and a local file as argument, and ensure that they are identical before signing, or maybe even upload directly with the archival service if we can define the conventions for that.
Yes, I think that this combined functionality would be nice. Since the "no hidden release" property appear to depend so strongly on a workflow that forever only adds signatures for publicly available content, the tools can help to assert that before completing the upload.
I'm thinking something like this:
ssh-add -L > jas.pub sigsum-submit -k jas.pub libidn2-2.3.8.tar.gz sigsum-submit --timeout 30s --diagnostics=debug -p sigsum-policy-20250309.txt --token-signing-key ~/self/sigsum-token-secret-josefsson.org/mykey --token-domain josefsson.org --content-url https://ftp.gnu.org/gnu/libidn/libidn2-2.3.8.tar.gz libidn2-2.3.8.tar.gz.req
The tool should attempt to download the URL and verify that its SHA256 checksum match the 'message' field in the *.req file.
/Simon
I added this idea here:
https://git.glasklar.is/sigsum/core/sigsum-go/-/issues/111
You mentioned an archival service, what is that? One idea is to recommend people to get things archived into the Software Heritage:
https://archive.softwareheritage.org/save/
I don't find how to add tarballs though, otherwise maybe sigsum-submit could have an option to confirm that the artifact has been archived by Software Heritage.
/Simon
Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
It is okay if I make a mistake and sign some corrupt tarball: I can explain this situation if I still have the corrupt tarball. But if I run a set of commands to sign some artifact that I accidentally remove, then things are really bad for that key.
To reduce the risk for mistakes, when using your actual release signing key, it makes sense to ensure that the artifact is reliably archived, *before* signing and submitting it to the log. Maybe we can add some features to sigsum-submit to help, e.g., accept both a url and a local file as argument, and ensure that they are identical before signing, or maybe even upload directly with the archival service if we can define the conventions for that.
Yes, I think that this combined functionality would be nice. Since the "no hidden release" property appear to depend so strongly on a workflow that forever only adds signatures for publicly available content, the tools can help to assert that before completing the upload.
I'm thinking something like this:
ssh-add -L > jas.pub sigsum-submit -k jas.pub libidn2-2.3.8.tar.gz sigsum-submit --timeout 30s --diagnostics=debug -p sigsum-policy-20250309.txt --token-signing-key ~/self/sigsum-token-secret-josefsson.org/mykey --token-domain josefsson.org --content-url https://ftp.gnu.org/gnu/libidn/libidn2-2.3.8.tar.gz libidn2-2.3.8.tar.gz.req
The tool should attempt to download the URL and verify that its SHA256 checksum match the 'message' field in the *.req file.
/Simon
Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
Simon Josefsson simon@josefsson.org writes:
I added this idea here:
Thanks, I've commented on the issue.
You mentioned an archival service, what is that?
I didn't have any particular service in mind, just the abstract thing of somewhere where key owner is authorized to upload data, and where data is properly backed up and/or mirrored, unlikely to disappear, and available to the public.
One idea is to recommend people to get things archived into the Software Heritage:
I'm not familiar with software heritage. I imagine an archive where random users can upload stuff will have its own set of complications, including some procedure to unpublish stuff for legal reasons. But at least, those issues are different from hosting a public sigsum log, which is why separation makes sense to me.
I think it's also worth noting that if you sigsum log a claim that an artifact with a given hash is reproducibly built from some recipe (repo, git tag, toolchain version etc) it's not strictly necessary to put the artifact itself into a reliable archive service.
Regards, /Niels
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
What you have in the current template looks as good as it gets right now!
Thank you!
Avoiding the ugly Unix-specific 'cat<<EOF>' garbage was the primary thing I was thinking about. Maybe the public key can be taken on the command line as strings?
What we discussed so far with Filippo to shrink it:
**Named trust policies.** So that you would only have to say here are my Sigsum key(s) and they should be used with "Debian's trust policy", "the builtin default policy", etc. A key-line might look like this:
sigsum_policy="builtin" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM1WpnEswJLPzvXJDiswowy48U+G+G1kmgwUE2eaRHZG
With the idea that it should be possible to specify either the default, or to override it by, e.g., using the policy an apt-package installed.
Or maybe saying nothing implies builtin, and there is a way to override it with the sigsum_policy option as shown above. This is all work in progress ideas that we have yet to hash out (but you might get the idea), so if you have any feedback or related ideas to explore shoot!
I would prefer if tools used a system-installed /etc/sigsum/trust-policy.conf file with options to disable and/or override and use a user-provided trust file. Please don't hard wire magic crypto values into the binary, it smells of TPM's.
Another idea is to use named self-integrity-protected trust policies like this:
cat <<EOF > inetutils-sigsum-trust-policy.txt log 154f49976b59ff09a123675f58cb3e346e0455753c3c3b15d465dcb4f6512b0b https://poc.sigsum.org/jellyfish witness poc.sigsum.org/nisse 1c25f8a44c635457e2e391d1efbca7d4c2951a0aef06225a881e46b98962ac6c witness rgdd.se/poc-witness 28c92a5a3a054d317c86fc2eeb6a7ab2054d6217100d0be67ded5b74323c5806 group demo-quorum-rule all poc.sigsum.org/nisse rgdd.se/poc-witness quorum demo-quorum-rule EOF
sha256sum inetutils-sigsum-trust-policy.txt => 72af4399354bc7803a540999c27d249493f8fd00e74414e0de79e692260df635 inetutils-sigsum-trust-policy.txt
Then that file could be provided in
/etc/sigsum/trust-policy.d/72af4399354bc7803a540999c27d249493f8fd00e74414e0de79e692260df635.conf
and the user could run something like this:
sigsum-verify --signing-key "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE" \ --trust-policy-hash 72af4399354bc7803a540999c27d249493f8fd00e74414e0de79e692260df635 \ inetutils-2.6.tar.gz.proof < inetutils-2.6.tar.gz
Assuming the system installed this particular trust policy during installation. This avoids you "blessing" any particular trust policy, but move this on to users.
But basically, I'd like to not force the very long trust policy blurbs in everyones READMEs. And to have named trust policies to pick from.
+1
**Better primer page for users.** So, basically something similar to www.so/getting-started; but targeted solely for users that want to use sigsum-verify rather than getting a full demo of the entire system.
+1
We probably also want a primer page that can be linked for the type of verification Sigsum facilitates from a 3rd-party perspective; and we should probably have a separate page dedicated for release-signing. If we had that, you could probably get away with one sentence + link.
+1
(I posted some more in-line comments further down in the template.)
Btw, I plan to use my OpenPGP authentication key (i.e., not the signature key) from my Gnuk hardware dongle, exported via GnuPG's SSH agent, for use by sigsum-submit --signing-key to create *.proof. Does anyone see a problem with this? I don't know how to make my OpenPGP signature key from the Gnuk available via the SSH agent easily, has anyone done that? I haven't thought through the flow here. The threat I'm worried about is if some remote SSH server abuse my setup to make me sign some blob that may later be submitted to the Sigsum transparency log as a release signature? Is there sufficient domain context separation happening here? It doesn't feel intuitively safe.
/Simon
... Here is the GNU inetutils home page: https://gnu.org/s/inetutils/
Here are the compressed sources: https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.gz (2.9MB) https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.xz (1.7MB)
Here are the GPG detached signatures: https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.gz.sig https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.xz.sig
Here is minimal source-only "git archive" sources: https://ftpmirror.gnu.org/inetutils/inetutils-v2.6-src.tar.gz (820kB)
Here are Sigsum Proofs: https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.gz.proof https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.xz.proof https://ftpmirror.gnu.org/inetutils/inetutils-v2.6-src.tar.gz.proof
Use a mirror for higher download bandwidth: https://www.gnu.org/order/ftp.html
Here are the SHA1 and SHA256 checksums:
ced45165aeda8a9584d291b81225d86be82e1a90 inetutils-2.6.tar.gz gra2UqTds+E0rwII1iW38faAJn3igu5Wau60BvaI+HI= inetutils-2.6.tar.gz a6576bacd408adf93017f44d35608f05c893c5d5 inetutils-2.6.tar.xz YuriPIWQhNnJci9Nu+NnddrLnPDbwVXaQ3AEnkl2OCM= inetutils-2.6.tar.xz
Verify the base64 SHA256 checksum with cksum -a sha256 --check from coreutils-9.2 or OpenBSD's cksum since 2007.
Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this:
gpg --verify inetutils-2.6.tar.gz.sig
The signature should match the fingerprint of the following key:
pub ed25519 2019-03-20 [SC] B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE uid Simon Josefsson simon@josefsson.org
If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command.
gpg --locate-external-key simon@josefsson.org
gpg --recv-keys 51722B08FE4745A2
wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=inetutils&dow...' | gpg --import -
As a last resort to find the key, you can try the official GNU keyring:
wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg gpg --keyring gnu-keyring.gpg --verify inetutils-2.6.tar.gz.sig
Use the .proof file to verify the Sigsum proof. These files are like signatures with extra transparency: you can cryptographically verify that every proof is logged in a public append-only log, so you can say with confidence what signatures exists. This helps to protect against secret (targetted and/or malicious) releases.
If you want some inspiration for why the above paragraph is true:
https://git.glasklar.is/rgdd/age-release-verify
I'd love to see a similar prototype for your use-case!
Our releases are Sigsum signed with the following public key:
cat <<EOF > inetutils-sigsum-key.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE EOF
You may use the following Sigsum verification policy:
cat <<EOF > inetutils-sigsum-trust-policy.txt log 154f49976b59ff09a123675f58cb3e346e0455753c3c3b15d465dcb4f6512b0b https://poc.sigsum.org/jellyfish
Jellyfish is a prototype log -- I'd recommend that you use seasalp, Glasklar's production log. See https://www.sigsum.org/services/.
witness poc.sigsum.org/nisse 1c25f8a44c635457e2e391d1efbca7d4c2951a0aef06225a881e46b98962ac6c witness rgdd.se/poc-witness 28c92a5a3a054d317c86fc2eeb6a7ab2054d6217100d0be67ded5b74323c5806
These test/prototype witnesses are not available for seasalp. Glasklar isn't running a stable witness yet (ln5 is working on fixing that the coming weeks; I'm also told a few other organizations are looking to start running witnesses). The witness cosignatures that you see on
https://seasalp.glasklar.is/get-tree-headare all from Google TrustFabric's witness which runs from 15 different vantage points. I'd suggest using a majority policy (8/15 cosignatures). Such a policy for seasalp would look like this:
log 0ec7e16843119b120377a73913ac6acbc2d03d82432e2c36b841b09a95841f25 https://seasalp.glasklar.is witness ArmoredWitness-falling-pond 54c4862caba4ef942fe1abc6afb65d63cba0a55d3e6313ff59154b8586d882e2 witness ArmoredWitness-weathered-rain 62db94aa7926e8b2ae0461e9ebf69cd2795c077eb1cfe63360f61d6fdbe1de52 witness ArmoredWitness-wispy-wood 456f659e0b0efa658e3a2895e2775a7c6754ae09d5842241bb603d649517068f witness ArmoredWitness-small-breeze 00166295237c618f42258e82deac2d66a9d0ff6b54e7be39fbb6b8d65b3b8143 witness ArmoredWitness-quiet-wood 9b71799be731b15fe9b54f37cd6f22f9499d3e3309dabcb588bf82e234844913 witness ArmoredWitness-morning-darkness 7ba003654674398b62dd70ab369a3f750a48670354d66f79125827514a0b9fbd witness ArmoredWitness-shy-wind 198bed2687bcf60fc246eae3583f2a9764287ece65aa1aa9f2b6b04a1628be1d witness ArmoredWitness-hidden-river dae934c7cc1f45ba898a3dfe1265d492a6c58405ddec143fc16f84a0f588e3a5 witness ArmoredWitness-autumn-wood eb085426da77b81b534ec99c0e987d90f4aa0e01d5cf31178212767b7dbe38a9 witness ArmoredWitness-snowy-sound 0b85b9d46ccbd1cfa78a19b04f8fc4359538390c9d82675e89d2433217aaad50 witness ArmoredWitness-throbbing-bird 98149a5d739b3baa777128f617531ce8b654d24502a7e151244cc5b7597667bc witness ArmoredWitness-rough-wind ea31934afb8632958de2fb37dd9bfabb8dc7961dea67a6ae4c57f1a1ca26eef7 witness ArmoredWitness-dry-sunset 03f38be7ab7f1081be393a9e69dd594d9a184a0eef36b0a1ab6f7a7f05beffc3 witness ArmoredWitness-nameless-firefly 075189980cc1388fa8686c7432028812de3182e257e219463f7cf28d49d573dd witness ArmoredWitness-floral-sky e90299398a4d39d030da888a0923ecf16786881ac12243db73c9f0cf2a2d80e6 group GoogleTrustFabric 8 ArmoredWitness-falling-pondArmoredWitness-weathered-rain ArmoredWitness-wispy-wood ArmoredWitness-small-breeze ArmoredWitness-quiet-wood ArmoredWitness-morning-darkness ArmoredWitness-shy-wind ArmoredWitness-hidden-river ArmoredWitness-autumn-wood ArmoredWitness-snowy-sound ArmoredWitness-throbbing-bird ArmoredWitness-rough-wind ArmoredWitness-dry-sunset ArmoredWitness-nameless-firefly ArmoredWitness-floral-sky
quorum GoogleTrustFabricThis is not listed on www.sigsum.org yet. For the script I ran and did a bit of cut-and-paste from to extract the appropriate public keys, see:
https://www.rgdd.se/volatile/aw-config-Rasmus
group demo-quorum-rule all poc.sigsum.org/nisse rgdd.se/poc-witness quorum demo-quorum-rule EOF
Run a command like this to verify downloaded artifacts:
sigsum-verify -k inetutils-sigsum-key.pub \ -p inetutils-sigsum-trust-policy.txt \ inetutils-2.6.tar.gz.proof < inetutils-2.6.tar.gz
You may learn more about Sigsum concepts and find instructions how to download the tools here: https://www.sigsum.org/getting-started/
This release is based on the inetutils git repository, available as
git clone https://git.savannah.gnu.org/git/inetutils.git
with commit 346d839db35faa4beb755edfa3b962c87005fcb5 tagged as v2.6.
For a summary of changes and contributors, see:
https://git.sv.gnu.org/gitweb/?p=inetutils.git;a=shortlog;h=v2.6
or run this command from a git-cloned inetutils directory:
git shortlog v2.5..v2.6
This release was bootstrapped with the following tools: Gnulib 2025-01-02 e7d6a9e033ff82d5bd7f001d6d1a17bd6cc9607c Autoconf 2.71 Automake 1.16.5 Bison 3.8.2 M4 1.4.19 Makeinfo 7.1.1 Help2man 1.49.2 Make 4.3 Gzip 1.13 Tar 1.34 Guix 831b94a1efcea8f793afc949b5123a6235c9bb1a
NEWS
- Noteworthy changes in release 2.6 (2025-01-07) [stable]
...
Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
On Wed, Jan 08, 2025 at 02:33:28PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
What you have in the current template looks as good as it gets right now!
Thank you!
Avoiding the ugly Unix-specific 'cat<<EOF>' garbage was the primary thing I was thinking about. Maybe the public key can be taken on the command line as strings?
That's a question for nisse -- can you file an issue and tag him?
https://git.glasklar.is/sigsum/core/sigsum-go/-/issues
What we discussed so far with Filippo to shrink it:
**Named trust policies.** So that you would only have to say here are my Sigsum key(s) and they should be used with "Debian's trust policy", "the builtin default policy", etc. A key-line might look like this:
sigsum_policy="builtin" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM1WpnEswJLPzvXJDiswowy48U+G+G1kmgwUE2eaRHZG
With the idea that it should be possible to specify either the default, or to override it by, e.g., using the policy an apt-package installed.
Or maybe saying nothing implies builtin, and there is a way to override it with the sigsum_policy option as shown above. This is all work in progress ideas that we have yet to hash out (but you might get the idea), so if you have any feedback or related ideas to explore shoot!
I would prefer if tools used a system-installed /etc/sigsum/trust-policy.conf file with options to disable and/or override and use a user-provided trust file.
Something like this is what we want to facilitate.
Please don't hard wire magic crypto values into the binary, it smells of TPM's.
The argument for having the option of using a builtin default-policy is that a user *somehow* got sigsum-verify installed and must trust the tool. By embedding a default policy, a separate trusted channel for getting it installed is avoided (so there are fewer moving parts).
It's still in the idea phase though, so if you have more arguments for why it's a terrible idea now is a great time to elaborate on them!
Another idea is to use named self-integrity-protected trust policies like this:
cat <<EOF > inetutils-sigsum-trust-policy.txt log 154f49976b59ff09a123675f58cb3e346e0455753c3c3b15d465dcb4f6512b0b https://poc.sigsum.org/jellyfish witness poc.sigsum.org/nisse 1c25f8a44c635457e2e391d1efbca7d4c2951a0aef06225a881e46b98962ac6c witness rgdd.se/poc-witness 28c92a5a3a054d317c86fc2eeb6a7ab2054d6217100d0be67ded5b74323c5806 group demo-quorum-rule all poc.sigsum.org/nisse rgdd.se/poc-witness quorum demo-quorum-rule EOF
sha256sum inetutils-sigsum-trust-policy.txt => 72af4399354bc7803a540999c27d249493f8fd00e74414e0de79e692260df635 inetutils-sigsum-trust-policy.txt
Then that file could be provided in
/etc/sigsum/trust-policy.d/72af4399354bc7803a540999c27d249493f8fd00e74414e0de79e692260df635.conf
and the user could run something like this:
sigsum-verify --signing-key "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE" \ --trust-policy-hash 72af4399354bc7803a540999c27d249493f8fd00e74414e0de79e692260df635 \ inetutils-2.6.tar.gz.proof < inetutils-2.6.tar.gz
Assuming the system installed this particular trust policy during installation. This avoids you "blessing" any particular trust policy, but move this on to users.
This idea hasn't been up for discussion yet, thanks for sharing it. I'll put a link to this email in tomorrow's Sigsum weekly notes!
-Rasmus
But basically, I'd like to not force the very long trust policy blurbs in everyones READMEs. And to have named trust policies to pick from.
+1
**Better primer page for users.** So, basically something similar to www.so/getting-started; but targeted solely for users that want to use sigsum-verify rather than getting a full demo of the entire system.
+1
We probably also want a primer page that can be linked for the type of verification Sigsum facilitates from a 3rd-party perspective; and we should probably have a separate page dedicated for release-signing. If we had that, you could probably get away with one sentence + link.
+1
(I posted some more in-line comments further down in the template.)
Btw, I plan to use my OpenPGP authentication key (i.e., not the signature key) from my Gnuk hardware dongle, exported via GnuPG's SSH agent, for use by sigsum-submit --signing-key to create *.proof. Does anyone see a problem with this? I don't know how to make my OpenPGP signature key from the Gnuk available via the SSH agent easily, has anyone done that? I haven't thought through the flow here. The threat I'm worried about is if some remote SSH server abuse my setup to make me sign some blob that may later be submitted to the Sigsum transparency log as a release signature? Is there sufficient domain context separation happening here? It doesn't feel intuitively safe.
/Simon
... Here is the GNU inetutils home page: https://gnu.org/s/inetutils/
Here are the compressed sources: https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.gz (2.9MB) https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.xz (1.7MB)
Here are the GPG detached signatures: https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.gz.sig https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.xz.sig
Here is minimal source-only "git archive" sources: https://ftpmirror.gnu.org/inetutils/inetutils-v2.6-src.tar.gz (820kB)
Here are Sigsum Proofs: https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.gz.proof https://ftpmirror.gnu.org/inetutils/inetutils-2.6.tar.xz.proof https://ftpmirror.gnu.org/inetutils/inetutils-v2.6-src.tar.gz.proof
Use a mirror for higher download bandwidth: https://www.gnu.org/order/ftp.html
Here are the SHA1 and SHA256 checksums:
ced45165aeda8a9584d291b81225d86be82e1a90 inetutils-2.6.tar.gz gra2UqTds+E0rwII1iW38faAJn3igu5Wau60BvaI+HI= inetutils-2.6.tar.gz a6576bacd408adf93017f44d35608f05c893c5d5 inetutils-2.6.tar.xz YuriPIWQhNnJci9Nu+NnddrLnPDbwVXaQ3AEnkl2OCM= inetutils-2.6.tar.xz
Verify the base64 SHA256 checksum with cksum -a sha256 --check from coreutils-9.2 or OpenBSD's cksum since 2007.
Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this:
gpg --verify inetutils-2.6.tar.gz.sig
The signature should match the fingerprint of the following key:
pub ed25519 2019-03-20 [SC] B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE uid Simon Josefsson simon@josefsson.org
If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command.
gpg --locate-external-key simon@josefsson.org
gpg --recv-keys 51722B08FE4745A2
wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=inetutils&dow...' | gpg --import -
As a last resort to find the key, you can try the official GNU keyring:
wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg gpg --keyring gnu-keyring.gpg --verify inetutils-2.6.tar.gz.sig
Use the .proof file to verify the Sigsum proof. These files are like signatures with extra transparency: you can cryptographically verify that every proof is logged in a public append-only log, so you can say with confidence what signatures exists. This helps to protect against secret (targetted and/or malicious) releases.
If you want some inspiration for why the above paragraph is true:
https://git.glasklar.is/rgdd/age-release-verify
I'd love to see a similar prototype for your use-case!
Our releases are Sigsum signed with the following public key:
cat <<EOF > inetutils-sigsum-key.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE EOF
You may use the following Sigsum verification policy:
cat <<EOF > inetutils-sigsum-trust-policy.txt log 154f49976b59ff09a123675f58cb3e346e0455753c3c3b15d465dcb4f6512b0b https://poc.sigsum.org/jellyfish
Jellyfish is a prototype log -- I'd recommend that you use seasalp, Glasklar's production log. See https://www.sigsum.org/services/.
witness poc.sigsum.org/nisse 1c25f8a44c635457e2e391d1efbca7d4c2951a0aef06225a881e46b98962ac6c witness rgdd.se/poc-witness 28c92a5a3a054d317c86fc2eeb6a7ab2054d6217100d0be67ded5b74323c5806
These test/prototype witnesses are not available for seasalp. Glasklar isn't running a stable witness yet (ln5 is working on fixing that the coming weeks; I'm also told a few other organizations are looking to start running witnesses). The witness cosignatures that you see on
https://seasalp.glasklar.is/get-tree-headare all from Google TrustFabric's witness which runs from 15 different vantage points. I'd suggest using a majority policy (8/15 cosignatures). Such a policy for seasalp would look like this:
log 0ec7e16843119b120377a73913ac6acbc2d03d82432e2c36b841b09a95841f25 https://seasalp.glasklar.is witness ArmoredWitness-falling-pond 54c4862caba4ef942fe1abc6afb65d63cba0a55d3e6313ff59154b8586d882e2 witness ArmoredWitness-weathered-rain 62db94aa7926e8b2ae0461e9ebf69cd2795c077eb1cfe63360f61d6fdbe1de52 witness ArmoredWitness-wispy-wood 456f659e0b0efa658e3a2895e2775a7c6754ae09d5842241bb603d649517068f witness ArmoredWitness-small-breeze 00166295237c618f42258e82deac2d66a9d0ff6b54e7be39fbb6b8d65b3b8143 witness ArmoredWitness-quiet-wood 9b71799be731b15fe9b54f37cd6f22f9499d3e3309dabcb588bf82e234844913 witness ArmoredWitness-morning-darkness 7ba003654674398b62dd70ab369a3f750a48670354d66f79125827514a0b9fbd witness ArmoredWitness-shy-wind 198bed2687bcf60fc246eae3583f2a9764287ece65aa1aa9f2b6b04a1628be1d witness ArmoredWitness-hidden-river dae934c7cc1f45ba898a3dfe1265d492a6c58405ddec143fc16f84a0f588e3a5 witness ArmoredWitness-autumn-wood eb085426da77b81b534ec99c0e987d90f4aa0e01d5cf31178212767b7dbe38a9 witness ArmoredWitness-snowy-sound 0b85b9d46ccbd1cfa78a19b04f8fc4359538390c9d82675e89d2433217aaad50 witness ArmoredWitness-throbbing-bird 98149a5d739b3baa777128f617531ce8b654d24502a7e151244cc5b7597667bc witness ArmoredWitness-rough-wind ea31934afb8632958de2fb37dd9bfabb8dc7961dea67a6ae4c57f1a1ca26eef7 witness ArmoredWitness-dry-sunset 03f38be7ab7f1081be393a9e69dd594d9a184a0eef36b0a1ab6f7a7f05beffc3 witness ArmoredWitness-nameless-firefly 075189980cc1388fa8686c7432028812de3182e257e219463f7cf28d49d573dd witness ArmoredWitness-floral-sky e90299398a4d39d030da888a0923ecf16786881ac12243db73c9f0cf2a2d80e6 group GoogleTrustFabric 8 ArmoredWitness-falling-pondArmoredWitness-weathered-rain ArmoredWitness-wispy-wood ArmoredWitness-small-breeze ArmoredWitness-quiet-wood ArmoredWitness-morning-darkness ArmoredWitness-shy-wind ArmoredWitness-hidden-river ArmoredWitness-autumn-wood ArmoredWitness-snowy-sound ArmoredWitness-throbbing-bird ArmoredWitness-rough-wind ArmoredWitness-dry-sunset ArmoredWitness-nameless-firefly ArmoredWitness-floral-sky
quorum GoogleTrustFabricThis is not listed on www.sigsum.org yet. For the script I ran and did a bit of cut-and-paste from to extract the appropriate public keys, see:
https://www.rgdd.se/volatile/aw-config-Rasmus
group demo-quorum-rule all poc.sigsum.org/nisse rgdd.se/poc-witness quorum demo-quorum-rule EOF
Run a command like this to verify downloaded artifacts:
sigsum-verify -k inetutils-sigsum-key.pub \ -p inetutils-sigsum-trust-policy.txt \ inetutils-2.6.tar.gz.proof < inetutils-2.6.tar.gz
You may learn more about Sigsum concepts and find instructions how to download the tools here: https://www.sigsum.org/getting-started/
This release is based on the inetutils git repository, available as
git clone https://git.savannah.gnu.org/git/inetutils.git
with commit 346d839db35faa4beb755edfa3b962c87005fcb5 tagged as v2.6.
For a summary of changes and contributors, see:
https://git.sv.gnu.org/gitweb/?p=inetutils.git;a=shortlog;h=v2.6
or run this command from a git-cloned inetutils directory:
git shortlog v2.5..v2.6
This release was bootstrapped with the following tools: Gnulib 2025-01-02 e7d6a9e033ff82d5bd7f001d6d1a17bd6cc9607c Autoconf 2.71 Automake 1.16.5 Bison 3.8.2 M4 1.4.19 Makeinfo 7.1.1 Help2man 1.49.2 Make 4.3 Gzip 1.13 Tar 1.34 Guix 831b94a1efcea8f793afc949b5123a6235c9bb1a
NEWS
- Noteworthy changes in release 2.6 (2025-01-07) [stable]
...
Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
On Wed, Jan 08, 2025 at 02:33:28PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
What you have in the current template looks as good as it gets right now!
Thank you!
Avoiding the ugly Unix-specific 'cat<<EOF>' garbage was the primary thing I was thinking about. Maybe the public key can be taken on the command line as strings?
That's a question for nisse -- can you file an issue and tag him?
I opened this one:
https://git.glasklar.is/sigsum/core/sigsum-go/-/issues/90
Please don't hard wire magic crypto values into the binary, it smells of TPM's.
The argument for having the option of using a builtin default-policy is that a user *somehow* got sigsum-verify installed and must trust the tool. By embedding a default policy, a separate trusted channel for getting it installed is avoided (so there are fewer moving parts).
It's still in the idea phase though, so if you have more arguments for why it's a terrible idea now is a great time to elaborate on them!
My argument would be to draw an analogy with hard-coding the content of the /etc/ssl ca-certificates into binaries. Or hard-coding the public keys of the DNSSEC root trust anchors.
I believe you can still provide a builtin default-policy, if you want to, by including a default trust policy together with sigsum-verify, and have the installation process put that in the right place so the tool finds it automatically.
Yes, I believe you still can make a reasonable argument why hard-coding things in the binary is better, but I think for the majority of distribution-like use-cases it is better not to do this. It is a trade-off of different requirements.
/Simon
Simon Josefsson simon@josefsson.org writes:
I believe you can still provide a builtin default-policy, if you want to, by including a default trust policy together with sigsum-verify, and have the installation process put that in the right place so the tool finds it automatically.
If the install process is `go install sigsum.org/sigsum-go@vx.y.z` I don't think there's any way to get auxilliary files installed?
One could potentially embed the data (or hash of data + url) in some executable, but not use that directly. But have users do something like `go run sigsum.org/sigsum-go/cmd/sigsum-install@vx.y.z ...` to install default policies somewhere in /etc or $HOME, depending on privileges and command line arguments.
Or we could try to discourage this way of using te go tools to isntall sigsum (and instead advertise some method that verifies our release signatures), but I suspect that will be a bit futile.
Regards, /Niels
On Mon, Jan 13, 2025 at 02:49:37PM +0100, Niels Möller wrote:
Simon Josefsson simon@josefsson.org writes:
I believe you can still provide a builtin default-policy, if you want to, by including a default trust policy together with sigsum-verify, and have the installation process put that in the right place so the tool finds it automatically.
If the install process is `go install sigsum.org/sigsum-go@vx.y.z` I don't think there's any way to get auxilliary files installed?
One could potentially embed the data (or hash of data + url) in some executable, but not use that directly. But have users do something like
This is how I thought Go's tool chain works when changing version, e.g., something like this:
go install golang.org/dl/go1.22.0@latest go1.22.0 download
And I expected that the "downloader program" would know the hash of what it downloads and installs. But it seems it just reads the .sha256 file?
https://cs.opensource.google/go/dl/+/master:internal/version/version.go;l=14...
I'm probably missing something obvious.
But I think you're right that it would be possible to create an installer that knows how to install the tools and associated policies.
`go run sigsum.org/sigsum-go/cmd/sigsum-install@vx.y.z ...` to install default policies somewhere in /etc or $HOME, depending on privileges and command line arguments.
Or we could try to discourage this way of using te go tools to isntall sigsum (and instead advertise some method that verifies our release signatures), but I suspect that will be a bit futile.
Agreed.
-Rasmus
On Mon, Jan 13, 2025 at 02:17:38PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
On Wed, Jan 08, 2025 at 02:33:28PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
What you have in the current template looks as good as it gets right now!
Thank you!
Avoiding the ugly Unix-specific 'cat<<EOF>' garbage was the primary thing I was thinking about. Maybe the public key can be taken on the command line as strings?
That's a question for nisse -- can you file an issue and tag him?
I opened this one:
Thanks!
Please don't hard wire magic crypto values into the binary, it smells of TPM's.
The argument for having the option of using a builtin default-policy is that a user *somehow* got sigsum-verify installed and must trust the tool. By embedding a default policy, a separate trusted channel for getting it installed is avoided (so there are fewer moving parts).
It's still in the idea phase though, so if you have more arguments for why it's a terrible idea now is a great time to elaborate on them!
My argument would be to draw an analogy with hard-coding the content of the /etc/ssl ca-certificates into binaries. Or hard-coding the public keys of the DNSSEC root trust anchors.
I believe you can still provide a builtin default-policy, if you want to, by including a default trust policy together with sigsum-verify, and have the installation process put that in the right place so the tool finds it automatically.
Yes, I believe you still can make a reasonable argument why hard-coding things in the binary is better, but I think for the majority of distribution-like use-cases it is better not to do this. It is a trade-off of different requirements.
I agree that when sigsum-verify comes from a dist., e.g. apt-install sigsum-go, then it makes more sense to get the policy from either the sigsum-go package or a related installed package with just the policy!
-Rasmus
Rasmus Dahlberg rgdd@glasklarteknik.se writes:
I'd suggest using a majority policy (8/15 cosignatures). Such a policy for seasalp would look like this:
Implications of such a policy (if employed by both monitors and verifiers, and if we don't want to rely on additional checks on the monitor side) is that an attacker can publish split views without detection, if the attacker is able to compromise the log itself, and *one* of the listed witness devices. (Each view is shown to 7 of the honest witnesses, which will then cosign it. While the compromised device cosigns *both* views, and then each view will carry 8 valid cosignatures).
To be sensitive to an attack compromising log + a single device may sound bad, but it could make good sense under the theory that the easiest attack on the armored witnesses is via compromise of its software updates, and that kind of attack could just as easily compromise them all as only one device.
Bottomline: I agree such a policy is a reasonable starting point.
Regards, /Niels
On Thu, Jan 09, 2025 at 08:46:09AM +0100, Niels Möller wrote:
Rasmus Dahlberg rgdd@glasklarteknik.se writes:
I'd suggest using a majority policy (8/15 cosignatures). Such a policy for seasalp would look like this:
Implications of such a policy (if employed by both monitors and verifiers, and if we don't want to rely on additional checks on the monitor side) is that an attacker can publish split views without detection, if the attacker is able to compromise the log itself, and *one* of the listed witness devices. (Each view is shown to 7 of the honest witnesses, which will then cosign it. While the compromised device cosigns *both* views, and then each view will carry 8 valid cosignatures).
We're talking about the user's sigsum-verify policy, not how the monitor should behave when given the same policy (which is different).
-Rasmus
To be sensitive to an attack compromising log + a single device may sound bad, but it could make good sense under the theory that the easiest attack on the armored witnesses is via compromise of its software updates, and that kind of attack could just as easily compromise them all as only one device.
Bottomline: I agree such a policy is a reasonable starting point.
Regards, /Niels
Hi
The primary remaining blocker for me is what trust policy to include in the release notes. I'm beginning to feel that whatever goes into the announcement, users are best advised to make their own additional considerations that depends on current knowledge over time.
Still, it would be nice to include a minimal trust policy that is likely to continue to work and at least provide some security advantage for the user. What is the best trade-off right now? Having 25+ lines of policy hashes in the announcements breaks my readability standards, although I would be okay with a 3/5 policy.
Or would you rather not include any trust policy at all, and simply deferring this to your instructions? That would leave the release notes rather inconclusive though.
Another alternative is to add an indirection like:
wget -Oinetutils-sigsum-trust-policy.txt https://sigsum.org/FOO
or
wget https://ftp.gnu.org/gnu/inetutils/inetutils-sigsum-trust-policy.txt
Do you have any objection to the following text snippet? What could you suggest as improvement? I picked 5 AW witnesses from your list.
--- You may use the following Sigsum verification policy as a starting point. You are advised to follow Sigsum operational best practices and revise this going forward, see: https://www.sigsum.org/services/
cat <<EOF > inetutils-sigsum-trust-policy.txt log 0ec7e16843119b120377a73913ac6acbc2d03d82432e2c36b841b09a95841f25 https://seasalp.glasklar.is witness AW-1 54c4862caba4ef942fe1abc6afb65d63cba0a55d3e6313ff59154b8586d882e2 witness AW-2 7ba003654674398b62dd70ab369a3f750a48670354d66f79125827514a0b9fbd witness AW-3 ea31934afb8632958de2fb37dd9bfabb8dc7961dea67a6ae4c57f1a1ca26eef7 witness AW-4 03f38be7ab7f1081be393a9e69dd594d9a184a0eef36b0a1ab6f7a7f05beffc3 witness AW-5 e90299398a4d39d030da888a0923ecf16786881ac12243db73c9f0cf2a2d80e6 group GTF 3 AW-1 AW-2 AW-3 AW-4 AW-5 quorum GTF EOF ---
Wouldn't it be more reliable to include two different logs, possibly with 2/3 witnesses each? Having a single point of control on the 'seasalp.glasklar.is' domain name seems like a serious problem to me. Hard-coding IP addresses? Tor onion name?
Can I specify a quorum group requiring inclusion into two different logs with one witness each? Is there an example of a trust policy with multiple logs, and multiple witness from each, and some quorum setting? Can one witness validate multiple logs? Maybe a nice idea is to require 2/3 witness from two different logs where one of the witnesses is the same for both logs, to allow some cross-log witnessing.
/Simon
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
You may use the following Sigsum verification policy:
cat <<EOF > inetutils-sigsum-trust-policy.txt log 154f49976b59ff09a123675f58cb3e346e0455753c3c3b15d465dcb4f6512b0b https://poc.sigsum.org/jellyfish
Jellyfish is a prototype log -- I'd recommend that you use seasalp, Glasklar's production log. See https://www.sigsum.org/services/.
witness poc.sigsum.org/nisse 1c25f8a44c635457e2e391d1efbca7d4c2951a0aef06225a881e46b98962ac6c witness rgdd.se/poc-witness 28c92a5a3a054d317c86fc2eeb6a7ab2054d6217100d0be67ded5b74323c5806
These test/prototype witnesses are not available for seasalp. Glasklar isn't running a stable witness yet (ln5 is working on fixing that the coming weeks; I'm also told a few other organizations are looking to start running witnesses). The witness cosignatures that you see on
https://seasalp.glasklar.is/get-tree-headare all from Google TrustFabric's witness which runs from 15 different vantage points. I'd suggest using a majority policy (8/15 cosignatures). Such a policy for seasalp would look like this:
log 0ec7e16843119b120377a73913ac6acbc2d03d82432e2c36b841b09a95841f25 https://seasalp.glasklar.is witness ArmoredWitness-falling-pond 54c4862caba4ef942fe1abc6afb65d63cba0a55d3e6313ff59154b8586d882e2 witness ArmoredWitness-weathered-rain 62db94aa7926e8b2ae0461e9ebf69cd2795c077eb1cfe63360f61d6fdbe1de52 witness ArmoredWitness-wispy-wood 456f659e0b0efa658e3a2895e2775a7c6754ae09d5842241bb603d649517068f witness ArmoredWitness-small-breeze 00166295237c618f42258e82deac2d66a9d0ff6b54e7be39fbb6b8d65b3b8143 witness ArmoredWitness-quiet-wood 9b71799be731b15fe9b54f37cd6f22f9499d3e3309dabcb588bf82e234844913 witness ArmoredWitness-morning-darkness 7ba003654674398b62dd70ab369a3f750a48670354d66f79125827514a0b9fbd witness ArmoredWitness-shy-wind 198bed2687bcf60fc246eae3583f2a9764287ece65aa1aa9f2b6b04a1628be1d witness ArmoredWitness-hidden-river dae934c7cc1f45ba898a3dfe1265d492a6c58405ddec143fc16f84a0f588e3a5 witness ArmoredWitness-autumn-wood eb085426da77b81b534ec99c0e987d90f4aa0e01d5cf31178212767b7dbe38a9 witness ArmoredWitness-snowy-sound 0b85b9d46ccbd1cfa78a19b04f8fc4359538390c9d82675e89d2433217aaad50 witness ArmoredWitness-throbbing-bird 98149a5d739b3baa777128f617531ce8b654d24502a7e151244cc5b7597667bc witness ArmoredWitness-rough-wind ea31934afb8632958de2fb37dd9bfabb8dc7961dea67a6ae4c57f1a1ca26eef7 witness ArmoredWitness-dry-sunset 03f38be7ab7f1081be393a9e69dd594d9a184a0eef36b0a1ab6f7a7f05beffc3 witness ArmoredWitness-nameless-firefly 075189980cc1388fa8686c7432028812de3182e257e219463f7cf28d49d573dd witness ArmoredWitness-floral-sky e90299398a4d39d030da888a0923ecf16786881ac12243db73c9f0cf2a2d80e6 group GoogleTrustFabric 8 ArmoredWitness-falling-pondArmoredWitness-weathered-rain ArmoredWitness-wispy-wood ArmoredWitness-small-breeze ArmoredWitness-quiet-wood ArmoredWitness-morning-darkness ArmoredWitness-shy-wind ArmoredWitness-hidden-river ArmoredWitness-autumn-wood ArmoredWitness-snowy-sound ArmoredWitness-throbbing-bird ArmoredWitness-rough-wind ArmoredWitness-dry-sunset ArmoredWitness-nameless-firefly ArmoredWitness-floral-sky
quorum GoogleTrustFabricThis is not listed on www.sigsum.org yet. For the script I ran and did a bit of cut-and-paste from to extract the appropriate public keys, see:
https://www.rgdd.se/volatile/aw-config
Simon Josefsson simon@josefsson.org writes:
Do you have any objection to the following text snippet? What could you suggest as improvement? I picked 5 AW witnesses from your list.
It's a bit unclear to me what reliability to expect from the AW witnesses, but it makes sense to me as a starting point.
And as usual, availability of logs and witnesses matters at the time that you need to make a new release. It doesn't matter at all at verificatino time, since that's offline.
Maybe with a somewhat more verbose name for the GTF group (I guess it's an abbreviation for google trust fabric, but I guess that's unobvious to users).
Wouldn't it be more reliable to include two different logs, possibly with 2/3 witnesses each? Having a single point of control on the 'seasalp.glasklar.is' domain name seems like a serious problem to me. Hard-coding IP addresses? Tor onion name?
It would be good to have additional logs, for reliability. But as far as I'm aware, for now seasalp is the only available one with any intention to operate reliably.
Adding a tor onion address is certainly doable, but it's not entirely clear to me what benefits you get; the log is authenticated using its key, so what you'd protect against is attacks on the DNS lookup or attacks on routing or ip-based filtering somewhere in the middle of the routing path?
Can I specify a quorum group requiring inclusion into two different logs with one witness each? Is there an example of a trust policy with multiple logs, and multiple witness from each, and some quorum setting? Can one witness validate multiple logs?
When adding multiple logs to the policy, the semantics is that any of them is fine. Verifier accepts any of them, submitters submit to a randomly selected available log, and monitors should monitor *all* the listed logs.
And the expectation is that you would have more or less the same set of witnesses cosigning all logs in your policy. We'll put that to the test for the next log that someone wants top operate, and which we'd then like to be witnessed by both AW and by the glasklar witness that should materialize soon.
The same quorum in the policy applies regardless of which log was used. If we used a separate quorum for each log, I think that would make analysis of split view attacks a lot harier.
Regards, /Niels
Thanks for help!
Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
Simon Josefsson simon@josefsson.org writes:
Do you have any objection to the following text snippet? What could you suggest as improvement? I picked 5 AW witnesses from your list.
It's a bit unclear to me what reliability to expect from the AW witnesses, but it makes sense to me as a starting point.
And as usual, availability of logs and witnesses matters at the time that you need to make a new release. It doesn't matter at all at verificatino time, since that's offline.
So then shouldn't my trust policy be 'all' rather than a 3/5 setup? Assuming all of witnesses are online when doing 'sigsum-submit' as part of the release. I used a 'group ... 3 ...' statement now.
Maybe with a somewhat more verbose name for the GTF group (I guess it's an abbreviation for google trust fabric, but I guess that's unobvious to users).
Does it convey anything meaningful to the user? I prefer avoiding avoidable advertising.
Wouldn't it be more reliable to include two different logs, possibly with 2/3 witnesses each? Having a single point of control on the 'seasalp.glasklar.is' domain name seems like a serious problem to me. Hard-coding IP addresses? Tor onion name?
It would be good to have additional logs, for reliability. But as far as I'm aware, for now seasalp is the only available one with any intention to operate reliably.
How hard is it to operate? Maybe I could set one up too, for experimentation...
Adding a tor onion address is certainly doable, but it's not entirely clear to me what benefits you get; the log is authenticated using its key, so what you'd protect against is attacks on the DNS lookup or attacks on routing or ip-based filtering somewhere in the middle of the routing path?
Perhaps I was just confused -- maybe the DNS name is not looked up during verification? I was worried about that DNS name going away.
Can I specify a quorum group requiring inclusion into two different logs with one witness each? Is there an example of a trust policy with multiple logs, and multiple witness from each, and some quorum setting? Can one witness validate multiple logs?
When adding multiple logs to the policy, the semantics is that any of them is fine. Verifier accepts any of them, submitters submit to a randomly selected available log, and monitors should monitor *all* the listed logs.
And the expectation is that you would have more or less the same set of witnesses cosigning all logs in your policy. We'll put that to the test for the next log that someone wants top operate, and which we'd then like to be witnessed by both AW and by the glasklar witness that should materialize soon.
The same quorum in the policy applies regardless of which log was used. If we used a separate quorum for each log, I think that would make analysis of split view attacks a lot harier.
Okay. Would it meaningful for a client to (be able to) require that something was submitted to two different logs?
/Simon
Simon Josefsson simon@josefsson.org writes:
And as usual, availability of logs and witnesses matters at the time that you need to make a new release. It doesn't matter at all at verificatino time, since that's offline.
So then shouldn't my trust policy be 'all' rather than a 3/5 setup? Assuming all of witnesses are online when doing 'sigsum-submit' as part of the release. I used a 'group ... 3 ...' statement now.
I think it is desirable if the policy you distribute now can be used to verify your *next* release too. And with "all" you'd get in trouble if one of those witness devices is offline at that time.
Maybe with a somewhat more verbose name for the GTF group (I guess it's an abbreviation for google trust fabric, but I guess that's unobvious to users).
Does it convey anything meaningful to the user? I prefer avoiding avoidable advertising.
It says that the utility of those witnesses (and the policy) depends on Google (the operator(*) of all witnesses in the policy) behaving properly. You could think about that in two ways:
* Either it's unavoidable advertising... since you are endorsing that policy, that implies that you think the policy has some utility, and hence that you want to express some level of trust in the witness operator.
* Or you can think about it as a statement of conditional utility: You say that the policy has utility only for those users willing to have some level of trust in the witness operator doing the right thing.
But in either case, I think it is meaningful for users to know about. And it will clearly be an improvement when we have more production witnesses online.
(*) one could maybe debate whether or not the AW witnesses are "operated" by Google; the devices are operated physically by selected individuals, as I understand it, but both selection of those individuals, and the software updates for the devices, is controlled by the Google folks.
It would be good to have additional logs, for reliability. But as far as I'm aware, for now seasalp is the only available one with any intention to operate reliably.
How hard is it to operate? Maybe I could set one up too, for experimentation...
Somewhere strictly between "trivial" and "extraordinary difficult"... For redundancy, you need two machines (and some rough understanding of the fail-over procedures). Each machine needs our log server software + trillian + mysql (we have some ansible stuff to help set that up). And you need to think about how you want to manage the log's private key, there's documentation on how we do that, using multiple yubihsm and physical safes, which is a bit cumbersome and expensive.
If it's for experiments, you can simplify that a bit with a single node and cleartext key on disk (which is how we run poc.sigsum.org/jellyfish). That's still not trivial, but rather easy.
If you are able to operate a production service (say, you're aiming to keep it running for two years, with downtime at most a few days at a time), I think at this time, an additional witness would be more valuable than an additional log.
Perhaps I was just confused -- maybe the DNS name is not looked up during verification? I was worried about that DNS name going away.
It's not needed by the verifier. It is needed by a monitor, which is why I'd suggest you include it in the policy file, even though it's syntactically optional.
Okay. Would it meaningful for a client to (be able to) require that something was submitted to two different logs?
Generally, no. I can see hypothetical scnarios where it could make sense, e.g., if you want to require both group A and group B of witnesses to cosign releases, but those witnesses for some reason don't witness the same logs. Then you could distribute two separate proofs of logging, verify them against separate policies, and require that both proofs are valid. And those semantics would have to be built on top of current tools.
(We might end up with some of those complexities in our tooling, if we want to have multiple versions of policies, which policy to apply depending on the time the proof was made, or by which submission key, but that's still all very open).
Regards, /Niels
Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
Simon Josefsson simon@josefsson.org writes:
And as usual, availability of logs and witnesses matters at the time that you need to make a new release. It doesn't matter at all at verificatino time, since that's offline.
So then shouldn't my trust policy be 'all' rather than a 3/5 setup? Assuming all of witnesses are online when doing 'sigsum-submit' as part of the release. I used a 'group ... 3 ...' statement now.
I think it is desirable if the policy you distribute now can be used to verify your *next* release too. And with "all" you'd get in trouble if one of those witness devices is offline at that time.
Okay, I think I'm slowly grasping concepts here. What we seem to want is release announcements to contain Sigsum public keys and trust policies, and ideally for those to stay identical between releases to allow users to check if two consequetive releases are using the same details. This matches the semantics for PGP public keys, so it make some sense. These instructions are for humans and not machines, so sometimes key rollover and trust policies can change if a human-readable explanation is present.
It would be nice to have some machine readable mechanism too, and even nicer if they are similar.
Maybe with a somewhat more verbose name for the GTF group (I guess it's an abbreviation for google trust fabric, but I guess that's unobvious to users).
Does it convey anything meaningful to the user? I prefer avoiding avoidable advertising.
It says that the utility of those witnesses (and the policy) depends on Google (the operator(*) of all witnesses in the policy) behaving properly. You could think about that in two ways:
Either it's unavoidable advertising... since you are endorsing that policy, that implies that you think the policy has some utility, and hence that you want to express some level of trust in the witness operator.
Or you can think about it as a statement of conditional utility: You say that the policy has utility only for those users willing to have some level of trust in the witness operator doing the right thing.
But in either case, I think it is meaningful for users to know about. And it will clearly be an improvement when we have more production witnesses online.
(*) one could maybe debate whether or not the AW witnesses are "operated" by Google; the devices are operated physically by selected individuals, as I understand it, but both selection of those individuals, and the software updates for the devices, is controlled by the Google folks.
Okay. This seems like a slippery slope towards running my own witness and/or log. I feel a bit uncomfortable using some yet not announced set of servers for long-term verification.
It would be good to have additional logs, for reliability. But as far as I'm aware, for now seasalp is the only available one with any intention to operate reliably.
How hard is it to operate? Maybe I could set one up too, for experimentation...
Somewhere strictly between "trivial" and "extraordinary difficult"... For redundancy, you need two machines (and some rough understanding of the fail-over procedures). Each machine needs our log server software + trillian + mysql (we have some ansible stuff to help set that up). And you need to think about how you want to manage the log's private key, there's documentation on how we do that, using multiple yubihsm and physical safes, which is a bit cumbersome and expensive.
If it's for experiments, you can simplify that a bit with a single node and cleartext key on disk (which is how we run poc.sigsum.org/jellyfish). That's still not trivial, but rather easy.
If you are able to operate a production service (say, you're aiming to keep it running for two years, with downtime at most a few days at a time), I think at this time, an additional witness would be more valuable than an additional log.
Perhaps I was just confused -- maybe the DNS name is not looked up during verification? I was worried about that DNS name going away.
It's not needed by the verifier. It is needed by a monitor, which is why I'd suggest you include it in the policy file, even though it's syntactically optional.
Okay. Would it meaningful for a client to (be able to) require that something was submitted to two different logs?
Generally, no. I can see hypothetical scnarios where it could make sense, e.g., if you want to require both group A and group B of witnesses to cosign releases, but those witnesses for some reason don't witness the same logs. Then you could distribute two separate proofs of logging, verify them against separate policies, and require that both proofs are valid. And those semantics would have to be built on top of current tools.
(We might end up with some of those complexities in our tooling, if we want to have multiple versions of policies, which policy to apply depending on the time the proof was made, or by which submission key, but that's still all very open).
Thanks for explaining!
/Simon
On Mon, Jan 13, 2025 at 02:37:11PM +0100, Simon Josefsson wrote:
Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
Simon Josefsson simon@josefsson.org writes:
And as usual, availability of logs and witnesses matters at the time that you need to make a new release. It doesn't matter at all at verificatino time, since that's offline.
So then shouldn't my trust policy be 'all' rather than a 3/5 setup? Assuming all of witnesses are online when doing 'sigsum-submit' as part of the release. I used a 'group ... 3 ...' statement now.
I think it is desirable if the policy you distribute now can be used to verify your *next* release too. And with "all" you'd get in trouble if one of those witness devices is offline at that time.
Okay, I think I'm slowly grasping concepts here. What we seem to want is release announcements to contain Sigsum public keys and trust policies, and ideally for those to stay identical between releases to allow users to check if two consequetive releases are using the same details. This matches the semantics for PGP public keys, so it make some sense. These instructions are for humans and not machines, so sometimes key rollover and trust policies can change if a human-readable explanation is present.
It would be nice to have some machine readable mechanism too, and even nicer if they are similar.
Maybe with a somewhat more verbose name for the GTF group (I guess it's an abbreviation for google trust fabric, but I guess that's unobvious to users).
Does it convey anything meaningful to the user? I prefer avoiding avoidable advertising.
It says that the utility of those witnesses (and the policy) depends on Google (the operator(*) of all witnesses in the policy) behaving properly. You could think about that in two ways:
Either it's unavoidable advertising... since you are endorsing that policy, that implies that you think the policy has some utility, and hence that you want to express some level of trust in the witness operator.
Or you can think about it as a statement of conditional utility: You say that the policy has utility only for those users willing to have some level of trust in the witness operator doing the right thing.
But in either case, I think it is meaningful for users to know about. And it will clearly be an improvement when we have more production witnesses online.
(*) one could maybe debate whether or not the AW witnesses are "operated" by Google; the devices are operated physically by selected individuals, as I understand it, but both selection of those individuals, and the software updates for the devices, is controlled by the Google folks.
Okay. This seems like a slippery slope towards running my own witness and/or log. I feel a bit uncomfortable using some yet not announced set of servers for long-term verification.
Yep, makes sense. I expect "about pages" to exist for Glasklar's log and (soon to be running) witness in a couple of weeks -- it's what I'm working on right now, and I know it's on the TODO list for GTF too.
But as you might guess, it will take a while longer before this ecosystem matures so much that there's a good selection of logs and witnesses with good business continuity, degrees of independence, etc.
Thanks for trying and giving feedback in the early stages though, it is very helpful (and motivation) in order to move in the right direction!
-Rasmus
It would be good to have additional logs, for reliability. But as far as I'm aware, for now seasalp is the only available one with any intention to operate reliably.
How hard is it to operate? Maybe I could set one up too, for experimentation...
Somewhere strictly between "trivial" and "extraordinary difficult"... For redundancy, you need two machines (and some rough understanding of the fail-over procedures). Each machine needs our log server software + trillian + mysql (we have some ansible stuff to help set that up). And you need to think about how you want to manage the log's private key, there's documentation on how we do that, using multiple yubihsm and physical safes, which is a bit cumbersome and expensive.
If it's for experiments, you can simplify that a bit with a single node and cleartext key on disk (which is how we run poc.sigsum.org/jellyfish). That's still not trivial, but rather easy.
If you are able to operate a production service (say, you're aiming to keep it running for two years, with downtime at most a few days at a time), I think at this time, an additional witness would be more valuable than an additional log.
Perhaps I was just confused -- maybe the DNS name is not looked up during verification? I was worried about that DNS name going away.
It's not needed by the verifier. It is needed by a monitor, which is why I'd suggest you include it in the policy file, even though it's syntactically optional.
Okay. Would it meaningful for a client to (be able to) require that something was submitted to two different logs?
Generally, no. I can see hypothetical scnarios where it could make sense, e.g., if you want to require both group A and group B of witnesses to cosign releases, but those witnesses for some reason don't witness the same logs. Then you could distribute two separate proofs of logging, verify them against separate policies, and require that both proofs are valid. And those semantics would have to be built on top of current tools.
(We might end up with some of those complexities in our tooling, if we want to have multiple versions of policies, which policy to apply depending on the time the proof was made, or by which submission key, but that's still all very open).
Thanks for explaining!
/Simon
On Mon, Jan 13, 2025 at 10:49:00AM +0100, Simon Josefsson wrote:
Thanks for help!
Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
Simon Josefsson simon@josefsson.org writes:
Do you have any objection to the following text snippet? What could you suggest as improvement? I picked 5 AW witnesses from your list.
Ask Al on IRC/Matrix for how he'd recommend to trim down the policy. He's one of the people that are reponsible for the armory witnesses.
It's a bit unclear to me what reliability to expect from the AW witnesses, but it makes sense to me as a starting point.
And as usual, availability of logs and witnesses matters at the time that you need to make a new release. It doesn't matter at all at verificatino time, since that's offline.
So then shouldn't my trust policy be 'all' rather than a 3/5 setup? Assuming all of witnesses are online when doing 'sigsum-submit' as part of the release. I used a 'group ... 3 ...' statement now.
I think of the policy as more long lived. If you "all" now and the next time one witness is missing, then you can't release for an "all" policy.
Maybe with a somewhat more verbose name for the GTF group (I guess it's an abbreviation for google trust fabric, but I guess that's unobvious to users).
Does it convey anything meaningful to the user? I prefer avoiding avoidable advertising.
It says something about what you think Sigsum banks on to be a secure system of append-only log(s). Probably useful for some but not others.
Wouldn't it be more reliable to include two different logs, possibly
It's more reliable from an availability perspective. I.e., it is sufficient that any of the logs are online when you do a submission.
with 2/3 witnesses each? Having a single point of control on the 'seasalp.glasklar.is' domain name seems like a serious problem to me. Hard-coding IP addresses? Tor onion name?
For those wanting a Tor onion name, it's on Linus' TODO list.
https://git.glasklar.is/glasklar/services/sigsum-logs/-/issues/26
It would be good to have additional logs, for reliability. But as far as I'm aware, for now seasalp is the only available one with any intention to operate reliably.
How hard is it to operate? Maybe I could set one up too, for experimentation...
Not hard, a few pointers to get started:
https://git.glasklar.is/sigsum/admin/ansible/-/tree/main/roles/litewitness https://github.com/FiloSottile/litetlog?tab=readme-ov-file#litewitness
Adding a tor onion address is certainly doable, but it's not entirely clear to me what benefits you get; the log is authenticated using its key, so what you'd protect against is attacks on the DNS lookup or attacks on routing or ip-based filtering somewhere in the middle of the routing path?
Perhaps I was just confused -- maybe the DNS name is not looked up during verification? I was worried about that DNS name going away.
Correct -- if the trust policy is only meant to be used by sigsum-verify you should be able to remove the log URL all together. At least it looks like this would be a valid policy when reading the example here:
https://git.glasklar.is/sigsum/core/sigsum-go/-/blob/main/doc/policy.md?ref_...
Can I specify a quorum group requiring inclusion into two different logs with one witness each? Is there an example of a trust policy with multiple logs, and multiple witness from each, and some quorum setting? Can one witness validate multiple logs?
When adding multiple logs to the policy, the semantics is that any of them is fine. Verifier accepts any of them, submitters submit to a randomly selected available log, and monitors should monitor *all* the listed logs.
And the expectation is that you would have more or less the same set of witnesses cosigning all logs in your policy. We'll put that to the test for the next log that someone wants top operate, and which we'd then like to be witnessed by both AW and by the glasklar witness that should materialize soon.
The same quorum in the policy applies regardless of which log was used. If we used a separate quorum for each log, I think that would make analysis of split view attacks a lot harier.
Okay. Would it meaningful for a client to (be able to) require that something was submitted to two different logs?
No -- the potential security property that you're sketching on here is what the (much lighter) witnesses provide.
-Rasmus
On Mon, Jan 13, 2025 at 12:10:41PM +0100, Rasmus Dahlberg wrote:
On Mon, Jan 13, 2025 at 10:49:00AM +0100, Simon Josefsson wrote:
Thanks for help!
Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
Simon Josefsson simon@josefsson.org writes:
Do you have any objection to the following text snippet? What could you suggest as improvement? I picked 5 AW witnesses from your list.
Ask Al on IRC/Matrix for how he'd recommend to trim down the policy. He's one of the people that are reponsible for the armory witnesses.
It's a bit unclear to me what reliability to expect from the AW witnesses, but it makes sense to me as a starting point.
And as usual, availability of logs and witnesses matters at the time that you need to make a new release. It doesn't matter at all at verificatino time, since that's offline.
So then shouldn't my trust policy be 'all' rather than a 3/5 setup? Assuming all of witnesses are online when doing 'sigsum-submit' as part of the release. I used a 'group ... 3 ...' statement now.
I think of the policy as more long lived. If you "all" now and the next time one witness is missing, then you can't release for an "all" policy.
Maybe with a somewhat more verbose name for the GTF group (I guess it's an abbreviation for google trust fabric, but I guess that's unobvious to users).
Does it convey anything meaningful to the user? I prefer avoiding avoidable advertising.
It says something about what you think Sigsum banks on to be a secure system of append-only log(s). Probably useful for some but not others.
Wouldn't it be more reliable to include two different logs, possibly
It's more reliable from an availability perspective. I.e., it is sufficient that any of the logs are online when you do a submission.
with 2/3 witnesses each? Having a single point of control on the 'seasalp.glasklar.is' domain name seems like a serious problem to me. Hard-coding IP addresses? Tor onion name?
For those wanting a Tor onion name, it's on Linus' TODO list.
https://git.glasklar.is/glasklar/services/sigsum-logs/-/issues/26
It would be good to have additional logs, for reliability. But as far as I'm aware, for now seasalp is the only available one with any intention to operate reliably.
How hard is it to operate? Maybe I could set one up too, for experimentation...
Not hard, a few pointers to get started:
https://git.glasklar.is/sigsum/admin/ansible/-/tree/main/roles/litewitness https://github.com/FiloSottile/litetlog?tab=readme-ov-file#litewitness
Oh wait, I thought you meant witness. Logs are more work.
-Rasmus
Adding a tor onion address is certainly doable, but it's not entirely clear to me what benefits you get; the log is authenticated using its key, so what you'd protect against is attacks on the DNS lookup or attacks on routing or ip-based filtering somewhere in the middle of the routing path?
Perhaps I was just confused -- maybe the DNS name is not looked up during verification? I was worried about that DNS name going away.
Correct -- if the trust policy is only meant to be used by sigsum-verify you should be able to remove the log URL all together. At least it looks like this would be a valid policy when reading the example here:
https://git.glasklar.is/sigsum/core/sigsum-go/-/blob/main/doc/policy.md?ref_...
Can I specify a quorum group requiring inclusion into two different logs with one witness each? Is there an example of a trust policy with multiple logs, and multiple witness from each, and some quorum setting? Can one witness validate multiple logs?
When adding multiple logs to the policy, the semantics is that any of them is fine. Verifier accepts any of them, submitters submit to a randomly selected available log, and monitors should monitor *all* the listed logs.
And the expectation is that you would have more or less the same set of witnesses cosigning all logs in your policy. We'll put that to the test for the next log that someone wants top operate, and which we'd then like to be witnessed by both AW and by the glasklar witness that should materialize soon.
The same quorum in the policy applies regardless of which log was used. If we used a separate quorum for each log, I think that would make analysis of split view attacks a lot harier.
Okay. Would it meaningful for a client to (be able to) require that something was submitted to two different logs?
No -- the potential security property that you're sketching on here is what the (much lighter) witnesses provide.
-Rasmus
Simon Josefsson simon@josefsson.org writes:
- Suggest a filename extension
It seems some people use *.proof although *.sigsum-proof may be more advertizy. Or just *.sigsum?
Naming is somewhat hard... On one hand, I like the very explicit .sigsum-proof, but it would also be nice with something shorter.
Maybe canonical name *.sigsum-proof and a short form like *.ssp (SigSum Proof), *.prf (sigsum PRooF), *.spf (Sigsum ProoF), *.sps (Sigsum Proof Signature), *.sis (SIgsum Signature), *.ssi (Sigsum SIgnature), ...?
Of the three-letter extension, I like .prf, which seems easy to read out like "proof". Might cause some confusion with PReFerences files or PRoFile files, but I guess that's inevitable with a three letter acronym.
I think a three character extension would be nice.
Do you think it still matters? I'm thinking of usecases like transferring files on a USB device with a FAT file system, would you get less problems with "foo-1.1.tar.gz.prf" than with "foo-1.1.tar.gz.proof"? Or are there other usecases where it could matter?
We might also want to think about if we want to stress "proof" as "proof of Sigsum logging", or if we want to frame it as a kind of extended aka "spicy" signature.
I realize now that the sigsum-submit --help is already fairly clear:
I think the current (and documented) behavior makes sense. But we could discuss if .proof is the best extension.
- Add a ABNF grammar describing the format.
What concrete utility do you see? If we adopt ABNF, we should consider adding that also to https://git.glasklar.is/sigsum/project/documentation/-/blob/main/log.md.
My primary utility of doing that is to lock down the format so we won't have ten slightly different variants of it. And alignment with the MIME/IETF registration process.
I don't object to that. And I hope it should be fairly easy to get the ABNF right, since the format is rather simple.
https://datatracker.ietf.org/doc/html/rfc2046#section-4.1.1 says
The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence.
Apparently this doesn't prevent using text/plain on LF-delimited files, and that seems better than using application/sigsum-proof for what is essentially text anyway.
If that appears acceptable, then I'd be happy with "text/sigsum-proof" (ascii-only, but no explicit charset parameter), and mandated LF line endings, even though that violates RFC 2046 as you quote above.
An Informational RFC would be nice, although strictly not required. Instead you could prepare a *.md file specifying things and then fill out this form:
We discussed this briefly at today's Sigsum weekly. I think the next step is to move the spec to https://git.glasklar.is/sigsum/project/documentation, next to log.md, and apply another round of polish.
Okay - having versioning in the format specification is fine, it could simply say that anything except 'version=2' is undefined behaviour.
And I take it it would be acceptable, at a later time, to update the reference for the MIME type to assign meaning to contents that don't start with the literal line "version=2" ?
I believe most formats specify one MIME type once and then do version rolling inside the format specifications. Introducing new MIME types for each new format version is more fragile, and usually doesn't give any advantages.
Agree a new MIME type seems excessive. I was thinking of something like "image/jpeg; coding=arithmetic" expressing that support for arithmetic coding ("not yet widely implemented" according to the cjpeg man page) is required to be able to process the contents. Or in an Accept: header, it would advertise that you do have that ability. But I'm not aware of anything like that used in practice.
Regards, /Niels
On Tue, Jan 07, 2025 at 03:37:31PM +0100, Sigsum General wrote:
Simon Josefsson simon@josefsson.org writes:
- Suggest a filename extension
It seems some people use *.proof although *.sigsum-proof may be more advertizy. Or just *.sigsum?
Naming is somewhat hard... On one hand, I like the very explicit .sigsum-proof, but it would also be nice with something shorter.
Maybe canonical name *.sigsum-proof and a short form like *.ssp (SigSum Proof), *.prf (sigsum PRooF), *.spf (Sigsum ProoF), *.sps (Sigsum Proof Signature), *.sis (SIgsum Signature), *.ssi (Sigsum SIgnature), ...?
Of the three-letter extension, I like .prf, which seems easy to read out like "proof". Might cause some confusion with PReFerences files or PRoFile files, but I guess that's inevitable with a three letter acronym.
I also think .ssi is good -- easy to say with three syllables S-S-I.
I think a three character extension would be nice.
Do you think it still matters? I'm thinking of usecases like transferring files on a USB device with a FAT file system, would you get less problems with "foo-1.1.tar.gz.prf" than with "foo-1.1.tar.gz.proof"? Or are there other usecases where it could matter?
We might also want to think about if we want to stress "proof" as "proof of Sigsum logging", or if we want to frame it as a kind of extended aka "spicy" signature.
I think stressing ".sigsum" is nice from this perspective, i.e., it's a SIGned checkSUM that happens to be transparent thanks to sigsum.
-Rasmus
I realize now that the sigsum-submit --help is already fairly clear:
I think the current (and documented) behavior makes sense. But we could discuss if .proof is the best extension.
- Add a ABNF grammar describing the format.
What concrete utility do you see? If we adopt ABNF, we should consider adding that also to https://git.glasklar.is/sigsum/project/documentation/-/blob/main/log.md.
My primary utility of doing that is to lock down the format so we won't have ten slightly different variants of it. And alignment with the MIME/IETF registration process.
I don't object to that. And I hope it should be fairly easy to get the ABNF right, since the format is rather simple.
https://datatracker.ietf.org/doc/html/rfc2046#section-4.1.1 says
The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence.
Apparently this doesn't prevent using text/plain on LF-delimited files, and that seems better than using application/sigsum-proof for what is essentially text anyway.
If that appears acceptable, then I'd be happy with "text/sigsum-proof" (ascii-only, but no explicit charset parameter), and mandated LF line endings, even though that violates RFC 2046 as you quote above.
An Informational RFC would be nice, although strictly not required. Instead you could prepare a *.md file specifying things and then fill out this form:
We discussed this briefly at today's Sigsum weekly. I think the next step is to move the spec to https://git.glasklar.is/sigsum/project/documentation, next to log.md, and apply another round of polish.
Okay - having versioning in the format specification is fine, it could simply say that anything except 'version=2' is undefined behaviour.
And I take it it would be acceptable, at a later time, to update the reference for the MIME type to assign meaning to contents that don't start with the literal line "version=2" ?
I believe most formats specify one MIME type once and then do version rolling inside the format specifications. Introducing new MIME types for each new format version is more fragile, and usually doesn't give any advantages.
Agree a new MIME type seems excessive. I was thinking of something like "image/jpeg; coding=arithmetic" expressing that support for arithmetic coding ("not yet widely implemented" according to the cjpeg man page) is required to be able to process the contents. Or in an Accept: header, it would advertise that you do have that ability. But I'm not aware of anything like that used in practice.
Regards, /Niels _______________________________________________ Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
sigsum-general@lists.sigsum.org
-
Niels Möller -
Rasmus Dahlberg -
Simon Josefsson