On Tue, Feb 25, 2025 at 04:41:10PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
and/or commands used to sign things?
Do you sign and submit on separate setups? If yes, fun to see that someone uses that feature! If no, you could sign and submit in a single step by passing both -k and -p when running sigsum-submit.
Right, I noticed this but I prefer to keep privileges of commands that need private keys as minimal as possible, for easier auditing. If both -k and -p is given, the tool goes from a offline tool to an online tool that talks to remote servers.
Ack, makes sense!
I was happy to see that you made an effort to separate these two steps, so I can tighten down permissions when running the private key operation.
Happy to see it used -- thanks nisse for designing it that way!
It uses a 8/15 GoogleTrustFabric witness quorum in the trust policy file, not mentioned in the release notes since this information doesn't seem widely published yet.
For more diversity you could consider adding Glasklar's witness:
https://git.glasklar.is/glasklar/services/witnessing/-/blob/main/witness.gla...
Mullvad also started running a stable witness (not documented similar to Google's witness, only mentioned on Matrix a couple weeks back):
witness witness.mullvad.net 15d6d0141543247b74bab3c1076372d9c894f619c376d64b29aa312cc00f61ad
I'd probably set the threshold to 2/3 for google,glasklar,mullvad; and keep the google threshold at 8/15.
Thanks -- I'll try to do this next time.
(Note that you probably want to create a new policy file rather than updating the existing one, and then link the new file in newer announcements. Since otherwise the old instructions will break.)
I was thinking I could make changes to the trust policy file if it were a strict superset of the earlier information. What is important is that both new and old commands still work, not that the trust policy is necessarily identical, or am I missing something?
If the old proofs that you already published also work for the new policy it should be fine. That may or may not be the case, depends.
E.g., now you're releases probably have cosignatures that would satisify a google,glasklar,mullvad 2/3 policy (you can check with sigsum-verify).
But if glasklar's and mullvad's witness had been put into operation today, you wouldn't have had those cosignatures in your .proof files and so the update of your out-of-band trust policy would have been breaking.
I don't like storing the rate-limiting domain token private key on disk. I noticed it is recommended to use a separate key for this, but what are the risks if people would start to use their software signing key instead? Aren't the signatures domain separated? Key management is a hassle, so reducing the number of private keys people have to manage the lifecycle for leads to a overall security improvement. I would also prefer to use my hardware-bound OpenPGP signing subkey (instead of my hardware-bound OpenPGP authentication subkey), but I haven't been able to figure out the SSH agent tooling for this.
You're right that submit and rate-limit signatures are domain separated with a namespace. So, there's no security risk for your signed checksums if you re-use the same key for submission and rate limiting.
The only caveat is that the rate-limit key is essentially used to compute token=Sign(key, <log pubkey>). Then "$domain, $token" is passed as an HTTP header to the log server when doing a submission.
The risk: if $token is somehow revealed to an unauthorized party, then that party can start spending your rate-limit. Recovery requires rotating the rate-limit key and updating your DNS TXT record. In which case you're back to having separate keys.
Further reading:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/log.md#4--r...
Does this context help wrt. if it is safe to reuse the same key? (If it helps I would also start by using the same submit and rate limit key.)
Thanks for the link! I find this design surprising: if I understand you correctly, it means the private key is only needed once to generate the token, not on every sigsum-submit usage. So effectively the token is a long-lived key-equivalent?!
Correct, so what's really computed is a per-log-and-per-key HTTP token. And sigsum-submit derives that (identical) token every time it runs, rather than using the token(s) that can be produced with `sigsum-token`.
I was expecting some kind of challenge-response or at least monotonically increasing signed counter, to avoid replay attacks of earlier submission tokens.
Here's the proposal when we migrated to this fixed token, which discusses something in the direction of what you're sketching on:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/proposals/2...
If you think it was the wrong decision it could be re-opened. The best way to would be to write a proposal and circulate it for discussion.
Could also be a single command:
Thanks!
sigsum-verify -k jas.pub -p sigsum-policy.txt inetutils-2.6.tar.gz.proof < inetutils-2.6.tar.gz sigsum-verify -k jas.pub -p sigsum-policy.txt inetutils-2.6.tar.xz.proof < inetutils-2.6.tar.xz sigsum-verify -k jas.pub -p sigsum-policy.txt inetutils-v2.6-src.tar.gz.proof < inetutils-v2.6-src.tar.gz
Running sigsum-verify is redundant, i.e., sigsum-submit does not give you a .proof file unless it verifies for the input and provided policy.
Okay. I find it good to actually test what end-users will run to make sure I get it correct.
Makes sense!
sha256sum inetutils-2.6.tar.gz | cut -d' ' -f1 | base16 -d | sha256sum sha256sum inetutils-2.6.tar.xz | cut -d' ' -f1 | base16 -d | sha256sum sha256sum inetutils-v2.6-src.tar.gz | cut -d' ' -f1 | base16 -d | sha256sum
sigsum-monitor --interval 5s -p sigsum-policy.txt jas.pub
Given the tools we have right now it doesn't get better than this. I'll comment more below on the topic of writing a monitor for your use-case.
Fwiw, a sigsum-keygen sub-command to compute the SHA256(SHA256(file)) value would be useful. Initially I didn't have the 'base16' tool and it isn't that common.
Good idea, filed:
https://git.glasklar.is/sigsum/core/sigsum-go/-/issues/103
Ideas for improvements?
Specify somewhere what you're claim is. To me it looks like the claim is: you will only sign checksums that can be reproduced from source at $LOCATION, see $R-GUIX-JOB. This is what I'm sketching a monitor on.
The claim could also include where you publish release announcements, in which case the monitor could try to falsify something like: "official releases are announced at $MAILING-LIST". So if you ever make a release without announcing it there, then the monitor could flag it as well.
(Claims are helpful so monitors know what to falsify / verify.)
Thanks! The concept of "claims" really helps to make the concepts understandable to my mind.
Amazing, yes it's a helpful concept!
Unfortunately it is not clear to me what I think is useful to actually claim here. The R-GUIX-JOB is complex and tied to the GitLab pipeline infrastructure. I don't think it is a very good claim going forward. You may find the B-Guix job simpler - effectively ./bootstrap + ./configure + make dist after adjusting for build dependencies.
I think a better claim would be something like: I claim to sign only source tarballs that were prepared reproducibly via 'make dist' by me by using 'guix time-machine ...' in a git checkout of the tagged commit.
Sounds good (and I also like the well-known script path further below.)
The 'guix time-machine' command should be a complete command that people can run to reproduce the tarball.
We don't know if the 'guix time-machine' will actually work in 10 years, but I don't know of any other approach available that offers any similar promise. Specifying a particular Debian snapshot timestamp and related commands get complex quickly. I think most normal GNU/Linux operating system doesn't give me the kind of behavior that is needed here.
This sounds like an orthogonal improvement point; that it already works to do this for (quite some time?) is really good. I would suspect that the most interesting issues are anyway detected close to the release?
Are you able to build a "libtasn1 release monitor" out of this information?
From a quick glance it seems possible, yes.
Sketch:
Monitor tails release tags from the git repository. For each release tag, run the rebuild recipe and arrive at the expected checksums. Now we basically have a list of (release tag, checksums) pairs. In your case it looks like there are three checksums per release tag.
Monitor tails sigsum logs in the trust policy, filtering entries on your submit key. And ensure it sees enough cosignatures for your trust policy. Now we basically have a list of signed checksums that users would have accepted as valid.
Compute the diff between checksums in the log and checksums that were reproduced. If there's ever a checksum in the log that haven't been reproduced from source, flag it and escalate to the monitor's operator.
This might happen if:
- There is a reproducibility issue
- Submit key signed something that's out of tree (hidden release)
If there is a claim about where official release announcements are, the monitor could also verify that all releases have been published there.
Great! The main thing to improve here, I think, would be to establish some commonality for the "run the rebuild recipe" step. How about mandating that a script ".sigsum/reproduce-release-artifacts" should be present to support Sigsum artifact reproduction? Maybe that is useful beyond Sigsum even.
That sounds exactly like what we've discussed for age, i.e., the repository should have a script that knows how to reproduce the tarballs (when checked out at a given version). It makes sense that this script has a well-known path. I agree it doesn't have to be .sigsum/. We just need to know what the well-known path is to configure sigsum's monitor.
-Rasmus