Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use GnuPG status-fd codes to determine signature validity. #149

Closed
wants to merge 2 commits into from

Conversation

isislovecruft
Copy link
Contributor

  • ADDS two compiled regexes, launcher.gnupg_goodsig_pattern and
    launcher.gnupg_validsig_pattern.
  • CHANGE the signature validity check in Launcher.verify() to be more
    robust and accurate.
  • ADD check that the signature was created by the key with fingerprint
    which we expected it to be from.
  • FIXES micahflee#147

NOTE: This patch depends upon some of the changes in my previous patch
for issue #137 (pull request #148) in commit
b337b3d.

Rather than checking the GnuPG process exit code, a more robust way to
handle determining whether or not a GnuPG process behaved as was
intended is to check GnuPG's status-fd output. [0]

In the case of key import, the particular status-fd flag we're looking
for is `IMPORT_OK` followed by a "reason", then the expected
fingerprint. [1]  Because the "reason"s are integers which may be ORed,
and we are never expecting private keys to be within the file, we can
assume the reason to be `[0, 15]` inclusive.

While it's not strictly necessary to hardcode Erinn's key fingerprint
within the code because the keyfiles are safely distributed along with
the source code, doing so adds a simple defense-in-depth mechanism for
the unlikely case that a user's torbrowser-launcher package/source
download was compromised.  As such, and because it was a trivial
addition which will also assist with checking that a signature was made
by the key with the expected fingerprint [2], I've gone ahead and added
a `common.fingerprints` dictionary whose keys match the names of the
`common.paths` keyfile for their respective key (i.e. the fingerprint
for `common.paths['erinn_key']` is stored at
`common.fingerprints['erinn_key']`) in order to facilitate extensibility
in the event that torbrowser-launcher should add new keyfiles in the
future.  This may be removed, if undesirable.

 * ADD `common.gnupg_import_ok_pattern`, a compiled regex for
   determining if a key import was successful.
 * ADD new class attribute, `common.Common.fingerprints` for storing
   fingerprints.
 * ADD new method, `common.Common.import_key_and_check_status()`, which
   imports a GnuPG key, and then checks that the key was successfully
   imported.
 * CHANGE `common.Common.import_keys()` method to make adding
   new/additional keys easier.
 * FIXES torproject#137

[0]: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS;hb=HEAD#l323
[1]: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS;hb=HEAD#l713
[2]: torproject#147
 * ADDS two compiled regexes, `launcher.gnupg_goodsig_pattern` and
   `launcher.gnupg_validsig_pattern`.
 * CHANGE the signature validity check in `Launcher.verify()` to be more
   robust and accurate.
 * ADD check that the signature was created by the key with fingerprint
   which we expected it to be from.
 * FIXES torproject#147

NOTE: This patch depends upon some of the changes in my previous patch
      for issue torproject#137 (pull request torproject#148) in commit
      b337b3d.
@micahflee
Copy link
Collaborator

This looks great. Once you fix the minor issue with #148 I'll merge both of these.

@micahflee micahflee closed this Nov 1, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants