Skip to content
download URLs and verify the contents against a publicly recorded cryptographic log
Go Other
  1. Go 99.7%
  2. Other 0.3%
Branch: master
Clone or download

Latest commit

philips README: update to new etcd
Certificate renewal doesn't seem to be working... update to a new etcd
Latest commit b52ab3b Oct 20, 2019


Type Name Latest commit message Commit time
Failed to load latest commit information.
Documentation Documentation: backup original firefox design doc Aug 5, 2019
autocert *: use a go vanity import path Aug 5, 2019
fixtures add fixture for sha256sum file Mar 17, 2019
gitcache gitcache: check unchecked errors Aug 30, 2019
internal/testutil gitcache: refactor test setup to testutil Aug 1, 2019
production production: prometheus: switch project and cluster Aug 5, 2019
rget rget/cmd: check unchecked error Aug 30, 2019
rgetct rgetct: cleanup the code significantly Jul 22, 2019
rgetgithub rget: github: publish archives Jul 20, 2019
rgethash *: use a go vanity import path Aug 5, 2019
rgetserver rgetserver: Fix vanity URL import path Aug 28, 2019
rgetwellknown rget: server: add metrics endpoint Aug 2, 2019
vendor vendor: add promauto Aug 2, 2019
.gitignore gitignore: don't commit secrets Jul 3, 2019
.goreleaser.yml *: rename everything to the final name Jul 3, 2019 CODE_OF_CONDUCT: initial commit Aug 3, 2019
Dockerfile *: use a go vanity import path Aug 5, 2019
LICENSE Apache 2 license applies to the whole project not just `rget` Aug 5, 2019
Makefile Makefile: initial commit Jun 29, 2019 README: update to new etcd Oct 21, 2019 initial commit Aug 3, 2019
TODO TODO: more updates on completed tasks Aug 5, 2019
go.mod *: use a go vanity import path Aug 5, 2019
go.sum go.mod: update dependencies Jul 30, 2019


Go Report Card Docker Repository on Quay Build Status GoDoc

Alpha Warning: rget works as described but has minimal testing, no peer review, and no load testing. Please test the tool and provide feedback.

rget downloads URLs and verifies the contents against a publicly recorded cryptographic log. The public log gives users of rget a number of useful properties:

  • Verifiability of a downloaded URL's contents being identical to what the rest of the world sees
  • Searchability of recorded content changes of a URL
  • Notifications to any interested party about changes to the URLs contents

In practice the way the system works is a URL owner will publish the cryptographic digests at a URL adjacent to the content a rget user is downloading. The rget tool will download the digest and verify this digest appears in the Certificate Transparency log via a specially crafted DNS name.

Learn more and stay up to date with the project blog and newsletter. Checkout some of the blog posts:


Download the appropriate release from and extract the archive

Example Usage

Use rget to download the v3.4.2 etcd release for macOS and verify that the contents are publicly recorded.


Developer Usage

GitHub Developer Usage

It takes two commands to make a release available for verified download with rget:

rget github publish-release-sums

The first command will start a local web server and open a Github authorization URL in your browser. You will have 120 seconds to authorize it.

When authorized, it will calculate SHA256 sums for every file in the release, create a SHA256SUMS file, and add it to the Github release.

rget submit

The second command will submit the sums to the log. This does not use any GitHub credentials.

Note: If a project has release automation that uploads to GitHub simply add the creation of SHA256SUMS to the automation instead of using github publish-release-sums and call rget submit after uploading. See the integrations doc for a list of tools that work out of the box. As an example rget uses Go Releaser for automation.

Administration Usage

Run a server that will upload SHA files to a git repo for file backing

rget server <public git repo> <private certificates git repo>


If you have a question that isn't answered here please open an issue or start a discussion on the mailing list

  • Q: Where did this idea come from?

  • A: This project builds upon a design doc for Binary Transparency originally designed for the Mozilla Firefox project.

  • 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.

  • Q: Why not use GPG keys or other public key signing?

  • A: This is complimentary to public key signing! Public key signing asserts that someone with access to the private key signed the exact content. But, the private key can be used to generate an unlimited number of signatures for different content. If the URLs contents are both signed and logged in the URL content record then there is a guarantee that both the owner of the private key signed the content AND the content being fetched is cryptographically identical to the content other people are fetching using rget.

  • Q: Where does the name rget come from?

  • A: The "r" stands for recorder, as in a clerk who records or processes records. In many governments a Recorder of Deeds (aka Registrar General, County Clerk, etc) is an official who is tasked with recording and maintaining important public records of real property. Similarly this project aims to maintain a public record of internet property in the form of the cryptographic digest of certain URLs and provide tools to verify those records. The "get" comes from the HTTP GET verb and other tools like Wget.

  • Q: What are examples of practical attacks this could mitigate?

  • A: A well known example is the Feb. 2016 attack on the Linux Mint project where an attacker replaced a version of a Linux Mint release with a new version that included a backdoor vulnerability. With luck this was detected and mitigated within a day, however, there are likely many projects that have been attacked in a similar way without catching the attack. Further, the project could not make a strong assurance to the community on how long they were vulnerable, only stating "As far as we know, the only compromised edition was Linux Mint 17.3 Cinnamon edition.". By ensuring the cryptographic digests of all releases end up in a publicly audited log the project could have stated exactly when the content changed and potentially used a Certificate Transparency monitor to get notified quickly once it happened.

  • Q: What happens if an attacker can modify SHA256SUMS files?

  • A: The modification will show up in the logs. As an example the v1.0 release of the philips/releases-test project was modified several times. And this appears in the log on both and Google's Transparency Report

You can’t perform that action at this time.