X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=HNkRfWG9OBsx0VNj2qmLdEcV3pF3sHYTlowliUKFPw+zNFE370wLF
	xZtGj0HsAvK3WINjjz0YrNmGMeyN3pLkmEwiR8eSaHYTFw85kcA5dbqC67M07Roo
	rdNeZM5Qow0g7QKDwDcL/j02QvCQPPvhEDvgP6sSTCVjHmzFj+/aR0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=E2VPEEoZcn1nX/TsHCfGV8OoTnA=; b=H7IMkX5f/bC2nCVz2+5ZlnSQBO8y
	4dxKE2tFxpFNZWUgDKxdfdv+gUWqPdhv5JjJatqmNunGmXXgKOTjyB+50Iuq4xoP
	/LBMpDOubRHmH9RtWI4oJaaEpgqLQSYee5dytnsa/QVD+UI9o2h5HJSFTtnC1Nai
	mxe1hCjU+BTfM+I=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-100.9 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=jeffrey, walton, Walton, Jeffrey
X-HELO: mout.kundenserver.de
Date: Sat, 16 Feb 2019 10:40:02 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: textmode for stdout, what is "correct" now?
Message-ID: <20190216094002.GS2702@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <739ed5ce-6902-d702-e152-65dc2c1da667 AT ssi-schaefer DOT com> <CAH8yC8nsJoq+ezipRjVfF9ww8Eszf_=qdPudWRAVL1Dd11Lb4g AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="Iys0Un1O+0sigPHU"
Content-Disposition: inline
In-Reply-To: <CAH8yC8nsJoq+ezipRjVfF9ww8Eszf_=qdPudWRAVL1Dd11Lb4g@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)

--Iys0Un1O+0sigPHU
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Feb 15 20:26, Jeffrey Walton wrote:
> On Thu, Feb 14, 2019 at 10:23 AM Michael Haubenwallner
> <michael DOT haubenwallner AT ssi-schaefer DOT com> wrote:
> >
> > so I find myself struggling with textmode versus binmode for stdio agai=
n.
> >
> > Running the openssl command (from within the apps/ build directory here=
) does
> > yield different results regarding carriage return depending on the vers=
ion:
> >
> > $ ./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/bdd58d98467e9f0f6635c1628e1ea=
e304383afb1
> >
> > 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?
>=20
>=20
> 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.
>=20
>  * 64-char lines is covered in section 4.3.2.4, Printable Encodings
>  * CRLF is covered in section 4.3.1  Constraints
>=20
> 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

--=20
Corinna Vinschen
Cygwin Maintainer

--Iys0Un1O+0sigPHU
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlxn2nIACgkQ9TYGna5E
T6AoPxAAk8MlAiBS65NyjjhgssigJjfNrNd2LN1OjqSxCLZRGsOwCSrPOV/PPfBS
8vMwIHd+I38ipKyiU38Wl5yBnF4jFRr0nWsm3515efqojcnCpNFBwRLF17DnmIJ+
VPSDIgk14KPooxUVzvMW9jwIc5p82Ivan92UcWC5Cam/d/+hWB44fIILpXpNaGh6
t2LH/HQoMPdJYAuG5b6DmuJhoFFRK6ALAeeIAy/Q31bltzg8HZ1MPj1fRChWZO6d
e5W4cm993RrBG/QdEgy15lOsvHfJilIjBUgDAHoBqUZPjE2bi2Zv/r/wsXWpqnPq
+kgAHD9CW3zxjjpJu7vHLAWS9ALOCHoi5uFj62VBZsNg7KM0/mxOPEec8dqcfLvj
yKvkpUJnQ6AnGTiG0NPaEpuP0IrC9HB0cJvNpHCvcZlRN+YCcNza3KkeDCfQTP8O
rfjQInyT/XYMbK9NZTGgQXGf92F5YGxaEsLHmwsx/wBr/fEKA2mv5jUPd3vn47no
gIiDjwQkuxIXpbv2XGzr4NrJqXsIhtXPAIaOku+j/WVzbc6HemXTxlsdWZ5aCp1c
BFOitxIhNOLAfO7y2nuGRHre4G4bf9689ZEulmYfO5L0qHZXwBM+l1BuznOqBi/6
fNT00tkAww+CmKiYDZKLxbsELR+18idxYKzvJmC07dGNh+EaJaU=
=ImS6
-----END PGP SIGNATURE-----

--Iys0Un1O+0sigPHU--