On Fri, Feb 21, 2025 at 01:11:11PM +0100, Sigsum General wrote:
All,
I just announced GNU InetUtils with Sigsum signatures:
https://lists.gnu.org/archive/html/bug-inetutils/2025-02/msg00002.html
Below are the Sigsum-related commands I ran to Sigsum-sign the release including verification.
Does anyone have suggestions on how to improve the announcement text
I think the announcement text looks as good as it gets right now. As we discussed before, the main improvement points would be:
1. Better way to communicate/get the trust policy 2. Better primer page(s) rather than the broad getting started
For (1), I would like if we could remove the wget (or EOF blurbs) and just say something like this:
sigsum-verify -k inetutils-sigsum-key.pub -p sigsum-strict \ inetutils-2.6.tar.gz.proof < inetutils-2.6.tar.gz
where sigsum-strict is a named policy maintained by Sigsum that, e.g., gives a high level of assurance at the cost of higher risk of unavailability at the time of submission. I'd expect the name to be mapped to a trust policy by the tool and/or its packaging, and for there to be other named policies than the one(s) maintained by Sigsum folks.
It's on our current roadmap to come up with a proposal in the direction of named policies / how to get rid of the EOF blurbs (which you did now with a wget -- it works but also seems a bit unoptimal in the long run).
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/archive/202...
As soon as there's any more concrete thoughts to comment on I'll let you know. (I already took note of your feedback in the other email thread.) And before we implement anything, a proposal will (as usual) be circulated and eventually decided on a sigsum weekly meet.
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.
See below for a few more suggestions.
I'd like to establish a "best practice" on how to Sigsum-protect software source code releases, for other maintainers to follow.
Nice, keep up the good work! Your early usage is very helpful.
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.
(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 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.)
/Simon
ssh-add -L > jas.pub sigsum-submit -k jas.pub inetutils-2.6.tar.gz sigsum-submit -k jas.pub inetutils-2.6.tar.xz sigsum-submit -k jas.pub inetutils-v2.6-src.tar.gz
Could be a single command:
sigsum-submit -k jas.pub inetutils-2.6.tar.gz inetutils-2.6.tar.xz inetutils-v2.6-src.tar.gz
cp ../www-inetutils/sigsum-policy.txt .
sigsum-submit --timeout 30s --diagnostics=debug -p sigsum-policy.txt --token-signing-key ~/self/sigsum-token-secret-josefsson.org/mykey --token-domain josefsson.org inetutils-2.6.tar.gz.req sigsum-submit --timeout 30s --diagnostics=debug -p sigsum-policy.txt --token-signing-key ~/self/sigsum-token-secret-josefsson.org/mykey --token-domain josefsson.org inetutils-2.6.tar.xz.req sigsum-submit --timeout 30s --diagnostics=debug -p sigsum-policy.txt --token-signing-key ~/self/sigsum-token-secret-josefsson.org/mykey --token-domain josefsson.org inetutils-v2.6-src.tar.gz.req
Could also be a single command:
sigsum-submit --timeout 30s --diagnostics=debug -p sigsum-policy.txt --token-signing-key ~/self/sigsum-token-secret-josefsson.org/mykey --token-domain josefsson.org inetutils-2.6.tar.gz.req inetutils-2.6.tar.xz.req inetutils-v2.6-src.tar.gz.req
But you'd probably want to increase the timeout to get comparable behavior since efficient batch submit is not merged yet.
https://git.glasklar.is/sigsum/core/sigsum-go/-/merge_requests/227
The above should be merged ~next week (nisse is not here this week).
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.
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.
build-aux/gnupload --to ftp.gnu.org:inetutils inetutils-2.6.tar.gz.proof inetutils-2.6.tar.xz.proof inetutils-v2.6-src.tar.gz.proof
Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
Hi
Here is a software announcement with pointers to Sigsum proofs
https://lists.gnu.org/archive/html/help-libtasn1/2025-02/msg00000.html
The artifact can be reproduce by GitLab pipeline or offline by following the same recipe as in .gitlab-ci.yml ('R-guix' job) on the git tag.
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.)
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.
(FYI: it's on my wish list to put together a monitor for your use-case by adapting age-release verify. But right now I'm a bit backlogged.)
-Rasmus
/Simon
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