
Show HN: Rget verify GitHub releases against a public recorded cryptographic log - philips
https://merklecounty.substack.com/p/rget-a-secure-download-user-story
======
gtank
This is a user-facing implementation of
[https://wiki.mozilla.org/Security/Binary_Transparency](https://wiki.mozilla.org/Security/Binary_Transparency),
built on top of Let's Encrypt
([https://letsencrypt.org/](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.

------
philips
If you want to go straight to the code you can find it at
[https://github.com/merklecounty/rget#rget](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/kubernetes/kubernetes/issues/70132#issuecomment-518297891)
[https://github.com/etcd-io/maintainers/issues/16](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](https://blog.golang.org/modules2019)

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

------
mevile
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?

~~~
philips
That is a great question. See the FAQ entry on the README[1] for my thoughts
on that.

Q: Why not build this ontop of blockchain?

A: Blockchain could be used to create a similar guarantee. However, using the
Certificate Transparency technology extends a number of advantages and was a
pragmatic choice to get this project going: the industry momentum of
certificate transparency log technology (1), leverage existing web
technologies like DNS and TLS (2), and finally most practical applications
that want to use blockchain with the web end up using a centralized gateway
for speed and reliability (3)(4). Perhaps as the bridge between the web and
blockchain matures it will become a more practical option.

[1]:
[https://github.com/merklecounty/rget/blob/master/README.md#f...](https://github.com/merklecounty/rget/blob/master/README.md#faq)

