On Feb 15 20:26, Jeffrey Walton wrote: > On Thu, Feb 14, 2019 at 10:23 AM Michael Haubenwallner > <michael.haubenwall...@ssi-schaefer.com> wrote: > > > > so I find myself struggling with textmode versus binmode for stdio again. > > > > Running the openssl command (from within the apps/ build directory here) > > does > > yield different results regarding carriage return depending on the version: > > > > $ ./apps/openssl version > > OpenSSL 1.0.2p 14 Aug 2018 > > $ ./apps/openssl x509 -hash -noout -in /etc/pki/tls/cert.pem | xxd > > 00000000: 6139 3464 3039 6535 0a a94d09e5. > > > > > > $ ./apps/openssl version > > OpenSSL 1.1.0j 20 Nov 2018 > > $ ./apps/openssl x509 -hash -noout -in /etc/pki/tls/cert.pem | xxd > > 00000000: 6139 3464 3039 6535 0d0a a94d09e5.. > > > > Some subsequent shell script does create wrong symlink filenames > > (with embedded CR) when used with openssl-1.1.x. > > > > The commit that changed this behaviour in openssl-1.1 is: > > https://github.com/openssl/openssl/commit/bdd58d98467e9f0f6635c1628e1eae304383afb1 > > > > From an openssl developer's point of view, I can understand to set > > textmode when the intent is to output some text, and to set > > binmode when the intent is to output some binary data. > > > > Question now is: These days, what is the correct way to handle this? > > > RFC 1421, Privacy Enhanced Mail (PEM) > (https://www.ietf.org/rfc/rfc1421.txt), is the controlling document. > Lines should break at 64 characters, and EOL is CRLF pairs. > > * 64-char lines is covered in section 4.3.2.4, Printable Encodings > * CRLF is covered in section 4.3.1 Constraints > > Line breaks at 64 chars is an anachronism (in my opinion), but some > software still enforces it. Some software will reject keys and > certificates if not properly broken.
POSIX software has to write the \r explicitely since it can't rely on DOS textmode. Corinna -- Corinna Vinschen Cygwin Maintainer
signature.asc
Description: PGP signature
