Showing posts with label gpg. Show all posts
Showing posts with label gpg. Show all posts

Monday, 8 October 2012

HOWTO fix git-buildpackage signs with wrong signature

If you have two or more available gpg keys that can be used for the same identity (e.g.: 'John Doe <john@doe.com>') that you might use to add entries to changelogs of packages, you might end up in situations where git-buildpackage or other similar tool might want to sign packages with the wrong key.

It seems debsign (the tool that actually does the signing) just picks up the first key that is still valid (I also have a revoked key) and matches the used identity.

There are many ways to fix this, but the one that will work for most cases is to run this command:

echo 'DEBSIGN_KEYID=0x0123ABCD' >> ~/.devscripts

Of course, you should replace  0x0123ABCD with the keyid which you prefer.

This will create a ~/.devscripts file (if it didn't exist) which will contain the DEBSIGN_KEY variable with the desired value. This file will be sourced by debsign before doing its actual work, so it will do the right thing when ran.

There are also git-buildpackage specific fixes like defining builder in the [DEFAULT] section of ~/.gbp.conf and passing '-k0x0123ABCD' to debuild something like:

[DEFAULT]
builder = debuild -i -I -k1234ABCD
...

But that probably gets ugly if you use a custom builder.


P.S.: I have just deleted my old key 0xDD1F1F9F since I won't be using it anymore. I don't remember where I put the revocation certificate, but I'll revoke the key, once and if I find the revocation certificate. Otherwise, it will expire in July, next year.

From now on, I am going to use only the key 0xE3E083A1 to which I even added a photo and some newer identities and updated with a few signatures I got during DebConf 9.

Tuesday, 4 November 2008

signing packages heads-up

When trying to sign some Debian packages fails, you might think that temporally changing LANG to find similar errors on the web is a good idea.

But when you see that the expired key is not the default one and you made sure that the GPG agent environment info is correct, while signing still fails, you might start to consider that bad rendering of the "s comma below" character in your name might be worth taking into account.


gpg: skipped "Eddy Petrișor ": secret key not available


Also, remembering that LC_MESSAGES=C is the right way to have English messages, while preserving all the rest of the localization info, is also useful.

Wednesday, 16 July 2008

OH MY GOD!

This can't be true! How can someone trust such a key?

Does anybody have a reasonable explanation for such an abomination?



Update: It seems it is unclear to some people what is the problem with this key. There are multiple identities (apparently different people) for the same key. So, in layman's terms, multiple different people are using exactly the same key to certify their identity.

I really don't understand how this could work in real life. Maybe is a case of misunderstanding what gpg is about?

Sunday, 29 June 2008

when printouts don't help to revoke a GPG key

It's official, I am revoking my gpg key because after my laptop returned from service[1] I realized is a bad idea to change the passphrase just before a long break away from a routine that would help the brain to cement the new passphrase. In other words, I forgot the passphrase.

So, let's get the revocation certificate printout and revoke that gpg and generate a new one. All is good and fine until you realize that „I” (capital i) and „l” (low case „L”) look very much the same on paper. Oops!

So, what do you do? How many „I/l”-s are there in the certificate? Let's find out...


0 eddy@bounty ~/tmp/revoke $ cat template
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: A revocation certificate should follow

iEkEIBECAAkFAkbYOQUCHQIACgkQY8Chqv3NRNquGgCgxdMDrhycNcoJsaeeg7hk
8vVJZzsAnRicsfjcZnUtmLIsys6KK48FbJ4h
=I5o9
-----END PGP PUBLIC KEY BLOCK-----


Well, I'm not going to count, I'll remove the header and footer and see from there...

0 eddy@bounty ~/tmp/revoke $ cat template.in | tr -d '[a-zA-HJ-Z0-9=]'
II
I
I


Ok, so we have 16 possible combinations, not that many.

0 eddy@bounty ~/tmp/revoke $ for i in l I ; do for j in l I ; do for k in l I ; do for l in l I ; do cat template.in | sed -e "s#I#$i#" -e "s#I#$j#" -e "s#I#$k#" -e "s#I#$l#" > $i$j$k$l.mid ; done ; done ; done ; done
0 eddy@bounty ~/tmp/revoke $ md5sum *.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIII.mid
63a9dd10e381b8ff5c758ab3467a5c45 IIIl.mid
63a9dd10e381b8ff5c758ab3467a5c45 IIlI.mid
919d8494c9990c68f50bc9df61f269bc IIll.mid
63a9dd10e381b8ff5c758ab3467a5c45 IlII.mid
919d8494c9990c68f50bc9df61f269bc IlIl.mid
919d8494c9990c68f50bc9df61f269bc IllI.mid
919d8494c9990c68f50bc9df61f269bc Illl.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIII.mid
919d8494c9990c68f50bc9df61f269bc lIIl.mid
919d8494c9990c68f50bc9df61f269bc lIlI.mid
919d8494c9990c68f50bc9df61f269bc lIll.mid
919d8494c9990c68f50bc9df61f269bc llII.mid
919d8494c9990c68f50bc9df61f269bc llIl.mid
919d8494c9990c68f50bc9df61f269bc lllI.mid
919d8494c9990c68f50bc9df61f269bc llll.mid


Oops, that's not ok... I guess I've been replacing some of the characters more than once.

Take 2:
0 eddy@bounty ~/tmp/revoke $ for i in l I ; do for j in l I ; do for k in l I ; do for l in l I ; do cat template.in | tr 'Il' '-'| sed -e "s#-#$i#" -e "s#-#$j#" -e "s#-#$k#" -e "s#-#$l#" > $i$j$k$l.mid ; done ; done ; done ; done
0 eddy@bounty ~/tmp/revoke $ md5sum *.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIII.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIIl.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIlI.mid
eab3a5e312bc0314ac2b3d4536bda2f6 IIll.mid
7150fa775c83c276223a30d373671333 IlII.mid
7150fa775c83c276223a30d373671333 IlIl.mid
7150fa775c83c276223a30d373671333 IllI.mid
7150fa775c83c276223a30d373671333 Illl.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIII.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIIl.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIlI.mid
63a9dd10e381b8ff5c758ab3467a5c45 lIll.mid
919d8494c9990c68f50bc9df61f269bc llII.mid
919d8494c9990c68f50bc9df61f269bc llIl.mid
919d8494c9990c68f50bc9df61f269bc lllI.mid
919d8494c9990c68f50bc9df61f269bc llll.mid


Oops, that's not good either. Doh, sed works on lines.

Take 3:

Make a one line out of the template and try again:

0 eddy@bounty ~/tmp/revoke $ cat template.in
iEkEIBECAAkFAkbYOQUCHQIACgkQY8Chqv3NRNquGgCgxdMDrhycNcoJsaeeg7hk8vVJZzsAnRicsfjcZnUtmLIsys6KK48FbJ4h=I5o9

0 eddy@bounty ~/tmp/revoke $ for i in l I ; do for j in l I ; do for k in l I ; do for l in l I ; do cat template.in | tr 'I' '-' | tr 'l' '-' | sed -e "s#-#$i#" -e "s#-#$j#" -e "s#-#$k#" -e "s#-#$l#" > $i$j$k$l.mid ; done ; done ; done ; done
0 eddy@bounty ~/tmp/revoke $ md5sum *.mid
66ab0a0bed219db8499debabb9a41c0b IIII.mid
e02c1751c4491ce5db1ebe9e64d8eadc IIIl.mid
c96a33f821d3fba84f655aa986084320 IIlI.mid
998c5c4219a5afdd77f82c9fc9818f6f IIll.mid
e08fe6c5380765d12c4f5e4090a7d9c6 IlII.mid
24241b58c231900b02ebb0410183983e IlIl.mid
72040a77e7cca9a91abf2bb0d51c00dd IllI.mid
a02e8645f3593f5c3549b49adef04bc2 Illl.mid
99a1a47c853ed760ef1f58cba7b75916 lIII.mid
c48bf75f30be46ec576a46a1d5664a93 lIIl.mid
717e9dfdc0d3fba973ba66ccb57d69dc lIlI.mid
3e9a2c937fd269d85c09b449b4da17de lIll.mid
4d283333d1d62086328dbc72425a645d llII.mid
542a7c00e99aad5137975581e57a92c9 llIl.mid
ef0e0a2daad7a933b620331a86455c23 lllI.mid
bdf852887308830475a506f8daad9624 llll.mid


That's better. Now let's put those lines back in place:

0 eddy@bounty ~/tmp/revoke $ for I in *.mid ; do cat $I | sed -e 's#\(eeg7hk\)#\1-#' -e 's#\(K48FbJ4h\)#\1-#' | tr '-' '\n' > $I.good ; done


And revoke that key...

0 eddy@bounty ~/tmp/revoke $ for I in *.mid.good ; do echo "$I:" && (cat header $I footer) > template && gpg --import -a template ; done
IIII.mid.good:
gpg: CRC error; 73689A - 239A3D
gpg: read_block: read error: invalid keyring
gpg: import from `template' failed: invalid keyring
gpg: Total number processed: 0
IIIl.mid.good:
gpg: CRC error; 73689A - 979A3D
gpg: read_block: read error: invalid keyring
gpg: import from `template' failed: invalid keyring
gpg: Total number processed: 0
IIlI.mid.good:
gpg: key FDCD44DA: "Eddy Petrișor
" revocation certificate imported
gpg: Total number processed: 1
gpg: new key revocations: 1
gpg: public key 67D8E867 is 987014 seconds newer than the signature
gpg: public key 67D8E867 is 987014 seconds newer than the signature
gpg: public key 67D8E867 is 987029 seconds newer than the signature
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 2 signed: 139 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1 valid: 139 signed: 667 trust: 138-, 0q, 0n, 1m, 0f, 0u
gpg: next trustdb check due at 2008-10-09
IIll.mid.good:
gpg: CRC error; 239A3D - 979A3D
gpg: read_block: read error: invalid keyring
gpg: import from `template' failed: invalid keyring
gpg: Total number processed: 0


Cool!


[1] I know is almost a half a year, but I've been busy and hoping