[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: armour pierced with PGP 8 arrow
Konrad Rosenbaum wrote:
> On Thursday 11 December 2003 19:04, David Shaw wrote:
> > I disagree we need to change anything here. There is already only one
> > separator permitted. Using your example:
> > Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial
> > The second instance of colon-space is NOT a separator. It's just part
> > of the value.
> As long as the line is not split, you are correct.
Knowing how coders make different assumptions, and have
different scanning tools available to them, even this could
cause some surprises. For e.g., in list based languages,
popping is more natural than parsing left-to-right.
Here's some perl:
perl -e ' $x = "Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial"; @a = (split(": ", $x)); $_ = shift(@a); print "$_\n"; /Version/ && print pop(@a), "\n"; '
> I'm a newbie to implementing OpenPGP - so please forgive me, if my question is
> stupid: why consider the additional headers at all? They seem to me to only
> have any value to human readers and none at all to OpenPGP itself, since all
> important information is already encoded into the binary message blocks (once
> you got them out of their armor). Is there any technical reason for the RFC
> not saying "Implementations shall ignore header lines."?
This is meta-part of the issue. Currently, the ID says:
"OpenPGP should consider improperly
formatted Armor Headers to be
corruption of the ASCII Armor."
I wonder whether that is too strong. It seems reasonable
to say that implementations may attempt to parse beyond and
ignore improperly formatted headers. Perhaps with warnings.
As we have not gone to any great extent to define why the
optional ascii armour headers are important, it seems odd
to treat them as if they are important enough to be capable
of breaking the armoured message.