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
