Some commits not signed correctly

[BinaryMuse]

I was talking to @stoe over some 🍸 yesterday and he was telling me about a problem he was having with the GitHub package. He said that every so often, it would fail to sign a commit correctly (but that it works most of the time). This PR demonstrates the issue; note the unverified commit at the bottom.

Indeed, if I import his keys and run git log --show-signature on the commit, I see the following:

commit ef53437417f86065e2b2819ffd43163cf49ce5f1 (HEAD -> mkt-test)
gpg: Signature made Fri Mar 31 05:54:18 2017 PDT
gpg:                using RSA key D0AEA5862192C1EB
gpg: BAD signature from "Stefan Stölzle <stoe@github.com>" [unknown]
Author: Stefan Stölzle <stoe@github.com>
Date:   Fri Mar 31 14:54:18 2017 +0200

    Move badges to H1

commit 9e1b3aa9c0250b7b1847f69f5755af46d05c0f8c
gpg: Signature made Fri Mar 31 05:54:02 2017 PDT
gpg:                using RSA key D0AEA5862192C1EB
gpg: Good signature from "Stefan Stölzle <stoe@github.com>" [unknown]
gpg:                 aka "Stefan Stölzle <stefan@github.com>" [unknown]
gpg:                 aka "Stefan Stölzle <stoelzle@github.com>" [unknown]
gpg:                 aka "[jpeg image of size 4763]" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: FFDD 99D4 E5EE 0CA6 F985  21D9 D0AE A586 2192 C1EB
Author: Stefan Stölzle <stoe@github.com>
Date:   Fri Mar 31 14:54:02 2017 +0200

    Add license badge

commit 9d6e5e4b8c50ab73bdb7dca993ae19f47ebb47ba
gpg: Signature made Fri Mar 31 05:49:43 2017 PDT
gpg:                using RSA key D0AEA5862192C1EB
gpg: Good signature from "Stefan Stölzle <stoe@github.com>" [unknown]
gpg:                 aka "Stefan Stölzle <stefan@github.com>" [unknown]
gpg:                 aka "Stefan Stölzle <stoelzle@github.com>" [unknown]
gpg:                 aka "[jpeg image of size 4763]" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: FFDD 99D4 E5EE 0CA6 F985  21D9 D0AE A586 2192 C1EB
Author: Stefan Stölzle <stoe@github.com>
Date:   Fri Mar 31 14:49:43 2017 +0200

    Use shields.io badge

Note that the top two commits were made only 16 seconds apart.

Here's the full object in question:

$ git cat-file -p ef53437417f86065e2b2819ffd43163cf49ce5f1
tree 441a5b2cf1e0c655bafcbb659e397f57fd027ac3
parent 9e1b3aa9c0250b7b1847f69f5755af46d05c0f8c
author Stefan Stölzle <stoe@github.com> 1490964858 +0200
committer Stefan Stölzle <stoe@github.com> 1490964858 +0200
gpgsig -----BEGIN PGP SIGNATURE-----

 iQIcBAABCAAGBQJY3lF6AAoJENCupYYhksHrvO4QAIdR25S7oA7d/dR1+Y8ebQkQ
 ejbHqcb1t6mvOyxI6HnHyQ5ekmzZJVOhTLJ1b6xsFsAyCKOJk9JvZKmzb5bwPTUp
 o/PR3FfUkT+B0afhwt/VaZtBcSGAToc5ICzsegXQEGiAAVhEM6e8Aph6p1qmGp8R
 6v1T1L4P8C36peENPlCqZB2rIPyiD7X/FQUGvrbT84FaMmh/GuxzR+S05ZvmHZ+e
 vYWskq5aLkLvaR/Tcz22bxWctSqERKbMHpxr6wU2wH2kozp0jmHiKlC5EVx5RCLl
 6zUq89tBIJcRy/r2KTKvB1agxCwXipf5YhAWGzkUgPB7XmWQ+9bJXyOxiRV0Pv9v
 9/NUIgKXcRAsKw1AHcxR2P3Cp5ZnEpdOnzYFL0hvV8HJOsVIa0QwidsJhQE2RT51
 A7D6RESZ4QiEUVgqWPQzlSv+Zh9bkUoOMarwKwzowo6731/ikmthkRL7a4pS3BMr
 RDaVIpv+IKQQw/NWUCE8WeWqrhULfjLIQGlus8p9fQyUUWS6yTcKzGDVvLBhF8fU
 UzIVqfFN+0bjwT7HanJ7MzOO7QIjlhB1MT0EAW/HlucuUR67tB4YMVUmqaqYnEtX
 bIRHObQGO6a1bskPDfiGD6URxNsKvzYFLHsYprw5DONWYyHnDMmpXliScIZsnNv4
 pzlkB4323NRwPxbJ4lbn
 =Si42
 -----END PGP SIGNATURE-----

Move badges to H1

He said that all these commits were made by Atom.

/cc @smashwilson for 💭

[the-j0k3r]

This seems related #846

[rugk]

BTW this is the first time I hear signed commits are possible with Atom's GitHub plugin. Could you explain how to enable it? (Or link to a doc.)

[winstliu]

@rugk you enable it through Git, and the GitHub package just respects your signing settings. https://help.github.com/articles/signing-commits-with-gpg/

[rugk]

Ah, but the issue was, AFAIK, that you cannot enter your password when using the Atom package, was not it?

[smashwilson]

The short answer is that you can... sometimes.

If the version of gpg that git is configured to execute is older than (I think) the 2.1 line, we have a wrapper script that will be used to collect a passphrase through an Atom dialog. If you upgrade gpg, though, it will stop working, because the command-line argument we were using to pass the passphrase to gpg was deprecated and removed.

I've got some work in progress to bundle gpg and gpg-agent binaries and interact with them in a more stable way, by running gpg with an isolated GNUPGHOME and a gpg-agent configured to talk to Atom for pinentry. There are some subtleties to deal with there in terms of how we deal with a native GPG installation, find your keys, and so on that I haven't worked out yet, and it keeps being punted in favor of more urgent stuff.

However! You should always be able to configure gpg and gpg-agent to use a non-tty pinentry program and have that work properly. On my Mac, I use pinentry-mac from homebrew, which prompts graphically, and can store passphrases in the OS keychain as an added convenience. On Windows, gpg4win was bundled with a graphical pinentry that works well from Atom. Linux has a variety of Qt and Gtk-based pinentry programs as well.

[the-j0k3r]

I always use the GPG pinentry (also first to pop up after a cold commit) my installed GPG has been the most modern since GPG 2.2.1 and currently GPG 2.2.7. not the atom one and so far no commit has, anything else fails entirely see #846 (comment) I never get the issue described here at all.

I have not configured GPG/GPG-Aget to use a non-tty pinentry, Im not on a mac though, windows here, maybe that is for UNIX-Like and Linux only?.

Again its always worked using the GPG pinenetry which always pops up first anyway and using atom one, only by forcefully dismissing that, always has failed completely, but again doesnt result in this bug, or ever has.

@stoe What OS and what GPG version are you using, re the last unverified commit in https://github.com/stoelzle/pdfify-node/pull/11 also the only way I know to get that result (unverified commit) is to use another key not associated with the exact GitHub main email or the email used is not part of that key.

☑️ Perhaps something to consider checking if you have more than one email not added to the GPG key in use configured in https://github.com/settings/keys?

⚠️ I think @stoe has many emails not added to the GPG key being used Atested by output ins #1196 (comment), This can be easily corrected and can easily be result in this bug if not done.

[stoe]

I think @stoe has many emails not added to the GPG key being used Atested by output ins #1196 (comment), This can be easily corrected and can easily be result in this bug if not done.

I have two addresses I use for Git, stoe@github.com (for work) and stefan@stoelzle.me (for private projects), for both I have valid GPG keys on GitHub, not sure what I can do to correct it.

[the-j0k3r]

I have two addresses I use for Git, stoe@github.com (for work) and stefan@stoelzle.me (for private projects), for both I have valid GPG keys on GitHub, not sure what I can do to correct it.

Are you sure its 2? I count 4 emails you only claim to have 2 so :humm: weird. You should definitely check it out as a matter of course.

You can add more than one email to the used keys,

3 from the git log

<stoe@github.com> (for work)
<stefan@github.com> (for ?)
<stoelzle@github.com> (for ?)

and the 4th

<stefan@stoelzle.me> (for private projects)

OpenPGP -> Key Management -> [Right-click on your key] -> Manage User IDs
or
Kleopatra -> [Right-click on your key] -> Add User-ID

You can also do it over CLI depending on your environment.

In any case your current configuration maybe tripping over itself because you have 4 emails resulting in issue, This is what I think is going on.

I can tell you that when I setup this I came across this issue because it was improperly configured, hence why I mentioned it as a possible cause

[stoe]

Are you sure its 2? I count 4 emails you only claim to have 2 so :humm: weird. You should definitely check it out as a matter of course.

I use 2 from the commandline/git config, but my GPGs are set up with a total of 5 addresses actually 😼

I don't think it's the number of addresses, but will try and confirm.

[the-j0k3r]

@stoe any news?

[stoe]

Hadn’t been able to test while I was in India the last 3 weeks for an engagement and only had a Chromebook with me that didn’t have the setup.
Might be able to look into it this week, though.

[the-j0k3r]

Hadn’t been able to test while I was in India the last 3 weeks for an engagement

How very nice indeed, :) It must have been a very enjoyable experience.

Only had a Chromebook with me that didn’t have the setup.
Might be able to look into it this week, though.

No problem, Im curious for several related reasons, especially to see the amount of emails that have been shown to be associate vs the number you actually have, could be a small issue in GPG or something.. I keep my versions of Git/Atom/GPG up-to-date and only literally two emails max per key depending on usage.

Anyway enough rambling, this #1373 should be very interesting.

Have a good day and welcome back.