Better signature validation for subkeys.

[jburnham]

I have subkeys that do my signatures however when I set my .git/config gcrypt-participants to the id of the main key, the signing subkey is used when pushing to the repo but when fetching, it fails because it's looking for the main key id. Change the system to validate this by using PGP's VALIDSIG keyword. See this stackoverflow article for more.

See my example output for what I mean.

[root@localhost repo]# gpg --edit-key 477E48E6
gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  1024R/477E48E6  created: 2013-09-19  expires: 2018-09-18  usage: C
                     trust: ultimate      validity: ultimate
sub  1024R/69A0DB38  created: 2013-09-19  expires: 2014-09-19  usage: S
sub  1024R/D7A9D563  created: 2013-09-19  expires: 2014-09-19  usage: E
[ultimate] (1). testing <[email protected]>

[root@localhost repo]# gpg -K
/root/.gnupg/secring.gpg
------------------------
sec   1024R/477E48E6 2013-09-19 [expires: 2018-09-18]
uid                  testing <[email protected]>
ssb   1024R/69A0DB38 2013-09-19
ssb   1024R/D7A9D563 2013-09-19
[root@localhost repo]# git fetch crypted
gcrypt: Development version -- Repository format MAY CHANGE
gcrypt: Decrypting manifest
gpg: anonymous recipient; trying secret key 477E48E6 ...
gpg: anonymous recipient; trying secret key 69A0DB38 ...
gpg: anonymous recipient; trying secret key D7A9D563 ...
gpg: okay, we are the anonymous recipient.
gpg: Signature made Thu 19 Sep 2013 06:36:05 AM UTC using RSA key ID 69A0DB38
gpg: Good signature from "testing <[email protected]>"

##### This is where I add         gcrypt-participants = 477E48E6 to the .git/config "crypted" remote

[root@localhost repo]# git fetch crypted
gcrypt: Development version -- Repository format MAY CHANGE
gcrypt: Decrypting manifest
gpg: anonymous recipient; trying secret key 477E48E6 ...
gpg: anonymous recipient; trying secret key 69A0DB38 ...
gpg: anonymous recipient; trying secret key D7A9D563 ...
gpg: okay, we are the anonymous recipient.
gpg: Signature made Thu 19 Sep 2013 06:36:05 AM UTC using RSA key ID 69A0DB38
gpg: Good signature from "testing <[email protected]>"
gcrypt: Failed to verify manifest signature!
gcrypt: Only accepting signatories:  5BDC6F31477E48E6
gcrypt: Failed to decrypt manifest!

##### This is where I apply the patch in this PR.

[root@localhost repo]# git fetch crypted
gcrypt: Development version -- Repository format MAY CHANGE
gcrypt: Decrypting manifest
gpg: anonymous recipient; trying secret key 477E48E6 ...
can't connect to `/root/.gnupg/S.gpg-agent': No such file or directory
1gpg: anonymous recipient; trying secret key 69A0DB38 ...
gpg: anonymous recipient; trying secret key D7A9D563 ...
gpg: okay, we are the anonymous recipient.
gpg: Signature made Thu 19 Sep 2013 06:36:05 AM UTC using RSA key ID 69A0DB38
gpg: Good signature from "testing <[email protected]>"

This was discovered when using @joeyh's git-annex with the command like "git annex initremote crypted type=gcrypt gitrepo=~/crypt keyid=477E48E6" but tested manually with gcrypt only and adding gcrypt-participants to the .git/config.

[joeyh]

Merged this into my branch, especially since it affects git-annex.

[maertsen]

What is blocking a merge of the patch provided by @jburnham?

I just ran into the issue described in this ticket while using git-remote-gcrypt standalone in combination with a gpg-setup with separate subkeys for signing, encryption.

Please let me know if I can do anything to help out.

(I'm using the Debian package for git-remote-gcrypt as maintained by @joeyh, version 0.20130908-5)

[joeyh]

This is patch introduced a bug, https://github.com/blake2-ppc/git-remote-gcrypt/issues/8

I am waiting on a fixed version that avoids that problem.

[spwhitton]

@joeyh Do you recall the details of the issue report you linked to? Unfortunately, the owner of that repo has deleted the issue tracker and the Wayback Machine doesn't have it. I would like to confirm that the issue does not remain in my fork.

[joeyh]

I don't remember what I was referring to exactly, but here's what github-backup caught about that issue:

joey@elephant:~/lib/backup/github/git-remote-gcrypt/blake2-ppc_git-remote-gcrypt/issue#github>cat 8 Issue {issueClosedAt = Just (GithubDate {fromGithubDate = 2013-09-26 19:55:30 UTC}), issueUpdatedAt = GithubDate {fromGithubDate = 2014-01-02 16:12:36 UTC}, issueEventsUrl = "https://api.github.com/repos/bluss/git-remote-gcrypt/issues/8/events", issueHtmlUrl = Just "https://github.com/bluss/git-remote-gcrypt/issues/8", issueClosedBy = Nothing, issueLabels = [], issueNumber = 8, issueAssignee = Nothing, issueUser = GithubUser {githubOwnerAvatarUrl = "https://avatars.githubusercontent.com/u/16392?v=3", githubOwnerLogin = "joeyh", githubOwnerUrl = "https://api.github.com/users/joeyh", githubOwnerId = 16392, githubOwnerGravatarId = Just ""}, issueTitle = "--fast-list breaks with some keys", issuePullRequest = Nothing, issueUrl = "https://api.github.com/repos/bluss/git-remote-gcrypt/issues/8", issueCreatedAt = GithubDate {fromGithubDate = 2013-09-26 19:43:22 UTC}, issueBody = Just "For reasons I cannot fathom, --fast-list sometimes causes gpg --list-keys --with-colons to leave off the fingerprint line, which git-remote-gcrypt requires in order to use a key.\r\n\r\njoey@darkstar:~>gpg --list-keys --with-colons --fingerprint\r\ntru::1:1380223980:0:3:1:5\r\npub:u:4096:1:84D555DDC4304C6B:2013-09-26:::u:joey's git-annex encryption key::escaESCA:\r\nfpr:::::::::C3E4FAF4CDE260254502EAEB84D555DDC4304C6B:\r\npub:u:1024:1:C5ED1A54380D1F28:2013-09-26:::u:foo key::scESC:\r\nfpr:::::::::6B3D236076AD0D5EAC46E00FC5ED1A54380D1F28:\r\nsub:u:1024:1:FA293162759F5055:2013-09-26::::::e:\r\njoey@darkstar:~>gpg --list-keys --fast-list --with-colons --fingerprint\r\ntru::1:1380223980:0:3:1:5\r\npub::4096:1:84D555DDC4304C6B:2013-09-26::::::escaESCA:\r\npub::1024:1:C5ED1A54380D1F28:2013-09-26::::::scESC:\r\nfpr:::::::::6B3D236076AD0D5EAC46E00FC5ED1A54380D1F28:\r\nsub::1024:1:FA293162759F5055:2013-09-26::::::e:\r\n\r\nI created both these keys today for testing purposes; one was created using gpg's batch mode and the other regular gpg --gen-key. A bunch of test keys that I created earlier using batch mode all show up with fingerprint.\r\n\r\nI am going to work around this in my fork by removing the --fast-list option.", issueState = "closed", issueId = 20131818, issueComments = 1, issueMilestone = Nothing}

joey@elephant:~/lib/backup/github/git-remote-gcrypt/blake2/issue#github>cat 8_comment/25198459 IssueComment {issueCommentUpdatedAt = GithubDate {fromGithubDate = 2013-09-26 19:55:30 UTC}, issueCommentUser = GithubUser {githubOwnerAvatarUrl = "https://avatars.githubusercontent.com/u/16392?v=3", githubOwnerLogin = "joeyh", githubOwnerUrl = "https://api.github.com/users/joeyh", githubOwnerId = 16392, githubOwnerGravatarId = Just ""}, issueCommentUrl = "https://api.github.com/repos/bluss/git-remote-gcrypt/issues/comments/25198459", issueCommentCreatedAt = GithubDate {fromGithubDate = 2013-09-26 19:55:30 UTC}, issueCommentBody = "Apologies.. This bug was introduced by https://github.com/blake2-ppc/git-remote-gcrypt/pull/7 which has not been merged into this repo. That added the requirement that fingerprints be listed, which had not been the case before. I have fixed it in my repo.", issueCommentId = 25198459}

[spwhitton]

Thanks for dredging that up, Joey.

For the record, the commit fixing this is b0174432, present in Joey's fork and in my fork (and so in Debian and Ubuntu).