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.
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:
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
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.
[+] [-] gtank|6 years ago|reply
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|6 years ago|reply
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
[+] [-] mevile|6 years ago|reply
I was wondering though, would a distributed ledger make sense as an alternative to a set of public logs operated by multiple organizations?
[+] [-] philips|6 years ago|reply
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...