Show HN: Rget verify GitHub releases against a public recorded cryptographic log

This is a user-facing implementation of https://wiki.mozilla.org/Security/Binary_Transparency, built on top of Let's Encrypt (https://letsencrypt.org/) and exisiting Certificate Transparency infrastructure.

You may already know that packages are signed, and that signing prevents someone from shipping you a random evil package instead of the one that the developer intended to release.

Transparency is a new concept that fills in a missing piece of that story: how can you be sure that you got the same artifact as everyone else? It works by adding a hash of every release to an append-only public log. Now, when you're deciding if you want to install that package, you check not just the signature but also if the hash of the thing you've received is in the public log.

Because of the logging, someone can't just ship you a custom evil version even if they steal the signing keys! At minimum they'll have to submit their version to the log as well, which makes that previously undetectable attack publicly visible forever. In the world of TLS certificates, log monitors catch all kinds of mistakes and malice. I'm excited to see the idea finally making progress in other domains.

If you want to go straight to the code you can find it at https://github.com/merklecounty/rget#rget

My initial target with the project is to onboard a couple of popular GitHub projects. And because of my experience with etcd and Kubernetes I am starting with those two:

https://github.com/kubernetes/kubernetes/issues/70132#issuec... https://github.com/etcd-io/maintainers/issues/16

This is an interesting problem space that I think people are starting to really dig into and build systems around. For example the Go community is working on a similar log for their federated library package system: https://blog.golang.org/modules2019

Also, here is a good post on the topic in general as well: http://unmitigatedrisk.com/?p=636

Very interesting! I've always thought that it was interesting that the hash and the download would often be hosted on the same server.

I was wondering though, would a distributed ledger make sense as an alternative to a set of public logs operated by multiple organizations?