Open Stack

On 2019-07-29 13:52:20 -0700 (-0700), James E. Blair wrote:
> A colleague at Red Hat is working on an effort to record signatures of
> release artifacts.  Essentially it's a way to help users verify release
> artifacts (or determine if they have been changed) independent of PGP
> signatures.  You can read about it here:
> https://github.com/merklecounty/rget#rget
[...]
> As mentioned in the README this is very early stages and the author,
> Brandon Philips, welcomes both further testing and feedback on the
> process in general.
> 
> Thoughts?

I really like the way it leverages RFC 6962 Certificate Transparency
logs for checksum distribution; the decision not to fall into the
blockchain-all-things trap lends a lot of additional credibility to
the idea. I agree this would be fairly trivial to integrate into our
release publication jobs, and even to backfill with our existing
archives. It would grant consumers of our release artifacts the
ability to validate them against an open third-party registry,
separately from checking the cryptographic release signatures we
currently provide alongside them... it could even be used to detect
tampering with the signatures themselves in the event of a signing
key compromise. This seems like a great idea for URLs of artifacts
we host, and I'm happy to hack on the implementation in OpenDev's CI
system, likely via a new role in Zuul's standard library of job
components.

For artifacts we upload to third-party services like PyPI and Docker
Hub on the other hand, assuming I've digested (pun intended) the
relevant literature correctly, it might make more sense for the
maintainers of those services to do something similar as they tend
to perform a fair amount of URL indirection and so trying to keep up
historical data for those URLs ourselves could be tricky. On the
other hand if those third-party services were to integrate rget
updating as part of their infrastructure it would be a lot more
seamless (especially if they similarly integrated CT checks into the
corresponding client-side tooling).

Another challenge I see is that, due to the fact that most of what
we host is source code, and most consumers of our source code are
obtaining it via Git rather than release artifacts, rget wouldn't
really do much for them as far as I can see... though once Git
completes its planned transition to SHA2-256 in the coming years, I
could see a call for some solution to publish known object hashes to
a CT log in a similar fashion. I suppose it could be done now by
re-checksumming all content over a Git object and submitting a
certificate for that, but it seems a bit heavy-weight and I'll admit
to not having thought through it completely so there are likely
hidden gotchas with that idea.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20190729/0dbd2b77/attachment.sig>