CodeMirror
/
itpol
mirror of
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Edits and a privacy note for keyservers 

Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
This commit is contained in:
Konstantin Ryabitsev 2017-12-11 14:07:21 -05:00
parent f35667dddc
commit 9d61a13f1c
No known key found for this signature in database
GPG Key ID: 34BAB80AF9F247B8
1 changed files with 38 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
developer-security-hygiene.md
View File

@ -7,9 +7,9 @@ Updated: 2017-12-01
This document is aimed at developers working on free software projects. It
covers the following topics:
1. Basic introduction to PGP and Git
2. PGP key best practices
3. Basic workstation security
1. PGP key best practices
2. Basic introduction to PGP and Git
3. Basic workstation security best practices
We use the term "Free" as in "Freedom," but this guide can also be used for
developing non-free or source-available ("Open Source") software. If you write
@ -137,7 +137,7 @@ To verify the signature:
Frequently, encrypted messages are also signed with the sender's own PGP key.
This should be the default whenever using encrypted messaging, as encryption
without authentication is not very meaningful (unless you are a whistleblower
or a secret agent).
or a secret agent and need plausible deniability).
### Understanding Key Identities
@ -176,11 +176,11 @@ not to an impostor (Eve). In PGP, this certainty is called "key validity:"
#### Web of Trust (WoT) vs. Trust on First Use (TOFU)
PGP uses a trust delegation mechanism known as the "Web of Trust." At its
core, this is an attempt to replace the need for centralized Certification
PGP incorporates a trust delegation mechanism known as the "Web of Trust." At
its core, this is an attempt to replace the need for centralized Certification
Authorities of the HTTPS/TLS world. Instead of various software makers
dictating who should be your trusted certification authorities, PGP leaves
this responsibility to each user.
dictating who should be your trusted certifying entity, PGP leaves this
responsibility to each user.
Unfortunately, very few people understand how the Web of Trust works, and even
fewer bother to keep it going. It remains an important aspect of the OpenPGP
@ -196,7 +196,7 @@ trust the changed key or not.
Similarly, the first time you import someone's PGP key, it is assumed to be
trusted. If at any point in the future GnuPG comes across another key with the
same identity, both the previously imported key and the new key will be marked
as invalid and you will need to manually figure out which one to trust.
as invalid and you will need to manually figure out which one to keep.
In this guide, we will be using the TOFU trust model.
@ -315,7 +315,7 @@ An identity is basically in the same format as the "From" field in emails:
You can create new identities, revoke old ones, and change which identity is
your "primary" one at any time. Since the primary identity is shown in all
GnuPG operations, you should pick a name and address that are both
professional and the most likely ones to be used for PGP-enforced
professional and the most likely ones to be used for PGP-protected
communication, such as your work address or the address you use for signing
off on project commits.
@ -343,7 +343,7 @@ correctly.
#### Generate the master key
To generate your new master key, issue the following command, putting in the
right values instead of Alice Engineer:
right values instead of "Alice Engineer:"
$ gpg --quick-generate-key 'Alice Engineer <alice@example.org>' rsa4096 cert
@ -368,14 +368,15 @@ You should avoid using 8-character "short key IDs" as they are not
sufficiently unique.
At this point, I suggest you open a text editor, copy the fingerprint of your
new key and paste it there. You'll need to use it for the next few steps.
new key and paste it there. You'll need to use it for the next few steps, so
having it close by will be handy.
#### Back up your master key
For disaster recovery purposes -- and especially if you intend to use the Web
of Trust and collect key signatures from other project developers -- you
should create a hardcopy backup of your private key. This is supposed to be a
"last resort" measure in case all other backup mechanisms have failed.
should create a hardcopy backup of your private key. This is supposed to be
the "last resort" measure in case all other backup mechanisms have failed.
The best way to create a printable hardcopy of your private key is using the
`paperkey` software written for this very purpose. Paperkey is available on
@ -388,14 +389,14 @@ key:
The output will be in a format that is easy to OCR or input by hand, should
you ever need to recover it. Print out that file, then take a pen and write
the key passphrase on the margin of the paper. This is a required step because
the key printout is still encrypted with the passphrase, and if you ever
change the passphrase on your key, you will not remember what it used to be
when you had first created it -- *guaranteed*.
the key passphrase on the margin of the paper. **This is a required step**
because the key printout is still encrypted with the passphrase, and if you
ever change the passphrase on your key, you will not remember what it used to
be when you had first created it -- *guaranteed*.
Put the resulting printout and the hand-written passphrase into an envelope
and store in a secure and well-protected place that is away from your home,
such as your bank vault.
and store in a secure and well-protected place, preferably away from your
home, such as your bank vault.
**NOTE ON PRINTERS**: Long gone are days when printers were dumb devices
connected to your computer's parallel port. These days they have full
@ -482,6 +483,20 @@ that is most likely to work:
Most keyservers communicate with each-other, so your key information will
eventually synchronize to all the others.
**NOTE ON PRIVACY:** Keyservers are completely public and therefore, by
design, leak potentially private information about you, such as your full
name, nicknames, and personal or work email addresses. If you sign other
people's keys or someone signs yours, keyservers will additionally become
leakers of your social connections. Once such personal information makes it to
the keyservers, it becomes impossible to edit or delete. Even if you revoke a
signature or identity, that does not delete them from your key record, just
marks them as revoked -- making them stand out even more.
That said, if you participate in software development on a public project, all
of the above information is already public record, and therefore making it
additionally available via a keyserver record does not result in net loss in
privacy.
##### Upload your public key to GitHub
If you use GitHub in your development (and who doesn't?), you should upload
@ -524,7 +539,7 @@ we did with `paperkey`).
#### Prepare detachable encrypted storage
Start by getting a small USB "thumb" drive (preferably two) that you will use
Start by getting a small USB "thumb" drive (preferably two!) that you will use
for backup purposes. You will first need to encrypt them:
- [Apple instructions](https://support.apple.com/kb/PH25745)
@ -550,7 +565,8 @@ You should now test to make sure it still works:
If you don't get any errors, then you should be good to go. Unmount the USB
drive, distinctly label it so you don't blow it away next time you need to use
a random USB drive, and put in a safe place -- but not too far away, because
you'll need to use it every now and again.
you'll need to use it every now and again for things like adding identities,
extra subkeys, or adding signatures to other people's keys.
#### Remove the master key