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