Signature Verification Mismatches

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Signature Verification Mismatches

duplicity-talk mailing list
Duplicity appears to accept and use multiple different signature identifiers for the same key.  I have one key that can be identified with the following three signature identifiers.  Running signed backups using any of these three signature identifiers will work.

13E613A2
3EB1015313E613A2
8CB6F8488D1434DC0AA7F9143EB1015313E613A2

But when I use either the shortest or the longest of the identifiers, I get an error message like the following when I run a restore command (this is the message when using the longest signature identifier).

Volume was signed by key 3EB1015313E613A2, not 8CB6F8488D1434DC0AA7F9143EB1015313E613A2


This was a very confusing message that took me a long time to debug.  After finding the discussion thread at (http://lists.nongnu.org/archive/html/duplicity-talk/2016-11/msg00025.html), I started debugging the duplicity code and I found that I could make the longest key signature identifier work if I changed gpg.py:293 in duplicity 0.7.11 from:

match = re.search("^\\[GNUPG:\\] GOODSIG ([0-9A-F]*)",
                  status_buf, re.M)

to:

match = re.search("^\\[GNUPG:\\] VALIDSIG ([0-9A-F]*)",
                   status_buf, re.M)

But this change broke the case of using the medium length 16 character key signature identifier so I don't know what the best fix is.  But it seems like there should be some way to canonicalize all the key signature identifiers into one form so that all signature identifiers can work without incorrectly outputting the "Volume was signed by key" error message.


Andrew

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Signature Verification Mismatches

duplicity-talk mailing list
As I said in that thread you linked, I think the correct thing to do is to consult the gpg binary of the full form of the signature, and to normalize the fingerprint into the longest form possible so there is no ambiguity. 

I haven't looked at the code to see how this can be implemented, but `gpg2 --list-secret-keys --fingerprint --with-colons <FINGERPRINT>` seems to be an easily parseable format to get the full form fingerprint.

~Mark 
On Mar 2, 2017, at 15:45, Andrew, trash nothing! founder via Duplicity-talk <[hidden email]> wrote:

Duplicity appears to accept and use multiple different signature identifiers for the same key.  I have one key that can be identified with the following three signature identifiers.  Running signed backups using any of these three signature identifiers will work.

13E613A2
3EB1015313E613A2
8CB6F8488D1434DC0AA7F9143EB1015313E613A2

But when I use either the shortest or the longest of the identifiers, I get an error message like the following when I run a restore command (this is the message when using the longest signature identifier).

Volume was signed by key 3EB1015313E613A2, not 8CB6F8488D1434DC0AA7F9143EB1015313E613A2


This was a very confusing message that took me a long time to debug.  After finding the discussion thread at (http://lists.nongnu.org/archive/html/duplicity-talk/2016-11/msg00025.html), I started debugging the duplicity code and I found that I could make the longest key signature identifier work if I changed gpg.py:293 in duplicity 0.7.11 from:

match = re.search("^\\[GNUPG:\\] GOODSIG ([0-9A-F]*)",
                  status_buf, re.M)

to:

match = re.search("^\\[GNUPG:\\] VALIDSIG ([0-9A-F]*)",
                   status_buf, re.M)

But this change broke the case of using the medium length 16 character key signature identifier so I don't know what the best fix is.  But it seems like there should be some way to canonicalize all the key signature identifiers into one form so that all signature identifiers can work without incorrectly outputting the "Volume was signed by key" error message.


Andrew
_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Signature Verification Mismatches

duplicity-talk mailing list
See bug #1670151.  It's in the works.

...Ken


On Fri, Mar 3, 2017 at 3:30 PM, Mark Grandi via Duplicity-talk <[hidden email]> wrote:
As I said in that thread you linked, I think the correct thing to do is to consult the gpg binary of the full form of the signature, and to normalize the fingerprint into the longest form possible so there is no ambiguity. 

I haven't looked at the code to see how this can be implemented, but `gpg2 --list-secret-keys --fingerprint --with-colons <FINGERPRINT>` seems to be an easily parseable format to get the full form fingerprint.

~Mark 
On Mar 2, 2017, at 15:45, Andrew, trash nothing! founder via Duplicity-talk <[hidden email]> wrote:

Duplicity appears to accept and use multiple different signature identifiers for the same key.  I have one key that can be identified with the following three signature identifiers.  Running signed backups using any of these three signature identifiers will work.

13E613A2
3EB1015313E613A2
8CB6F8488D1434DC0AA7F9143EB1015313E613A2

But when I use either the shortest or the longest of the identifiers, I get an error message like the following when I run a restore command (this is the message when using the longest signature identifier).

Volume was signed by key 3EB1015313E613A2, not 8CB6F8488D1434DC0AA7F9143EB1015313E613A2


This was a very confusing message that took me a long time to debug.  After finding the discussion thread at (http://lists.nongnu.org/archive/html/duplicity-talk/2016-11/msg00025.html), I started debugging the duplicity code and I found that I could make the longest key signature identifier work if I changed gpg.py:293 in duplicity 0.7.11 from:

match = re.search("^\\[GNUPG:\\] GOODSIG ([0-9A-F]*)",
                  status_buf, re.M)

to:

match = re.search("^\\[GNUPG:\\] VALIDSIG ([0-9A-F]*)",
                   status_buf, re.M)

But this change broke the case of using the medium length 16 character key signature identifier so I don't know what the best fix is.  But it seems like there should be some way to canonicalize all the key signature identifiers into one form so that all signature identifiers can work without incorrectly outputting the "Volume was signed by key" error message.


Andrew
_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk



_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk