[openpgp] Re: ecosystem split: text-mode signatures over C R-only line endings

Daniel Kahn Gillmor <[email protected]> Wed, 22 Oct 2025 11:49:20 -0400
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
On Wed 2025-10-15 17:28:38 -0400, Daniel Kahn Gillmor wrote:
> So i think the following question is what we need to answer:
>
>  - is `\r` (CR) on its own a "line-ending" that needs to be converted to
>    CRLF when signing in text mode?

It also occurs to me that line-ending normalization might behave
differently with the same source code on different systems, depending on
how normalization is done.

i think the C standard and POSIX and GNU could all contribute, if any
implementation reaches for some of the footguns they offer.

The C standard offers gets() and fgets(), both of which appear to be
agnostic about what the newline character actually is, which suggests
that it's defined by the platform. If Wikipedia [0] is correct, even the
string escape sequences '\r' (CR) and '\n' (LF) aren't even obliged to
map to ASCII 0x0d and 0x0a octets respectively.  😱

[0] https://en.wikipedia.org/wiki/Newline#In_programming_languages

GNU introduced (and POSIX adopted in 2008) getline() (and its sibling
getdelim() -- which allows specification of the delimiting character).
so any normalization code that uses any of these functions could also
behave differently on different platforms.

Finally, on MS-DOS platforms, some code might just not normalize line
endings at all (because the platform natively uses CRLF as a line
ending).  This would mean that the line "foo\n" would *not* be
normalized to "foo\r\n" any tooling that simply #ifdefs out
normalization when building on an "already normalized" platform.

It all seems fairly absurd, a relic of a world where data was unlikely
to move from one machine to another.

If we can't simply drop text-mode signatures as an antiquated relic, i
think we would be well served as a community by explicitly describing
how to interpret and transform the bytestreams in question.  OpenPGP is
all-in on UTF-8, so the question of "what bytes are CR and LF anyway?"
at least should be off the table.

Note that explicitly defining this as a deteriministic, unambiguous
translation will inevitably make some pre-existing text-mode signatures
"fail" if they were generated by some other normalization process.

I think that's a reasonable price to pay if it means that all future
text-mode signatures share a single consensus on what normalization
actually means.

The alternative (not defining it explicitly) means that some unknown and
possibly shifting combination of pre-existing signatures and different
implementations will have a sort of intermediate status -- verifiable by
some implementations and not by others.  blech

         --dkg

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 324 B)