Re: pgcrypto: PGP armor headers

On 9/29/14 3:02 PM, Heikki Linnakangas wrote:
> Thanks! I found the pgp_extract_armor_headers()'s signature quite weird,
> so I simplified that by making it always return arrays of keys and
> values. The callers is now responsible for returning all the keys
> (pgp_armor_header_keys) or finding the single key (pgp_armor_header). I
> also partially rewrote the implementation of
> pgp_extract_armor_headers(), making it more readable I hope.

OK.  Looks good to me.

> If an armor header line ends in CR+LF, pgp_armor_header() returned the
> CR as part of the value, with your patch. I don't think that's right,
> the line ending should be considered part of the armoring, so I changed
> that.

Nice catch.  You are correct.

> Is there any real life examples or tools out there to generate armors
> with headers with duplicate keys? RFC 4880 says:
>
>>     Note that some transport methods are sensitive to line length.  While
>>     there is a limit of 76 characters for the Radix-64 data (Section
>>     6.3), there is no limit to the length of Armor Headers.  Care should
>>     be taken that the Armor Headers are short enough to survive
>>     transport.  One way to do this is to repeat an Armor Header key
>>     multiple times with different values for each so that no one line is
>>     overly long.
>
> Does anyone do that in practice? Is there any precedence for
> concatenating the values in other tools that read armor headers?

Maybe I just suck at $SEARCH_ENGINE, but extracting armor headers 
programmatically doesn't seem to be very popular.  I could only find one 
example, which returned the last instance of the key.  But that seemed 
to be more an accident than anything else; it wasn't documented and the 
source code didn't say anything about it.  I also think that's the worst 
behaviour.  If we can't agree on concatenation, I'd rather see an error.

> I wonder if it would make sense to have pgp_armor_header_keys() return
> both the keys and values. That would make it easier to use, and it might
> then make sense for it to not remove the duplicates or concatenate
> values, but just them as is. The caller could then deal with the
> duplicates any way he wants. We could keep the function for extracting
> the value for a single key, with the concatenating behavior, for
> convenience.

I'd also suggest renaming it to pgp_armor_headers() in that case.  But 
otherwise it seems like a reasonable plan to me.  Want me to do that 
change or are you going to?


.marko