delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2019/02/15/20:26:50

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:mime-version:references:in-reply-to:reply-to
:from:date:message-id:subject:to:content-type; q=dns; s=default; b=
OSV6BMBVaCoqhJ39xc6pj7eY4l4WbZiumPGfed2Nv28P+ENkDgTVio+WTqktWKYr
lCKUQJFGuwMoTq4xkqtgWJkHoxDgWh1BPilsSKic1QXjccilgnoaF3zwPvcbdOh+
EDKWO1OmzBtZPnIc1Hk9LdHwMBoUExyXKnz9cWCNY8k=
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:mime-version:references:in-reply-to:reply-to
:from:date:message-id:subject:to:content-type; s=default; bh=JOj
mzsglrfeyv1I7nIA+pk0sMoE=; b=Fp39sBmV4PRqCgpVQ2Ug1lnidBTalP9mDtR
KF/T1xluKXlXyU5Be53ACo+qhRo7r19bNSOrS2ES2JgXNM5sYO6GH924DIQCO1EM
Dwyrf+roERfqN9n9XXU1WZDHS+xSIUE6GtVN24Lwlo5sdkHScQkmTG7AM33dmVYN
fJdsIgGY=
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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Privacy, D*ssi-schaefer.com, HX-Google-DKIM-Signature:reply-to, certificates
X-HELO: mail-it1-f172.google.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=0PfE35rjLPhfGbM7obuKweAsg7hbDDa1NbJiAFH6g18=; b=XtcKw62Z/H/L/3j8G528Nqorbxmb3NKeccYbmG3oYhExZxuOSC1WU6PzxkDfSdS7nj 1b0xoZyu+DZJ9hOz7Zc27UGMCkx7f5cNid69rJHPGO1jHK4VyWqlVZhgnoRNUpdC4zaT PxbGhaySeOqK2tFTucLgE8eB329vOZSL0s+LQMhvtwFfhGaSSqjbBDajAC+F57rNOKQ3 hJnAXlgNsdMv6avtFCz82vKZk0YvhoBXHTwabI4m/My1m0AiA3DJprFlkZulWHiW8rK7 EPfW0Ninz2oFLSrJmyHFvEFfYk31LmiSpIjvUgZCWkzPz3DI56DW0owuX/F2UUm3gAxd Seqw==
MIME-Version: 1.0
References: <739ed5ce-6902-d702-e152-65dc2c1da667 AT ssi-schaefer DOT com>
In-Reply-To: <739ed5ce-6902-d702-e152-65dc2c1da667@ssi-schaefer.com>
Reply-To: noloader AT gmail DOT com
From: Jeffrey Walton <noloader AT gmail DOT com>
Date: Fri, 15 Feb 2019 20:26:16 -0500
Message-ID: <CAH8yC8nsJoq+ezipRjVfF9ww8Eszf_=qdPudWRAVL1Dd11Lb4g@mail.gmail.com>
Subject: Re: textmode for stdout, what is "correct" now?
To: cygwin AT cygwin DOT com
X-IsSubscribed: yes

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 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.

Jeff

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019