Date: Fri, 9 Feb 2018 16:14:04 +0000
From: Kevin Chadwick <m8il1ists@gmail.com>
To: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Proposed change: openssl 1.1 as default system
 openssl implementation
Message-ID: <20180209161404.594c66ee@mechanicum.chadwicks.me.uk>
In-Reply-To: <em5a0b1545-2356-4725-98f0-8f0ee465fd67@elzian>
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>
	<em5a0b1545-2356-4725-98f0-8f0ee465fd67@elzian>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 09 Feb 2018 14:32:12 +0000

Last mail, hardly fair to make that ridiculous email publicly and THEN
go private!

https://marc.info/?l=openbsd-tech&m=149183119728617&w=2

_______________________________________________________________________

> We have a bunch of patches in ports to deal with EPROTO and EBADMSG
> not being defined.  It would be nice to get rid of those.  The diff
> below also adds the also missing ENOTRECOVERABLE and EOWNERDEAD.
> 
> Thoughts?
> 
> (Dunno if there is a point describing verbosely what those new errno
> values mean on other systems...)

These are all in POSIX now.  ENORECOVERABLE and EOWNERDEAD are errors
returned for robus mutexes that we don't implement yet (but might want
to implement at one point).  EBASMSG and EPROTO are really obsolete
values for streams.  EBADMSG got re-used in catgets(3), but our
implementation doesn't generate it and the message passing extension
(which we don't implement).  EPROTO probably should have been marked
as obsolete (and therefore optional).  Given that Darwin, FreeBSD,
NetBSD, Linux and Solaris all provide this, we're probably better off
adding them as well.

ok kettenis@

_______________________________________________________________________

>   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 think you are coming from porting in one direction and not having a
balanced view. In many ways POSIX is influenced towards Linux unfairly
too, like RFCS to Google and Apple etc..

_______________________________________________________________________
https://marc.info/?l=openbsd-tech&m=140332790726752&w=2

Few things to note...

I suspect everyone working on LibReSSL is happy to hear the news about
BoringSSL.  Choice is good!!  Their priority is on safety, not on ABI
compatibility.  Just like us.  Over time, I suspect google's version
will also become 'reduced API', since they require less legacy
application support.  That may give LibReSSL the opportunity to head
in the same direction, if the applications are willing...

Secondly, a lot of misinformation is being spread about the effort
required to get LibReSSL-portable out the door.  We've stripped the
code so that it is POSIX-only.  Therefore "Linux" compat is really not
hard.  We basically just need the following parts to be finished:

- A clean build framework

- and the finetunings of portable versions of our safetybelts:
   arc4random    strlcpy      strlcat
   explicit_bzero   reallocarray
   timingsafe_bcmp timingsafe_memcmp

So please stop believing rumours that we've made it hard to port!  The
entire world went to POSIX, and that's all this code needs to support.
It is a small step.  I don't think it will take much longer.

patience...
_______________________________________________________________________
https://news.ycombinator.com/item?id=1231734
https://lwn.net/Articles/625506/


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---