From: "Laurent Bercot" <ska-devel@skarnet.org>
To: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Proposed change: openssl 1.1 as default system openssl
 implementation
Date: Fri, 09 Feb 2018 14:32:12 +0000
Message-Id: <em5a0b1545-2356-4725-98f0-8f0ee465fd67@elzian>
In-Reply-To: <20180209130715.5aa36488@mechanicum.chadwicks.me.uk>
References: <CA+T2pCGFeh30aEi43hAvJ3yoHBijABy_U62wfjhVmf3FmbNUUg@mail.gmail.com>
 <20180208180544.3ff19e66@mechanicum.chadwicks.me.uk>
 <9750d294-4f83-3f20-17a1-2177ad62bfe3@adelielinux.org>
 <20180209130715.5aa36488@mechanicum.chadwicks.me.uk>
Reply-To: "Laurent Bercot" <ska-devel@skarnet.org>
User-Agent: eM_Client/7.1.31849.0
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  Apologies in advance for the offtopic.


>I just want to add that I think that this is unfair. OpenBSD goes out=20
>of
>it's way for portability

  Oh, does it really? Let's see.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html
specifies EPROTO and EOVERFLOW as error codes. OpenBSD has *never*
defined EPROTO, and guards EOVERFLOW with the nonstandard _BSD_SOURCE
macro. Those violations of POSIX are extremely basic, have been there
*forever*, have been reported multiple times, and are incredibly easy
to fix. Why have they never been fixed?

  OpenBSD does not define the POSIX timer_* API:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/timer_create.html

  And those are the first two examples I can recall instantly; in my
code, I have countless more workarounds to build on OpenBSD, which
shares with MacOS and Solaris the sad distinction of being one of
the Unix systems it is the *most painful* to port code to.

  Is that going out of its way for portability? I don't think so. The
_first_ step in pretending to care about portability, without even
talking about "going out of your way", is to respect standards, and
it is painfully obvious that OpenBSD isn't very interested in doing so.

  I will ignore the nonsense about RNG. I will just note that OpenBSD
first added the arc4random() API for random number generation, which
is a good API; then other BSDs aligned on it, and introduced the
arc4random_addrandom() function to allow the user to add to the
entropy pool. OpenBSD did not find this function useful; they did
not implement it. They could have added arc4random_addrandom() and
made it a NOP if they didn't want the functionality; but they did
not, and code that uses arc4random_addrandom() just does not compile
on OpenBSD. So now, as a developer it is not enough to test for
arc4random() presence; you need to test for both arc4random() and
arc4random_addrandom(). This is more burden for developers; this is
the _antithesis_ of helping portability.

  I like OpenBSD, I really do. I think they're doing a good job of
making a secure, tightly-knit Unix system. But this comes at a price,
and this price is willingness to deal with other systems' quirks and
make it easier for developers to port their code to OpenBSD.
Claiming that OpenBSD goes out of its way for portability is absurd,
because it's just not true, in a very obvious way.

  There is a time and place for OpenBSD advocacy, and a way to do it;
but now isn't the time, this thread isn't the place, and you're not
doing it right. So please stop derailing this thread with knee-jerk
fanboyism, and let Alpine devs decide what is best for their
distribution. And if you need to reply to this mail, please do so
off-list; I promise I'll read your reply.

--
  Laurent



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---