On Fri, 07 Apr 2006, David Shaw wrote:
> On Fri, Apr 07, 2006 at 03:40:43PM +0200, Peter Palfrader wrote:
> > Hi,
> >
> > running 1.4.4-cvs, when I try to download DE415B0E I get the following
> > error:
> >
> > | [EMAIL PROTECTED]:~$ gpg --keyserver random.sks.penguin.de --recv
> > 94c09c7f DE415B0E
> > | gpg: requesting key DE415B0E from hkp server random.sks.penguin.de
> > | gpg: requesting key 94C09C7F from hkp server random.sks.penguin.de
> > | gpg: key DE415B0E: public key "Susumu OSAWA <[EMAIL PROTECTED]>" imported
> > | gpg: [don't know]: invalid packet (ctb=2d)
> > | gpg: read_block: read error: invalid packet
> > | gpg: Total number processed: 1
> > | gpg: imported: 1
> >
> > While it imports the key in question, it breaks the current download
> > action, not fetching additional keys given on the command line.
>
> This is a feature, believe it or not. During an import (and a
> keyserver --recv-keys or --refresh-keys is really just an import), GPG
> reads packets off the input stream. Once any of those packets prove
> invalid (a packet starting with 2D is invalid), there is no way to
> know where it is in the stream - how many bytes should it jump ahead
> to get back on the track.
I don't believe it's a feature - yet :)
I think a --refresh should always try to refresh all keys. As it is in
this case - with a key with "evil" packets on the keyserver - I'm stuck
in a situation where "gpg --refresh-keys" only updates half of my
keyring.
I can see a point in aborting in the case of gpg --recv, but it's
confusing that it starts fetching keys starting with the last. Maybe
that could be turned around.
Cheers,
Peter
--
PGP signed and encrypted | .''`. ** Debian GNU/Linux **
messages preferred. | : :' : The universal
| `. `' Operating System
http://www.palfrader.org/ | `- http://www.debian.org/
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
