<?xml version="1.0" encoding="UTF-8"?><feed xmlns="http://www.w3.org/2005/Atom"><id>https://vic.demuzere.be/articles/tags/pgp/atom.xml</id><title>Vic Demuzere - PGP</title><link href="https://vic.demuzere.be/articles/tags/pgp/atom.xml" rel="self" type="application/atom+xml" /><link href="https://vic.demuzere.be/articles/tags/pgp/" rel="alternate" type="text/html" /><updated>2015-03-22T11:50:50+00:00</updated><author><name>Vic Demuzere</name></author><entry><id>https://vic.demuzere.be/articles/cryptographically-signing-git-commits-tags/</id><title>How to sign your project's git history</title><link href="https://vic.demuzere.be/articles/cryptographically-signing-git-commits-tags/" rel="alternate" /><updated>2025-03-28T08:56:26+00:00</updated><published>2015-03-22T11:50:50+00:00</published><content type="html"><![CDATA[<p>Git lists the author of every commit ever made to a repository.
This comes in quite handy, but is easy to fake.
Author data is simply read from the configuration file without any validation.
This means you could easily commit to an (open source) repository and pretend to be me.</p>
<pre><code>git config --global user.name &quot;Your Name&quot;
git config --global user.email you@example.com
</code></pre>
<p>The author data is especially important when something goes wrong.
Imagine a certain commit caused a security issue, or broke software in a way that should have been caught by tests.
Who made this change?
It is clear that we shouldn't trust the author listed by <code>git log</code> in this case.</p>
<p>Tags have partially solved this issue by allowing you to PGP sign them.
As the git commit hash includes the parent hash, this signature validates the complete history up to that specific tag.
The PGP signature is made by your personal key and is harder to fake.</p>
<h2 id="tags-with-a-signature">Tags with a signature<a href="#tags-with-a-signature" aria-label="Link to heading 'Tags with a signature'" data-heading-content="Tags with a signature" class="anchor"></a></h2>
<p>Creating a signed tag is easy once you have set up your private key in GnuPG.
Execute the <code>tag</code> command with the <code>-s</code> flag to sign the tag as you create it.</p>
<pre><code>git tag -s &lt;name&gt;
</code></pre>
<p>Git should be able to automatically find your PGP key based on the e-mail address you've listed in the <code>user.email</code> setting.
In case you don't want git to figure this out, it is also possible to set a default signing key globally:</p>
<pre><code>git config --global user.signingkey 1234ABCD
</code></pre>
<p>That's it! Now your tag is signed. This moves the problem but doesn't actually solve it.
Signed tags allow you to declare that you have <em>checked the commit log</em> and verified that it wasn't tampered with.
It is now possible to verify the tag using <code>git tag -v</code>.
This works fine for small projects and teams with only a few developers.
But what if you're managing something bigger?</p>
<p>Your initial problem remains: How do you know for sure who changed your code?
The real solution is obvious...</p>
<h2 id="signing-every-commit">Signing every commit<a href="#signing-every-commit" aria-label="Link to heading 'Signing every commit'" data-heading-content="Signing every commit" class="anchor"></a></h2>
<p>Git v1.7.9 introduced the ability to cryptographically sign commits, similar to how it works with tags.
The difference here is that the shortcode is uppercase <code>-S</code> as the lowercase flag is used for the <code>Signed-off-by</code> field already.
Other than that, usage is pretty much the same.</p>
<pre><code>git commit -am &quot;Fixed something somewhere&quot; -S 1234ABCD
</code></pre>
<p>There is quite a bit discussion about whether it is useful to sign every commit.
Linus Torvalds <a href="https://web.archive.org/web/20210415082241/http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html" title="Linus Torvalds on commit signing.">explained why he thinks signing commits is a bad idea</a> on a mailing list several years ago.
The most important part is quoted below, but you should really read the whole message to get the full picture:</p>
<blockquote>
<p>Signing each commit is totally stupid.
It just means that you automate it, and you make the signature worth less.
It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need one signature to make all the commits reachable from that one be effectively covered by that one.
So signing each commit is simply missing the point.</p>
</blockquote>
<p><del>Git doesn't provide a way to automatically sign every commit, although you could use a bash alias or something similar to make signing semi-automatic.</del></p>
<p>Update: Since Git 2.0 it is possible to configure Git to sign all your commits using the <a href="https://git-scm.com/docs/git-config#Documentation/git-config.txt-commitgpgSign" title="Git config: commit.gpgsign">commit.gpgsign</a> option.</p>
<div class="footer"><hr><p>Thanks for subscribing to my feed!</p><p>Feel free to e-mail comments or corrections to <a href="mailto:vic@demuzere.be?subject=RE%3A%20How%20to%20sign%20your%20project%27s%20git%20history">vic@demuzere.be</a>.</p></div>]]></content></entry><entry><id>https://vic.demuzere.be/articles/pgp-public-keys/</id><title>Verifying the identity behind a PGP public key</title><link href="https://vic.demuzere.be/articles/pgp-public-keys/" rel="alternate" /><updated>2024-11-11T17:39:14+00:00</updated><published>2015-01-22T18:44:00+00:00</published><content type="html"><![CDATA[<p>Your PGP keyring contains public keys that <strong>claim</strong> to represent someone you know. Getting those keys there is easy: using the keyserver network, they can be downloaded right from your PGP client! Lots of people publish their keys on their website as well. But how do you know for sure that <em>a certain key really represents a certain person</em>? I could create a public key using your name and e-mail address, <em>nobody keeps me from doing that</em>.</p>
<h2 id="signing-public-keys">Signing public keys<a href="#signing-public-keys" aria-label="Link to heading 'Signing public keys'" data-heading-content="Signing public keys" class="anchor"></a></h2>
<p>The GPG software allows you to sign other public keys, similar to how you can sign messages or basically any kind of data. Signing a public key however, <em>has a special meaning</em>. You declare that that, according to you, the key you've signed is real and really represents the listed person or organisation.</p>
<p>There are four signature levels:</p>
<ul>
<li>Level 0 signature: <strong>no indication</strong>. This is the default level and is usually used by people who don't know or don't care about signature levels. A lot of people don't specify the signature level when they sign public keys, so there is no reason to discard these right away.</li>
<li>Level 1 signature: <strong>personal belief but no verification</strong>. As the name says this level is used when someone signs a key but was unable to verify the identity. Used for nicknames, most of the time, as you can't really prove the identity behind a pseudonym. Be careful when you encounter a level 1 signature on a key with a full name and e-mail address. These levels have to be specified manually, if someone changes it to level 1, it might be for a reason.</li>
<li>Level 2 signature: <strong>casual verification</strong>: These signatures usually mean that people have met and checked identification, but didn't know each other upfront.</li>
<li>Level 3 signature: <strong>extensive verification</strong>: The level used when the signer was absolutely sure that the listed name is correct. Usually this means that they have known each other in person for years and have checked government issues identification.</li>
</ul>
<p>Note that this is the theory. The signature level names (indicated above) are listed in the <a href="https://gnupg.org/documentation/manuals/gnupg/" title="GPG manpage">GPG documentation</a>. The explanation of these levels is unclear and usually very personal. People use them in different ways, and some even have a webpage explaining what their levels mean. And then there's the huge group that only uses level 0 signatures. So in the end, they're just a vague indication.</p>
<p>If you are able to verify the owner of a public key, sign their public key. Most graphical frontends for PGP have an easy way to do this, the command below signs a key using the command line:</p>
<pre><code>$ gpg --sign-key &lt;name&gt;
</code></pre>
<p>But why are these signatures important?</p>
<h2 id="introducing-the-web-of-trust">Introducing the Web of Trust<a href="#introducing-the-web-of-trust" aria-label="Link to heading 'Introducing the Web of Trust'" data-heading-content="Introducing the Web of Trust" class="anchor"></a></h2>
<p>You can't know everyone, that's just impossible. I am aware that some people claim to have thousands of friends on social networks, but seriously? However, the people that you know may overlap with the ones I know. What is the easiest solution when you need someone's phone number but have no means to communicate? Ask a mutual friend! And that's how the Web of Trust works.</p>
<p>Let's say that you have a personal friend <a href="https://en.wikipedia.org/wiki/Alice_and_Bob" title="Alice and Bob">Alice</a> and want to send an encrypted message to Bob. You met Bob on an online message board and don't know him in person. You could ask Bob to verify the fingerprint of his public key, but someone might be tampering with the connection. It's possible to verify the identity of an internet stranger without meeting him, but it's pretty hard.</p>
<p>Fortunately Alice knows Bob in person, and we are able to verify Alice's key as we can meet her. We could use encrypted and signed communication to ask Alice if the key we have for Bob is correct. But if Alice has signed Bob's key, we don't even have to talk to her! As we trust Alice and her signatures, we are assured that Bob's key is correct.</p>
<pre><code>You --&gt; Alice --&gt; Bob
</code></pre>
<p>The more keys you sign and the more people sign yours, the easier it becomes to identify the correct public keys for other people. So when you meet someone that uses PGP, attempt to sign each other's keys. And <strong>never sign a key if you are not sure about the person's identity</strong>. The strength of the web of trust is your responsibility.</p>
<h2 id="trust-levels">Trust levels<a href="#trust-levels" aria-label="Link to heading 'Trust levels'" data-heading-content="Trust levels" class="anchor"></a></h2>
<p>Similar to signature levels, PGP also has a concept called trust levels. You can assign <em>trust</em> to keys in your keyring. This level indicates how much you trust a person's ability to sign other keys.</p>
<p>There are 5 levels:</p>
<ul>
<li><strong>Unknown</strong>: The default level for keys.</li>
<li><strong>None</strong>: These signatures are ignored completely when calculating the web of trust. Use this when you think someone is not able to make trustworthy signatures.</li>
<li><strong>Marginal</strong>: You have marginal trust in the owner of this key, but don't believe them if they're the only one signing a key. Their signatures are accepted if multiple marginally trusted keys sign the same public key. This level will probably be used the most in your keyring.</li>
<li><strong>Full</strong>: You trust the owner of this key completely. When this person signs a public key, the software trusts that signature as if you have signed it yourself.</li>
<li><strong>Ultimate</strong>: Use this level for your own keys.</li>
</ul>
<p>To modify the trust level of a key using the command line, edit keys in interactive mode and use the <code>trust</code> command:</p>
<pre><code>$ gpg –edit-key &lt;name&gt;
trust
</code></pre>
<p>Combine these levels with the Web of Trust, and you have a way to select the correct public key for people around the world.</p>
<h2 id="keysigning-parties">Keysigning parties<a href="#keysigning-parties" aria-label="Link to heading 'Keysigning parties'" data-heading-content="Keysigning parties" class="anchor"></a></h2>
<p>As you know by now, the strength of the web of trust depends on the number of signatures. Arranging to meet with people one by one takes a lot of time and may be costly, as transportation is not free. That's why people organise <em>keysigning parties</em>. Don't get your hopes up, they're not as fun as they sound.</p>
<p>During these parties people verify each other's keys. Some of these are pretty well organised and require you to register upfront, they then publish an easy to use list of participants and their fingerprints. Smaller parties may require you to bring printed fingerprints yourself. While it may get boring after a while, especially when there are a lot of participants, it's a great time to talk to security-minded people too!</p>
<h2 id="local-signing">Local signing<a href="#local-signing" aria-label="Link to heading 'Local signing'" data-heading-content="Local signing" class="anchor"></a></h2>
<p>Just a note.. In case you <em>really</em> want to sign a key that you can't verify, use local signing. This works the same, but indicates that the signature shouldn't be shared with others. Local signatures never leave your own keyring and thus don't influence the Web of Trust.</p>
<pre><code>$ gpg -lsign-key &lt;name&gt;
</code></pre>
<div class="footer"><hr><p>Thanks for subscribing to my feed!</p><p>Feel free to e-mail comments or corrections to <a href="mailto:vic@demuzere.be?subject=RE%3A%20Verifying%20the%20identity%20behind%20a%20PGP%20public%20key">vic@demuzere.be</a>.</p></div>]]></content></entry></feed>