Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key

[anarcat]

Control: tags -1 +confirmed -help +pending

On Fri, Jan 24, 2014 at 09:24:42PM +0100, Emilien Klein wrote:
> When trying to sign this particular key (2BEF0A33), I get the error message 
> that the key is expired.
> This key is not expired
> I've been in contact with the key owner, who acknoledged that one ID had 
> indeed been revoqued, but that the main key is still active.

On Sat, Jan 25, 2014 at 06:08:20PM +0100, Andreas Rütten wrote:
> I can confirm this behaviour with this two keys:
> 
> pub  4096R/29299233 2011-11-11
>Fingerprint=4B84 4C8F B6EB 4194 29F5  EBEC 5764 07A6 2929 9233 

Thanks. I have added that key to our test rig and wrote a unit test that
confirms the problem:

https://0xacab.org/monkeysphere/monkeysign/commit/03fc176fe804fe96b3c4ccd9ffcafaf0350b0c10

On Sat, Jul 16, 2016 at 05:31:15PM -0400, Jerome Charaoui wrote:
> tag patch
> thanks
> 
> This ugly little patch appears to fix the problem for me.

... and I have merged jerome's patch which fixes the failed unit test
here:

https://0xacab.org/monkeysphere/monkeysign/commit/65a986bf66b9c81cc13ab3cd51fda5a84121b01f

This will be fixed in the next upload.

Thank you for your patience and detailed reports.

A.


signature.asc
Description: Digital signature

Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key

[Antoine Beaupré]

On 2016-08-01 18:09:00, Antoine Beaupré wrote:
> On 2016-08-01 18:01:41, Jerome Charaoui wrote:
>> Le 2016-08-01 à 17:55, Antoine Beaupré a écrit :
>>> On 2016-07-16 18:57:10, Jerome Charaoui wrote:
 Alas, the previous patch is insufficient as monkeysign halts on a
 KEYEXPIRED error which occurs later on, probably when it's attempting to
 cleanup uids.

 I'm pondering whether we should instead patch expect_pattern() to always
 ignore KEYEXPIRED and SIGEXPIRED messages.

 Would this be detrimental in other keysigning scenarios?
>>> 
>>> I don't know.
>>> 
>>> I wonder if the simplest approach here would simply be to avoid
>>> exporting / importing expired material...
>>
>> That approach would indeed be simpler, however it would make monkeysign
>> useless when used on keys which have an expired subkey, which imo is not
>> an insignificant subset of keys.
>
> I meant filtering out expired subkeys.
>
>> Furthermore, according to GPG's own documentation, the KEYEXPIRED is not
>> a useful status message:
>> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS;h=645814a4c1fa8e8e735850f0f93b17617f60d4c8;hb=refs/heads/STABLE-BRANCH-2-0#l367
>
> Madness. But yeah, this does seem to say KEYEXPIRED should be ignored...

Another approach here was implemented by the geysigning people, which
should be considered:

https://github.com/muelli/geysigning/commit/5d672f643b7399ce8ab34528ca3ec7a1b0eb5ffb

I wonder if that would be sufficient?

A.

-- 
The greatest crimes in the world are not committed by people breaking
the rules but by people following the rules. It's people who follow
orders that drop bombs and massacre villages.
- Bansky

Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key

[Antoine Beaupré]

On 2016-08-01 18:01:41, Jerome Charaoui wrote:
> Le 2016-08-01 à 17:55, Antoine Beaupré a écrit :
>> On 2016-07-16 18:57:10, Jerome Charaoui wrote:
>>> Alas, the previous patch is insufficient as monkeysign halts on a
>>> KEYEXPIRED error which occurs later on, probably when it's attempting to
>>> cleanup uids.
>>>
>>> I'm pondering whether we should instead patch expect_pattern() to always
>>> ignore KEYEXPIRED and SIGEXPIRED messages.
>>>
>>> Would this be detrimental in other keysigning scenarios?
>> 
>> I don't know.
>> 
>> I wonder if the simplest approach here would simply be to avoid
>> exporting / importing expired material...
>
> That approach would indeed be simpler, however it would make monkeysign
> useless when used on keys which have an expired subkey, which imo is not
> an insignificant subset of keys.

I meant filtering out expired subkeys.

> Furthermore, according to GPG's own documentation, the KEYEXPIRED is not
> a useful status message:
> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS;h=645814a4c1fa8e8e735850f0f93b17617f60d4c8;hb=refs/heads/STABLE-BRANCH-2-0#l367

Madness. But yeah, this does seem to say KEYEXPIRED should be ignored...

a.
-- 
Toute mère doit être mère par choix.
Tout enfant doit être un enfant désiré.
 - Henry Morgentaler

Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key

[Jerome Charaoui]

Le 2016-08-01 à 17:55, Antoine Beaupré a écrit :
> On 2016-07-16 18:57:10, Jerome Charaoui wrote:
>> Alas, the previous patch is insufficient as monkeysign halts on a
>> KEYEXPIRED error which occurs later on, probably when it's attempting to
>> cleanup uids.
>>
>> I'm pondering whether we should instead patch expect_pattern() to always
>> ignore KEYEXPIRED and SIGEXPIRED messages.
>>
>> Would this be detrimental in other keysigning scenarios?
> 
> I don't know.
> 
> I wonder if the simplest approach here would simply be to avoid
> exporting / importing expired material...

That approach would indeed be simpler, however it would make monkeysign
useless when used on keys which have an expired subkey, which imo is not
an insignificant subset of keys.

Furthermore, according to GPG's own documentation, the KEYEXPIRED is not
a useful status message:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS;h=645814a4c1fa8e8e735850f0f93b17617f60d4c8;hb=refs/heads/STABLE-BRANCH-2-0#l367

-- Jerome



signature.asc
Description: OpenPGP digital signature

Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key

[Antoine Beaupré]

On 2016-07-16 18:57:10, Jerome Charaoui wrote:
> Alas, the previous patch is insufficient as monkeysign halts on a
> KEYEXPIRED error which occurs later on, probably when it's attempting to
> cleanup uids.
>
> I'm pondering whether we should instead patch expect_pattern() to always
> ignore KEYEXPIRED and SIGEXPIRED messages.
>
> Would this be detrimental in other keysigning scenarios?

I don't know.

I wonder if the simplest approach here would simply be to avoid
exporting / importing expired material...

a.

-- 
À force de ne jamais réfléchir, on a un bonheur stupide
- Jean Cocteau

Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key

[Jerome Charaoui]

Please review the attached patch.

-- jerome
From b1cc212bcfc4903c70f1150d83b3b376cee19fdf Mon Sep 17 00:00:00 2001
From: Jerome Charaoui 
Date: Tue, 19 Jul 2016 15:01:45 -0400
Subject: [PATCH] Ignore irrelevant gpg errors (closes #736548)

This will allow the expect_pattern() to skip gpg
errors which are not useful: KEYEXPIRED, SIGEXPIRED
and "gpg: moving a key signature to the correct place"

For descriptions of these errors, see GnuPG
documentation in doc/DETAILS
---
 monkeysign/gpg.py | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/monkeysign/gpg.py b/monkeysign/gpg.py
index 456cf3b..bc5661f 100644
--- a/monkeysign/gpg.py
+++ b/monkeysign/gpg.py
@@ -224,8 +224,17 @@ class Context():
 
 this therefore looks only at the next line, but may also hang
 like seek_pattern()
+
+if the beginning of the line matches a pattern which is
+being ignored, it will skip it and look at the next line
 """
 line = fd.readline()
+ignored = ('[GNUPG:] KEYEXPIRED', '[GNUPG:] SIGEXPIRED', 'gpg: ')
+
+while line and line.startswith(ignored):
+if self.debug: print >>self.debug, "SKIPPED:", line,
+line = fd.readline()
+
 match = re.search(pattern, line)
 
 if self.debug:
@@ -469,15 +478,6 @@ class Keyring():
 except GpgProtocolError as e:
 if 'sign_uid.okay' in str(e):
 multiuid = False
-elif '[GNUPG:]' not in str(e):
-# this is not a protocol message, try again but skipping now
-# this was necessary in order to sign Zack's key, as it was spewing:
-# gpg: moving a key signature to the correct place
-# instead of a [GNUGPG:] message
-try:
-multiuid = self.context.seek(proc.stderr, 'GET_BOOL keyedit.sign_all.okay')
-except GpgProtocolError as e:
-raise GpgRuntimeError(self.context.returncode, _('cannot select uid for signing: %s') % e.found().decode('utf-8'))
 else:
 raise GpgRuntimeError(self.context.returncode, _('cannot select uid for signing: %s') % e.found().decode('utf-8'))
 if multiuid:
-- 
2.8.1



signature.asc
Description: OpenPGP digital signature

Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key

[Jerome Charaoui]

Alas, the previous patch is insufficient as monkeysign halts on a
KEYEXPIRED error which occurs later on, probably when it's attempting to
cleanup uids.

I'm pondering whether we should instead patch expect_pattern() to always
ignore KEYEXPIRED and SIGEXPIRED messages.

Would this be detrimental in other keysigning scenarios?

-- Jerome



signature.asc
Description: OpenPGP digital signature

Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key

[Jerome Charaoui]

tag patch
thanks

This ugly little patch appears to fix the problem for me.

Thanks,

-- Jerome
From 818778fb4ed3d288bd03c0d27c452255629e8304 Mon Sep 17 00:00:00 2001
From: Jerome Charaoui 
Date: Sat, 16 Jul 2016 17:18:26 -0400
Subject: [PATCH] Ignore KEYEXPIRED GnuPG error (closes #736548)

Allows us to sign a key which has one or more expired subkeys.
---
 monkeysign/gpg.py | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/monkeysign/gpg.py b/monkeysign/gpg.py
index 456cf3b..5e4e874 100644
--- a/monkeysign/gpg.py
+++ b/monkeysign/gpg.py
@@ -478,6 +478,13 @@ class Keyring():
 multiuid = self.context.seek(proc.stderr, 'GET_BOOL keyedit.sign_all.okay')
 except GpgProtocolError as e:
 raise GpgRuntimeError(self.context.returncode, _('cannot select uid for signing: %s') % e.found().decode('utf-8'))
+elif '[GNUPG:] KEYEXPIRED' in str(e):
+# This is a protocol error but should be ignored,
+# see doc/DETAILS in GnuPG documentation.
+try:
+multiuid = self.context.seek(proc.stderr, 'GET_BOOL keyedit.sign_all.okay')
+except GpgProtocolError as e:
+raise GpgRuntimeError(self.context.returncode, _('cannot select uid for signing: %s') % e.found().decode('utf-8'))
 else:
 raise GpgRuntimeError(self.context.returncode, _('cannot select uid for signing: %s') % e.found().decode('utf-8'))
 if multiuid:
-- 
2.8.1



signature.asc
Description: OpenPGP digital signature

Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key

[sajolida]

If it helps providing more failure scenarios, I can't sign the Tails
signing key from Tails 2.2:


Preparing to sign with this key

pub  [unknown] 4096R/30F80A2C 1287394206 [expiry: 1500995439]
Fingerprint = DF84 1752 B55C D97F DA48  79B2 9E5B 04F4 30F8 0A2C
uid 1  [unknown] sajolida 
sub   4096R/34AD5681 1287394206

Signing the following key

pub  [unknown] 4096R/58ACD84F 1421590671 [expiry: 1484145775]
Fingerprint = A490 D0F4 D311 A415 3E2B  B7CA DBB8 02B2 58AC D84F
uid 1  [unknown] Tails developers (offline long-term identity key)

uid 2  [unknown] Tails developers 
sub   4096R/752A3DB6 1421590835 [expiry: 1484147888]
sub   4096R/56987A65 1421590930 [expiry: 1452522130]
sub   4096R/2F699C56 1421595116 [expiry: 1484147927]


Sign all identities? [y/N] y
Really sign key? [y/N] y
cannot select uid for signing: [GNUPG:] KEYEXPIRED 1452522130

Bug#736548: monkeysign: Reports key is expired, cannot sign on non-expired key

[Felix Dreissig]

I can confirm this as well. However, in my case it looks like it’s the key I’m 
signing with (my key) which has the expired subkeys.

On 2.x, the error message looks different, but the error appears to be the same:

cannot sign: [GNUPG:] KEYEXPIRED timestamp

Regards,
Felix

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736548: monkeysign: Reports key is expired, cannot sign on non-expired key

[Emilien Klein]

Package: monkeysign
Version: 1.1
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***

When trying to sign this particular key (2BEF0A33), I get the error message 
that the key is expired.
This key is not expired
I've been in contact with the key owner, who acknoledged that one ID had indeed 
been revoqued, but that the main key is still active.

I'd appreciate if you could give it a look.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.12-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages monkeysign depends on:
ii  gnupg 1.4.16-1
ii  python2.7.5-5
ii  python-pkg-resources  2.0.2-1

Versions of packages monkeysign recommends:
ii  python-gtk2   2.24.0-3+b1
ii  python-qrencode   1.01-3
ii  python-zbar   0.10+doc-9+b1
ii  python-zbarpygtk  0.10+doc-9+b1

monkeysign suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org