<commit_before>---
layout: post
title: "gpg-sign releases"
category: advanced
---

As a developer you use code written by other people _all the time_. To keep upstream changes from breaking your code, you depend on release numbers. Libraries like "bootstrap":https://github.com/twbs/bootstrap use "git tags":http://gitready.com/beginner/2009/02/03/tagging.html to track releases and make them available for download.

This strategy is common enough that GitHub has a handy release page right "here":https://github.com/twbs/bootstrap/releases/tag/v3.3.0 to download the zip/tar.gz of the tag you need.

You have the tarball, but are you sure you have the right code? Could the NSA have tampered with it? Could your internet service provider? Could GitHub? That release passes through many hands between the developer's hard drive and yours.

Well what if we cloned the repo directly? Commits are all hashed, and you can examine the history.

<pre>
$ git clone --branch v3.3.0 https://github.com/twbs/bootstrap
</pre>

Unfortunately, this very site can tell you how to "alter git history":http://localhost:4000/intermediate/2009/01/31/intro-to-rebase.html. Someone sneaky could hide a malicious change in the project history. Luckily, git can help. Signed tags use "Gnu Privacy Guard":https://www.gnupg.org/ to verify that a tag was made by the developers of the project, and that the contents are correct.

<pre>
$ cd bootstrap
$ git tag --verify v3.3.0
error: 16dbdbd7a2c6cfa3be4e5dcc52249e577c02c84a: cannot verify a non-tag object of type commit.
error: could not verify the tag 'v3.3.0'
</pre>

Dang, doesn't look like bootstrap signs their tags. Let's try a project that does sign their tags.

<pre><commit_msg>fix link and add byline<commit_after>---
layout: post
title: "gpg-sign releases"
category: advanced
---

This is a guest post from "<NAME>.":http://rsb.io/

As a developer you use code written by other people _all the time_. To keep upstream changes from breaking your code, you depend on release numbers. Libraries like "bootstrap":https://github.com/twbs/bootstrap use "git tags":http://gitready.com/beginner/2009/02/03/tagging.html to track releases and make them available for download.

This strategy is common enough that GitHub has a handy release page right "here":https://github.com/twbs/bootstrap/releases/tag/v3.3.0 to download the zip/tar.gz of the tag you need.

You have the tarball, but are you sure you have the right code? Could the NSA have tampered with it? Could your internet service provider? Could GitHub? That release passes through many hands between the developer's hard drive and yours.

Well what if we cloned the repo directly? Commits are all hashed, and you can examine the history.

<pre>
$ git clone --branch v3.3.0 https://github.com/twbs/bootstrap
</pre>

Unfortunately, this very site can tell you how to "alter git history":http://gitready.com/intermediate/2009/01/31/intro-to-rebase.html. Someone sneaky could hide a malicious change in the project history. Luckily, git can help. Signed tags use "Gnu Privacy Guard":https://www.gnupg.org/ to verify that a tag was made by the developers of the project, and that the contents are correct.

<pre>
$ cd bootstrap
$ git tag --verify v3.3.0
error: 16dbdbd7a2c6cfa3be4e5dcc52249e577c02c84a: cannot verify a non-tag object of type commit.
error: could not verify the tag 'v3.3.0'
</pre>

Dang, doesn't look like bootstrap signs their tags. Let's try a project that does sign their tags.

<pre>
{'fraction_non_alphanumeric': 0.08452722063037249, 'fraction_numerical': 0.02865329512893983, 'mean_word_length': 4.249624060150376, 'pattern_counts': {'":': 11, '<': 14, '<?xml version=': 0, '>': 14, 'https://': 8, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6428385', 'n_tokens_mistral': 1073, 'n_tokens_neox': 997, 'n_words': 476}