On 09/27/2014 11:50 PM, Marko Tiikkaja wrote:
> Hi,
>
> On 9/25/14, 3:56 PM, I wrote:
>> On 9/25/14 3:50 PM, Heikki Linnakangas wrote:
>>> Are you planning to post the main patch rebased on top of this soon? As
>>> in the next day or two? Otherwise I'll mark this as "Returned with
>>> feedback" for this commitfest.
>>
>> Yes. With good luck I'll get you a rebased one today, otherwise it'll
>> have to wait until tomorrow.
>
> Missed that promise by a day since something unexpected came up
> yesterday. Attached is v3 of the patch. The changes are:
>
> - Rebased on top of the current master
> - Added a function pgp_armor_header_keys() to list all keys present
> in an armor
> - Changed pgp_armor_header() to use a StringInfo instead of an mbuf
> - Fixed the "error is returned" problem in the documentation pointed
> out earlier
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.
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.
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?
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.
- Heikki