fetching DE415B0E from sks ([don't know]: invalid packet (ctb=2d))

[David Shaw]

On Fri, Apr 07, 2006 at 05:53:43PM +0200, Peter Palfrader wrote:
> 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:
> > > 
> > > | weasel at asteria:~$ 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 <susumu-o at goforward.org>" 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.

--import (and therefore --refresh) does try to handle all keys in the
stream.  It just can't continue once there is a stream error as there
is no way to reestablish its place in the stream.  The stream coding
more or less says stuff like "here's a signature and it's 40 bytes
long (40 bytes here)".  GPG reads that and keeps going.  If GPG sees
"here's garbage and it's garbage bytes long", it can't read it because
it's garbage, and it can't skip it because it doesn't know how many
(garbage) bytes to skip over.  The only thing it can do at that point
is stop.

Keyserver operations result in multiple streams (one per key).  If one
errors out, it might be possible to jump to the next BEGIN header, but
that would be a pretty nontrivial undertaking given how the code
currently works.

All that said, though, I'm not convinced that the armored stream you
got from the keyserver is invalid.  I think there may be a problem in
GPG's armor parser (hard to imagine after this many years, but..)  It
seems that the bad key is the right length (exactly 8192 bytes) to
trigger a problem.

> 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.

That's easy.  I'll do that.

David