epg and expired recipient keys

epg and expired recipient keys

[Michael Piotrowski]

Hi,

I've got a recipient for whom there is a current key and an expired
key.  When I'm trying to encrypt a message to this correspondent, epg
picks the expired key (perhaps because its key ID comes alphabetically
first), and then fails because the key has expired.

GnuPG automatically selects the right key to use, and avoids the
expired ones.

If this is a bug in epg, I'd think that someone must have run into it
before--or could this be a local problem?

Thanks and greetings

-- 
Michael Piotrowski, M.A.                               <mxp@dynalabs.de>
Public key at <http://www.dynalabs.de/mxp/pubkey.txt>

Re: epg and expired recipient keys

[Werner Koch]

On Fri, 23 Feb 2007 14:02, mxp@dynalabs.de said:

> GnuPG automatically selects the right key to use, and avoids the
> expired ones.
>
> If this is a bug in epg, I'd think that someone must have run into it
> before--or could this be a local problem?

I had the same problem and discussed this with Ueno.  The reason is
that epg uses --list-keys to get a list of macthing recinpients and
picks the first one.  This is obviously not correct, as it should skip
all revoked and expired keys.  

However, as this is a general problem I am thinking about adding a new
list mode which selects a useful key the same way gpg does when called
directly with -r.  I have not come to a conclusion as there are valid
reasons for MUAs to do their own selection.  For example a MUA might
keep a list of former contacts and use a fingerpritn directly to
select a key.


Salam-Shalom,

   Werner

Re: epg and expired recipient keys

[Michael Piotrowski]

On 2007-02-24, Werner Koch <wk@gnupg.org> wrote:

>> GnuPG automatically selects the right key to use, and avoids the
>> expired ones.
>> 
>> If this is a bug in epg, I'd think that someone must have run into it
>> before--or could this be a local problem?
>
> I had the same problem and discussed this with Ueno.  The reason is
> that epg uses --list-keys to get a list of macthing recinpients and
> picks the first one.  This is obviously not correct, as it should skip
> all revoked and expired keys.  

I thought so :-)

> However, as this is a general problem I am thinking about adding a new
> list mode which selects a useful key the same way gpg does when called
> directly with -r.  I have not come to a conclusion as there are valid
> reasons for MUAs to do their own selection.  For example a MUA might
> keep a list of former contacts and use a fingerpritn directly to
> select a key.

Hmm, while this is perhaps convenient, I'm not sure whether it is
really needed: As far as I can see, --list-keys already gives the
necessary information, and it seems to be trivial to check for "e",
"r", etc. in the appropriate fields.  But maybe I'm missing something.

Greetings

-- 
Michael Piotrowski, M.A.                               <mxp@dynalabs.de>
Public key at <http://www.dynalabs.de/mxp/pubkey.txt>

Re: epg and expired recipient keys

[Werner Koch]

On Sat, 24 Feb 2007 17:49, gdt@work.lexort.com said:

> querying for properties, and choosing a key.  So I don't follow your
> "have not come to a conclusion" - I don't think manual MTA choice
> argues for not providing the 'get me the right key' api.

gpg simply picks the first one.  However this is sometimes not the key
you want.  All other MUAs preset a list of available and matching
keys.  Only EGP does not.  Thus I wonder whether it is really
justified to add such a feature to gpg.  The next step would be to
keep a database of keys recently used in communication and to assign
them some trust.  I think that is better placed in a MUA.


Salam-Shalom,

   Werner

Re: epg and expired recipient keys

[Daiki Ueno]

>>>>> In <87y7mlgl9f.fsf@wheatstone.g10code.de> 
>>>>>	Werner Koch <wk@gnupg.org> wrote:
> gpg simply picks the first one.  However this is sometimes not the key
> you want.  All other MUAs preset a list of available and matching
> keys.  Only EGP does not.

Sorry for late response.  I'm a bit busy now though, EPG used to be
released on 29th every month, fortunatelly there are only 28 days in
this month, the next release is scheduled for 3/29 ;-)

> Thus I wonder whether it is really justified to add such a feature to
> gpg.  The next step would be to keep a database of keys recently used
> in communication and to assign them some trust.  I think that is
> better placed in a MUA.

I'm now wondering whether to exclude unusable keys from the key list
when Gnus calls EPG, or to make epg-encrypt-string accept "strings"
instead of "epg-key objects" (if RECIPIENTS are strings, EPG won't
resolve keys by itself).  However, the latter idea might have an
interface flaw since EPG may be compared to GPGME.

Regards,
-- 
Daiki Ueno

Re: epg and expired recipient keys

[Werner Koch]

On Mon, 26 Feb 2007 13:49, ueno@unixuser.org said:

> I'm now wondering whether to exclude unusable keys from the key list

Yes, please do this when encrypting.


Shalom-Salam,

   Werner

Re: epg and expired recipient keys

[Michael Piotrowski]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

On 2007-02-26, Werner Koch <wk@gnupg.org> wrote:

>> I'm now wondering whether to exclude unusable keys from the key list
>
> Yes, please do this when encrypting.

I'm using the attached patch to epg.el to filter unusable keys.  I'm
checking for keys marked d, i, r, or e in `epg--list-keys-1'.  If you
want to browse unusable keys in `epa-list-keys' the filtering would
have to be implemented somewhere else, so maybe this is not the final
solution.  But it works for me and allows me to send encrypted
messages to people for whom there also expired keys in my keyring.
So, maybe it can be used as an example for a more comprehensive
implementation.

Greetings

-- 
Michael Piotrowski, M.A.                               <mxp@dynalabs.de>
Public key at <http://www.dynalabs.de/mxp/pubkey.txt>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Filter unusable keys --]
[-- Type: text/x-patch, Size: 1497 bytes --]

Index: epg.el
===================================================================
RCS file: /cvs/root/epg/epg.el,v
retrieving revision 1.188
diff -C2 -r1.188 epg.el
*** epg.el	31 Jan 2007 03:27:46 -0000	1.188
--- epg.el	27 Feb 2007 11:14:01 -0000
***************
*** 1656,1660 ****
  			'("--fixed-list-mode"))
  		      (if name (list name))))
! 	keys string field index)
      (with-temp-buffer
        (apply #'call-process
--- 1656,1660 ----
  			'("--fixed-list-mode"))
  		      (if name (list name))))
! 	keys)
      (with-temp-buffer
        (apply #'call-process
***************
*** 1664,1677 ****
  	     nil (list t nil) nil args)
        (goto-char (point-min))
!       (while (re-search-forward "^[a-z][a-z][a-z]:.*" nil t)
! 	(setq keys (cons (make-vector 15 nil) keys)
! 	      string (match-string 0)
! 	      index 0
! 	      field 0)
! 	(while (eq index
! 		   (string-match "\\([^:]+\\)?:" string index))
! 	  (setq index (match-end 0))
! 	  (aset (car keys) field (match-string 1 string))
! 	  (setq field (1+ field))))
        (nreverse keys))))
  
--- 1664,1676 ----
  	     nil (list t nil) nil args)
        (goto-char (point-min))
!       (let ((line 0))
! 	(while (not (eobp))
! 	  (goto-line (incf line))
! 	  (let ((fields (split-string (buffer-substring (point)
! 							(point-at-eol))
! 				      ":" nil)))
! 	    (when (cddr fields)
! 	      (unless (string-match "[dire]" (second fields))
! 		(push (apply 'vector fields) keys))))))
        (nreverse keys))))
  

Re: epg and expired recipient keys

[Daiki Ueno]

>>>>> In <87zm71f0sl.fsf@wheatstone.g10code.de> 
>>>>>	Werner Koch <wk@gnupg.org> wrote:
> > I'm now wondering whether to exclude unusable keys from the key list

> Yes, please do this when encrypting.

Okay, I just installed this in Gnus CVS.  The filter function is

(defun mml2015-epg-find-usable-key (keys usage)
  (catch 'found
    (while keys
      (let ((pointer (epg-key-sub-key-list (car keys))))
        (while pointer
          (if (and (memq usage (epg-sub-key-capability (car pointer)))
                   (not (memq (epg-sub-key-validity (car pointer))
                              '(revoked expired))))
              (throw 'found (car keys)))
          (setq pointer (cdr pointer))))
      (setq keys (cdr keys)))))

Regards,
-- 
Daiki Ueno

Re: epg and expired recipient keys

[Wolfram Fenske]

Daiki Ueno <ueno@unixuser.org> writes:

>>>>>> In <87zm71f0sl.fsf@wheatstone.g10code.de> 
>>>>>>	Werner Koch <wk@gnupg.org> wrote:
>> > I'm now wondering whether to exclude unusable keys from the key list
>
>> Yes, please do this when encrypting.
>
> Okay, I just installed this in Gnus CVS.  The filter function is
>
> (defun mml2015-epg-find-usable-key (keys usage)
>   (catch 'found
>     (while keys
>       (let ((pointer (epg-key-sub-key-list (car keys))))
>         (while pointer
>           (if (and (memq usage (epg-sub-key-capability (car pointer)))
>                    (not (memq (epg-sub-key-validity (car pointer))
>                               '(revoked expired))))
>               (throw 'found (car keys)))
>           (setq pointer (cdr pointer))))
>       (setq keys (cdr keys)))))

How about a version that uses the "dolist" macro?  I think this makes
the code a lot clearer.  Plus, it's shorter.

--8<---------------cut here---------------start------------->8---
(defun mml2015-epg-find-usable-key (keys usage)
  (catch 'found
    (dolist (key keys)
      (dolist (sub (epg-key-sub-key-list key))
	(when (and (memq usage (epg-sub-key-capability sub))
                   (not (memq (epg-sub-key-validity sub) '(revoked expired))))
	  (throw 'found key))))))
--8<---------------cut here---------------end--------------->8---

-- 
Wolfram Fenske

A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?

Re: epg and expired recipient keys

[Katsumi Yamaoka]

>>>>> In <867itvcdve.fsf@hondo.cadr.de> Wolfram Fenske wrote:

> How about a version that uses the "dolist" macro?  I think this makes
> the code a lot clearer.  Plus, it's shorter.

> (defun mml2015-epg-find-usable-key (keys usage)
>   (catch 'found
>     (dolist (key keys)
>       (dolist (sub (epg-key-sub-key-list key))
> 	(when (and (memq usage (epg-sub-key-capability sub))
>                    (not (memq (epg-sub-key-validity sub) '(revoked expired))))
> 	  (throw 'found key))))))

It looks good and will probably make the code slow not so much.
I mean dolist is generally slower than well-designed while loop.
For instance:

(benchmark
    10000
  (let ((alist mm-mime-mule-charset-alist)
	sub rest)
    (while alist
      (setq sub (car alist))
      (while sub
	(setq rest (cons (car sub) rest)
	      sub (cdr sub)))
      (setq alist (cdr alist)))
    (nreverse rest)))
0.5125889778137207
0.5080130100250244
0.5140340328216553
0.5127580165863037
0.5110170841217041

(benchmark
    10000
  (let (rest)
    (dolist (sub mm-mime-mule-charset-alist (nreverse rest))
      (dolist (elem sub)
	(setq rest (cons elem rest))))))
0.6363399028778076
0.6323390007019043
0.6358840465545654
0.6289501190185547
0.6397740840911865

I used Lars' benchmark.el[1] and XEmacs 21.4.20 for those tests.

[1] http://quimby.gnus.org/elisp/benchmark.el

Re: epg and expired recipient keys

[Daiki Ueno]

>>>>> In <867itvcdve.fsf@hondo.cadr.de> 
>>>>>	Wolfram Fenske <Wolfram.Fenske@Student.Uni-Magdeburg.DE> wrote:
> > (defun mml2015-epg-find-usable-key (keys usage)
> >   (catch 'found
> >     (while keys
> >       (let ((pointer (epg-key-sub-key-list (car keys))))
> >         (while pointer
> >           (if (and (memq usage (epg-sub-key-capability (car pointer)))
> >                    (not (memq (epg-sub-key-validity (car pointer))
> >                               '(revoked expired))))
> >               (throw 'found (car keys)))
> >           (setq pointer (cdr pointer))))
> >       (setq keys (cdr keys)))))

> How about a version that uses the "dolist" macro?  I think this makes
> the code a lot clearer.  Plus, it's shorter.

I know.  However, while-loop looks not so unreadable for me that we have
to rewrite it with dolist.

Regards,
-- 
Daiki Ueno

Re: epg and expired recipient keys

[Wolfram Fenske]

Daiki Ueno <ueno@unixuser.org> writes:

>>>>>> In <867itvcdve.fsf@hondo.cadr.de> 
>>>>>>	Wolfram Fenske <Wolfram.Fenske@Student.Uni-Magdeburg.DE> wrote:
>> > (defun mml2015-epg-find-usable-key (keys usage)
>> >   (catch 'found
>> >     (while keys
>> >       (let ((pointer (epg-key-sub-key-list (car keys))))
>> >         (while pointer
>> >           (if (and (memq usage (epg-sub-key-capability (car pointer)))
>> >                    (not (memq (epg-sub-key-validity (car pointer))
>> >                               '(revoked expired))))
>> >               (throw 'found (car keys)))
>> >           (setq pointer (cdr pointer))))
>> >       (setq keys (cdr keys)))))
>
>> How about a version that uses the "dolist" macro?  I think this makes
>> the code a lot clearer.  Plus, it's shorter.
>
> I know.  However, while-loop looks not so unreadable for me that we have
> to rewrite it with dolist.

OK.  It was just a thought.  Maybe programming in Common Lisp has made
me go soft. :-)

-- 
Wolfram Fenske

A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?

Re: epg and expired recipient keys

[Wolfram Fenske]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>>>>>> In <867itvcdve.fsf@hondo.cadr.de> Wolfram Fenske wrote:
>
>> How about a version that uses the "dolist" macro?  I think this makes
>> the code a lot clearer.  Plus, it's shorter.

[...]

> I mean dolist is generally slower than well-designed while loop.
> For instance:

[...] (while version snipped)

> 0.5125889778137207
> 0.5080130100250244
> 0.5140340328216553
> 0.5127580165863037
> 0.5110170841217041

[...] (dolist version snipped)

> 0.6363399028778076
> 0.6323390007019043
> 0.6358840465545654
> 0.6289501190185547
> 0.6397740840911865

Interesting.

> I used Lars' benchmark.el[1] and XEmacs 21.4.20 for those tests.
>
> [1] http://quimby.gnus.org/elisp/benchmark.el

Thanks.  This might come in handy some day.

-- 
Wolfram Fenske

A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?

Re: epg and expired recipient keys

[Miles Bader]

Katsumi Yamaoka <yamaoka@jpl.org> writes:
> I mean dolist is generally slower than well-designed while loop.

That isn't true in general; it may be true if you're using cl.el's
craptastic version of dolist.  Unfortunately, gnus uses cl, so I guess
it loses there...

[The non-cl version of dolist is a macro that expands to basically the
same code as your hand-written while loop.]

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: epg and expired recipient keys

[Miles Bader]

Miles Bader <miles@gnu.org> writes:
> That isn't true in general; it may be true if you're using cl.el's
> craptastic version of dolist.  Unfortunately, gnus uses cl, so I guess
> it loses there...
>
> [The non-cl version of dolist is a macro that expands to basically the
> same code as your hand-written while loop.]

BTW, to be fair to cl.el, I think it tries to do additional tricks at
compilation time to get rid of the additional overhead of its version of
dolist (by removing unnecessary calls to catch/throw that its macro
previously inserted to emulate common-lisp blocks).  I don't know how
effective this is though.

-Miles

-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

dolist vs. while-loop (was Re: epg and expired recipient keys)

[Katsumi Yamaoka]

>>>>> In <87k5xs26v2.fsf@catnip.gol.com> Miles Bader wrote:

> Miles Bader <miles@gnu.org> writes:

>> That isn't true in general; it may be true if you're using cl.el's
>> craptastic version of dolist.  Unfortunately, gnus uses cl, so I guess
>> it loses there...
>>
>> [The non-cl version of dolist is a macro that expands to basically the
>> same code as your hand-written while loop.]

> BTW, to be fair to cl.el, I think it tries to do additional tricks at
> compilation time to get rid of the additional overhead of its version of
> dolist (by removing unnecessary calls to catch/throw that its macro
> previously inserted to emulate common-lisp blocks).  I don't know how
> effective this is though.

Yes, there's no difference between the byte codes of the subr.el
version and the cl-macs.el version except for variable names.
But I don't know in what case and for what purpose the byte code
of the cl-macs.el version will have the catch-throw form.  That
is a mystery.

BTW, the results of the benchmark tests I wrote were done in
XEmacs 21.4.20 (<b4modn7q9jr.fsf@jpl.org>).  In Emacs 22 (in the
same host), I got:

[while loop]
1.0685009956359863
1.074789047241211
1.0869169235229492
1.1011860370635986
1.0744349956512451

[dolist]
1.122694969177246
1.1409659385681152
1.140753984451294
1.1298248767852783
1.1383061408996582

I also used Lars' benchmark.el.  Please note that the later test
has nested two dolist forms like the one that Wolfram Fenske wrote.
I guess the reason it is slower than the while-loop version is that
the `let' form in the inside dolist is used many times.

Regards,

Re: dolist vs. while-loop (was Re: epg and expired recipient keys)

[Miles Bader]

Katsumi Yamaoka <yamaoka@jpl.org> writes:
> I also used Lars' benchmark.el.  Please note that the later test
> has nested two dolist forms like the one that Wolfram Fenske wrote.
> I guess the reason it is slower than the while-loop version is that
> the `let' form in the inside dolist is used many times.

It doesn't do any binding in the inner loop though.  let-binding has
some cost in elisp, but getting rid of lets (like using while instead of
dolist) is something you do when you desperately need speed; otherwise
the decrease in readability is simply not worth it.

-Miles

-- 
What the fuck do white people have to be blue about!?  Banana Republic ran
out of Khakis?  The Espresso Machine is jammed?  Hootie and The Blowfish are
breaking up??!  Shit, white people oughtta understand, their job is to GIVE
people the blues, not to get them!    -- George Carlin