Skip to content

Conversation

@gwillen
Copy link
Contributor

@gwillen gwillen commented Mar 30, 2011

Properly handle zero-length packets, by removing special case code which avoided doing so.

For justification of the existence of such packets:

http://tools.ietf.org/html/rfc4880#section-5.11

"""
5.11. User ID Packet (Tag 13)

A User ID packet consists of UTF-8 text that is intended to represent
the name and email address of the key holder. By convention, it
includes an RFC 2822 [RFC2822] mail name-addr, but there are no
restrictions on its content. The packet length in the header
specifies the length of the User ID.
"""

Thus any zero-length User ID (i.e. the empty string) will result in an OpenPGP packet with length zero, so we must be able to parse these. (And of course I only noticed this because these are common enough in the wild that I saw one within the first two shards (out of 200) of the SKS keyserver dump.)

Ideally before committing this we would figure out the purpose of the existing behavior, which was presumably inserted for a reason. I will poke around in your repo for clues.

We do already 'return unless $type;' which will ensure that we bail on failure in any case, regardless of the value of $length.

@sergeyromanov
Copy link
Collaborator

Hi,

I'm a new co-maintainer for this distribution. Thanks for your patch, first of all!

I will poke around in your repo for clues.

Did you manage to have a look on this one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants