Hello,
To start off, I would like to say that when we first switched to
libressl, it was largely as a reaction to what we perceived as bad
maintenance being done in openssl. At the time, it was a perfectly
reasonable and valid reaction.
There were other reasons to care, too: the libressl guys were working
to relicense as much of libressl as possible under ISC license.
But openssl 1.1 has a different situation: Akamai and the Core
Infrastructure Initiative have come together to sponsor development
and maintenance of openssl since we switched, which means that there's
higher quality maintenance occuring now. They are also working on a
relicensing process, much like the libressl guys are doing, which has
a larger scope[1]. Meanwhile, the libressl guys have been removing
functionality we depend on, such as support for hardware accelerators
(ENGINE apis), switching from 64-bit TAIN date calculations to time_t
(because time_t is good enough on OpenBSD) and dropping openssl 1.0.1
APIs they see as unsuitable.
libressl promised to retain compatibility with 1.0.1g APIs, but has
failed to do so. As such, there is an increasing workload to keep
packages compatible with libressl as it evolves. Therefore, it is
obviously not truly a suitable provider for the openssl package, and
we should switch back to proper openssl as the default. We will
however retain libressl for packages which require it (for example,
ones using the new libtls APIs).
If there is no objection to this proposed change, I intend to do the
swap next week.
[1]: https://license.openssl.org/
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 02/08/18 11:23, William Pitcock wrote:
> openssl 1.1 has a different situation: Akamai and the Core> Infrastructure Initiative have come together to sponsor development> and maintenance of openssl since we switched, which means that there's> higher quality maintenance occuring now.
This is good to hear, I didn't know about Akamai's involvement.
> They are also working on a> relicensing process, much like the libressl guys are doing, which has> a larger scope[1].
That would be a boon; I wish them all the best in their efforts.
> Meanwhile, the libressl guys have been removing> functionality we depend on, such as support for hardware accelerators> (ENGINE apis), switching from 64-bit TAIN date calculations to time_t> (because time_t is good enough on OpenBSD) and dropping openssl 1.0.1> APIs they see as unsuitable.>> libressl promised to retain compatibility with 1.0.1g APIs, but has> failed to do so. As such, there is an increasing workload to keep> packages compatible with libressl as it evolves.
These have all caused a number of problems trying to run certain
packages on Alpine. For example, since python -dev requires
libressl-dev, you can't build Python packages that require OpenSSL. Not
to mention the fact that LibreSSL just plain doesn't work on Adélie's
32-bit PowerPC and x86 ports.
> Therefore, it is> obviously not truly a suitable provider for the openssl package, and> we should switch back to proper openssl as the default. We will> however retain libressl for packages which require it (for example,> ones using the new libtls APIs).
+1.
> [1]: https://license.openssl.org/
One question I do have is: is there a way to disable the OpenSSL
compatibility in LibreSSL? It would be good for packages that require
LibreSSL (libressl-dev) to be buildable even if openssl-dev is installed
(preventing something like the above Python situation).
Best regards,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
On 02/08/18 12:05, Kevin Chadwick wrote:
> Do you have a list of packages at all?
This is an easy list, it is probably not the entire list:
awilcox on ciall /usr/src/alpine-aports $ find . -name
'*libressl*.patch' | sort
./community/asio/libressl.patch
./community/cargo/openssl-fix-libressl-cmsh-detection.patch
./community/cargo/openssl-libressl263-compat.patch
./community/erlang/0011-fix-libressl-build.patch
./community/freerdp/libressl-2.5.patch
./community/gsoap/libressl.patch
./community/heirloom-mailx/libressl.patch
./community/isync/libressl-compat.patch
./community/john/libressl.patch
./community/mongodb-tools/libressl.patch
./community/pgbouncer/libressl-2.5.patch
./community/qt5-qtbase/libressl-compat.patch
./community/retawq/libressl.patch
./community/rethinkdb/libressl-all.patch
./community/stunnel/stunnel-libressl.patch
./community/xchat/libressl.patch
./community/yadifa/libressl-compat.patch
./main/boost/libressl.patch
./main/elinks/libressl-2.5.patch
./main/fetchmail/libressl.patch
./main/freeswitch/sofia-sip-libressl.patch
./main/haproxy/fix-libressl-2.5.patch
./main/hexchat/libressl.patch
./main/hostapd/libressl-compat.patch
./main/krb5/libressl.patch
./main/ldns/1.6.17-libressl.patch
./main/libevent/libressl.patch
./main/libgit2/libressl.patch
./main/lua-cqueues/libressl-2.5.patch
./main/mosquitto/libressl.patch
./main/neon/fix-libressl.patch
./main/open-isns/libressl.patch
./main/openldap/libressl.patch
./main/opensmtpd/libressl-compat.patch
./main/openvswitch/libressl-compat.patch
./main/opusfile/libressl.patch
./main/partimage/libressl.patch
./main/perl-crypt-ssleay/libressl.patch
./main/postfix/libressl.patch
./main/python3/libressl.patch
./main/qt/qtcore-4.8.5-libressl.patch
./main/serf/libressl.patch
./main/spice-gtk/libressl.patch
./main/spice/libressl.patch
./main/strongswan/libressl.patch
./main/tlsdate/libressl-no-sslv3.patch
./main/tlsdate/libressl-sslstate.patch
./main/transmission/libressl.patch
./main/wpa_supplicant/libressl.patch
./main/xrdp/libressl-support.patch
./testing/bobcat/libressl-compatibility.patch
./testing/ejabberd/libressl.patch
./testing/imapfilter/libressl.patch
./testing/libimobiledevice/01-libressl.patch
./testing/litespeed/libressl.patch
./testing/megatools/libressl.patch
./testing/openconnect/openconnect-7.08-libressl251.patch
./testing/prayer/libressl.patch
./testing/proftpd/libressl.patch
./testing/tarantool/tests-libressl-compat.patch
./testing/x11vnc/libressl.patch
It isn't just this. Qt 5.10 introduces new dependency on OpenSSL 1.1
APIs for improved security, and LibreSSL does not implement those APIs
at all.
Also, as mentioned in my other email, one pain point is something like
mailman or taiga, which require Python Cryptography package version 1.7.
This version requires OpenSSL APIs that LibreSSL removed. That'd be
fine, since it could be built against OpenSSL instead, however!
libressl-dev and openssl-dev conflict, and python-dev installs
libressl-dev because Python is built against LibreSSL. That means you
can't actually build OpenSSL-requiring Python packages at all.
I'd imagine similar issues would be had with Ruby, Perl, Node, and all
the rest. Certainly any Qt application that needs OpenSSL APIs (like
Kleopatra, KDE's key management utility) won't be buildable as well.
This is a maintanence burden that prevents the Alpine community from
focusing on important issues. What is better: "making a stand" for
LibreSSL (which does not even care about Linux or ABI compatibility), or
investing that time and effort into our correct license field project?
Or porting more software to musl, improving the quality of more
codebases and the entire open source ecosystem? Or porting Alpine to
other architectures like better ARM support and MIPS support?
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
Hello,
On Thu, Feb 8, 2018 at 12:05 PM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
> On Thu, 8 Feb 2018 11:23:26 -0600>>>> Meanwhile, the libressl guys have been removing>> functionality we depend on, such as support for hardware accelerators>> (ENGINE apis), switching from 64-bit TAIN date calculations to time_t>> (because time_t is good enough on OpenBSD) and dropping openssl 1.0.1>> APIs they see as unsuitable.>> This is a strange take on the situation to say the least.
I would argue that 32-bit systems not being able to validate
certificates from CAs who have expiry dates past year 2038 is a major
security problem. This is caused by the elimination of the TAI64N
date calculation code.
> Apis were dropped for good reasons and they have committed to> implementing new API components that seem sensible and are most> desired. However the primary goal is security not functionality and if> anything you could argue that OpenSSL is still way too complex to be> fit for purpose.>> Multiple CVEs have been avoided by LibreSSL already.
Those CVEs were not avoided by removal of the functionality I listed
above. In fact, the removal of the functionality I listed above has
introduced security regressions.
>> libressl promised to retain compatibility with 1.0.1g APIs, but has>> failed to do so.>> I am not clear on the versions but I do know that they promised to be a> replacement at the time and whilst I am not really involved I have seen> comments that OpenSSL seem to be purposefully causing issues.
This is not the case; LibreSSL have removed APIs that were part of the
OpenSSL 1.0.1g set. It is possible today, to have a program which
successfully compiles under OpenSSL 1.0.1g (e.g. the release at the
time of the LibreSSL fork) and fails to compile under LibreSSL.
Accordingly, they broke their promise.
>> As such, there is an increasing workload to keep>> packages compatible with libressl as it evolves. Therefore, it is>> obviously not truly a suitable provider for the openssl package, and>> we should switch back to proper openssl as the default. We will>> Do you have a list of packages at all?>> proper!?!? I guess LibreSSL has less resources and hope that is what> you meant.
By proper, I mean an implementation that is conformant with the
OpenSSL 1.0.1g API, which is what was promised by LibreSSL.
> I believe the key protection improvements were/are better in LibreSSL> and so the fix for heartbleed was properly done!
The protection improvements are the same: the custom memory management
code has been removed from both.
> I understand your workload point and that Alpine is far from in> control over this but I don't like how this mail has been written and> wonder what environment caused that? Also, there are other libraries> like mbedtls and boring ssl, aren't these packages breaking> compatibility with them and reducing their scope? (Not an alpine issue> of course)
mbedtls has never implemented the OpenSSL API. BoringSSL is not
appropriate as a system openssl implementation, it is mostly to
support Chromium and other Google products.
> So maybe the packages like Python have an agenda or should slow down?> Python could also remove RWX memory requirements by default as a higher> priority?
Any interpreter which has the ability to JIT (such as Python 3.6 with
an appropriate JIT module loaded) requires RWX. PaX will never allow
a page which has been marked PROT_WRITE to ever become PROT_EXEC. It
is what it is, and it's also unrelated to the LibreSSL vs OpenSSL 1.1
discussion.
> (Python, saying they want to remove existing code for more security> (would it be compiled) but that the existing code is secure). Have they> audited the OpenSSL code themselves? I understand the joy of code> deletion however ;)
It is not Python that is the problem here; it is LibreSSL.
>> however retain libressl for packages which require it (for example,>> ones using the new libtls APIs).>> A properly simple and secure API?
Sure, and that simple and secure API can be implemented using a
different TLS library other than LibreSSL, which still has plenty of
OpenSSL technical debt. It would make more sense from our perspective
to provide an alternative libtls that uses BearSSL or mbedTLS or
something else that is very small and already audited.
>>> If there is no objection to this proposed change, I intend to do the>> swap next week.>> No objection, just not impressed. Alpine could make a stand but what> difference would it make.
A stand for what? LibreSSL has removed support for things we want,
such as cryptographic accelerators and TAIN-based date calculations.
Neither of those functionality were removed for security reasons, but
instead because the OpenBSD developers did not want to deal with
maintaining them. I can understand their decision in doing so, but
that doesn't mean that the cost-benefit analysis works out favorably
for us anymore.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Thu, Feb 8, 2018 at 12:16 PM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
> On Thu, 8 Feb 2018 12:09:38 -0600>>>> > openssl 1.1 has a different situation: Akamai and the Core>> > Infrastructure Initiative have come together to sponsor development>> > and maintenance of openssl since we switched, which means that>> > there's higher quality maintenance occuring now.>>>> This is good to hear, I didn't know about Akamai's involvement.>> I am fairly sure that funding was never a real issue and certainly not> one that could explain heartbleed.
Heartbleed is explained by the support for custom allocators in
combination with their own custom allocator. This functionality was
disabled in Alpine's openssl packaging prior to Heartbleed disclosure
and was ultimately removed upstream. Much like other distributions,
we actually do look at our security-critical code and make
security-conscious decisions.
As far as funding goes, when your funding comes from consulting
contracts (adding new things to a product), then a majority of your
resources go towards adding new features. The Akamai and CII funding
is explicitly for dedicated maintenance so that there is not a
capitalistic inversion of priorities.
> Akamai is probably also one of the lead reasons why people think> websites are secure when they are not necessarily too (akamai cert for> akamai server for download of acme.exe). Simplicity, cost issue?
I would argue Cloudflare is a larger offender there.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 02/08/18 13:22, Kevin Chadwick wrote:
> Mark Espie -> > you've got to realize that openssl deliberately broke compatibility> with previous versions precisely to try to stop libressl.
OpenSSL "broke" compatibility with previous versions /in an attempt to
create a better API/. By "broke", that means removing functions that
were already deprecrated. It had nothing to do with LibreSSL, but I'm
glad they have a victim complex.
>> By proper, I mean an implementation that is conformant with the>> OpenSSL 1.0.1g API, which is what was promised by LibreSSL.>>> > Is OpenSSL conformant, see above?
Yes, it isn't however conformant with 0.9 any more.
>> The protection improvements are the same: the custom memory management>> code has been removed from both.>>> > You clearly do not know about the extra protections and priviledge> separation in LibreSSL!!!
You must be talking about Pledge, which allows LibreSSL to declare what
system calls it will and will not be using. Of course, Pledge is only
available in OpenBSD.
> I guess you think PAM is great too?
Completely unrelated and unnecessary question.
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
Hello,
On Thu, Feb 8, 2018 at 1:22 PM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
> On Thu, 8 Feb 2018 12:53:06 -0600>>>> Hello,>>>> On Thu, Feb 8, 2018 at 12:05 PM, Kevin Chadwick <m8il1ists@gmail.com>>> wrote:>> > On Thu, 8 Feb 2018 11:23:26 -0600>> >>> >>> >> Meanwhile, the libressl guys have been removing>> >> functionality we depend on, such as support for hardware>> >> accelerators (ENGINE apis), switching from 64-bit TAIN date>> >> calculations to time_t (because time_t is good enough on OpenBSD)>> >> and dropping openssl 1.0.1 APIs they see as unsuitable.>> >>> > This is a strange take on the situation to say the least.>>>> I would argue that 32-bit systems not being able to validate>> certificates from CAs who have expiry dates past year 2038 is a major>> security problem. This is caused by the elimination of the TAI64N>> date calculation code.>> That is not the part that I was referring to, however as I> understand it this isn't an issue on OpenBSD or any constrained> embedded system that I develop??
It is not an issue on OpenBSD, they have a 64-bit time_t across all
architectures. Unfortunately, the Linux kernel does not yet offer a
syscall ABI that allows a 64-bit time_t on 32-bit architectures.
There is some added expense in implementing such a syscall ABI due to
the way the Linux syscall ABI works in general, but they are working
to fix the syscalls. Accordingly, this is an issue on Alpine 32-bit
systems, where today, LibreSSL will fail to validate certificate
chains where the root CA has already been updated to a expiry greater
than year 2038.
>> > Apis were dropped for good reasons and they have committed to>> > implementing new API components that seem sensible and are most>> > desired. However the primary goal is security not functionality and>> > if anything you could argue that OpenSSL is still way too complex>> > to be fit for purpose.>> >>> > Multiple CVEs have been avoided by LibreSSL already.>>>> Those CVEs were not avoided by removal of the functionality I listed>> above. In fact, the removal of the functionality I listed above has>> introduced security regressions.>>>> That wasn't the point and I doubt you actually know that, but nvm.
I understand your point: less code means less bugs. While this is
typically true, the real fix is to kick the OpenSSL habit altogether.
This means encouraging upstreams to use neither LibreSSL nor OpenSSL.
If OpenSSL is heroin, LibreSSL is methadone.
>> >> libressl promised to retain compatibility with 1.0.1g APIs, but has>> >> failed to do so.>> >>> > I am not clear on the versions but I do know that they promised to>> > be a replacement at the time and whilst I am not really involved I>> > have seen comments that OpenSSL seem to be purposefully causing>> > issues.>>>> This is not the case; LibreSSL have removed APIs that were part of the>> OpenSSL 1.0.1g set. It is possible today, to have a program which>> successfully compiles under OpenSSL 1.0.1g (e.g. the release at the>> time of the LibreSSL fork) and fails to compile under LibreSSL.>> Accordingly, they broke their promise.>>>> Christian Heimes ->> The situation is, LibreSSL hasn't been compatible with any supported> OpenSSL version since 2017-01-01. The lack of compatibility with the> industry standard OpenSSL either means: drop LibreSSL or don't improve> security of Python's ssl module. 1 reply 0 retweets 1 like
OpenSSL 1.0.1g is still supported by Python. This kind of
demonstrates my point, now doesn't it?
>> Mark Espie ->> you've got to realize that openssl deliberately broke compatibility> with previous versions precisely to try to stop libressl. we're talking> crypto, more fluffy interfaces are not necessarily better. Especially> when they allow people to create insecure crypto.
It is possible to build OpenSSL 1.0.1g applications against OpenSSL
1.1 without major modifications. But as a developer, it is the
responsibility of the developer to follow the evolution of the APIs
you are using.
As for breaking compatibility with previous versions to stop libressl:
the problem is actually that LibreSSL made downstream changes and
OpenSSL made equivalent changes, and the APIs are different. This may
or may not be intentional, but it does not matter to me because my
points are focused on the OpenSSL 1.0.1g API compatibility which is
the same for both libraries.
>> >> As such, there is an increasing workload to keep>> >> packages compatible with libressl as it evolves. Therefore, it is>> >> obviously not truly a suitable provider for the openssl package,>> >> and we should switch back to proper openssl as the default. We>> >> will>> >>> > Do you have a list of packages at all?>> >>> > proper!?!? I guess LibreSSL has less resources and hope that is what>> > you meant.>>>> By proper, I mean an implementation that is conformant with the>> OpenSSL 1.0.1g API, which is what was promised by LibreSSL.>>>> Is OpenSSL conformant, see above?
Yes.
>> > I believe the key protection improvements were/are better in>> > LibreSSL and so the fix for heartbleed was properly done!>>>> The protection improvements are the same: the custom memory management>> code has been removed from both.>>>> You clearly do not know about the extra protections and priviledge> separation in LibreSSL!!!
Privilege separation does not protect against buffer overruns. Also,
most likely, the "extra protections" you refer to are already present
in Alpine's OpenSSL package as an effect of how we build OpenSSL.
>> > I understand your workload point and that Alpine is far from in>> > control over this but I don't like how this mail has been written>> > and wonder what environment caused that? Also, there are other>> > libraries like mbedtls and boring ssl, aren't these packages>> > breaking compatibility with them and reducing their scope? (Not an>> > alpine issue of course)>>>> mbedtls has never implemented the OpenSSL API. BoringSSL is not>> appropriate as a system openssl implementation, it is mostly to>> support Chromium and other Google products.>>>> But packages like python have been demonstrated to run on the> constrained systems that they are designed for. OpenSSL is way too big.> I agree this is a Linux rather than Alpine issue, except for your desire> for more archs.
OpenSSL and LibreSSL have less than 1MB installed size difference.
Nobody has ever said "lets save resources by installing an OpenSSL
fork instead of OpenSSL." Resource constrained systems almost always
use a library designed for embedded use from the beginning, such as
mbedTLS or BearSSL. We should absolutely do the same in apk-tools, so
there is no OpenSSL/LibreSSL implementation on the system to begin
with.
>> > So maybe the packages like Python have an agenda or should slow>> > down? Python could also remove RWX memory requirements by default>> > as a higher priority?>>>> Any interpreter which has the ability to JIT (such as Python 3.6 with>> an appropriate JIT module loaded) requires RWX. PaX will never allow>> a page which has been marked PROT_WRITE to ever become PROT_EXEC. It>> is what it is, and it's also unrelated to the LibreSSL vs OpenSSL 1.1>> discussion.>>>> The point was that maybe Python should sort that out before removing> code here.
And my point is that there is nothing to sort out. Also, to be clear,
Python was never an element of my rationale for switching the default.
>> A stand for what? LibreSSL has removed support for things we want,>> such as cryptographic accelerators and TAIN-based date calculations.>> Neither of those functionality were removed for security reasons, but>> instead because the OpenBSD developers did not want to deal with>> maintaining them. I can understand their decision in doing so, but>> that doesn't mean that the cost-benefit analysis works out favorably>> for us anymore.>> I disagree as explained at the time of their removal. You don't want> hairy/dangerous code in a security library.
TAI64N is less hairy and less dangerous than POSIX time_t date
calculations because they are provably accurate. I will admit that
cryptographic accelerator support can be tricky to get right, however.
> I guess you think PAM is great too?
I believe PAM should be sandboxed with privilege separation and
thankfully in Adelie we have been scheming a way to do this, but this
is unrelated to LibreSSL vs OpenSSL. I will write to the list about
upstreaming PAM sandboxing once we have proven it in Adelie Linux 2.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Thu, Feb 8, 2018 at 4:40 PM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
>> > You clearly do not know about the extra protections and priviledge>> > separation in LibreSSL!!!>>>> You must be talking about Pledge, which allows LibreSSL to declare>> what system calls it will and will not be using. Of course, Pledge>> is only available in OpenBSD.>> No, Pledge is not priviledge seperation or even close to it, though it> does benefit from it!>> Buffer overflows are far less dangerous with priviledge separation> deployed and no the way you compile Alpine will not accomplish anything> like proper priviledge seperation.
Alpine has been using privilege separation for years where possible
regardless of using LibreSSL or not. Privilege separation would not
have prevented Heartbleed, as the unprivileged process would still
require a copy of the X509 objects in order to perform cryptographic
operations.
Also, buffer overflows are different than buffer over-reads. An
over-read is when a read goes past the end of a buffer, an overflow is
when a write goes past the end of a buffer. Heartbleed is an example
of an over-read, and the correct mitigation is to ensure that
allocation sizes are correct and non-contiguous.
> I guess you can see how with libtls then heartbleed would have had> much less affect. OpenBSD have been pioneering in depth use of> priviledge seperation with layers of security on top for years,
No, I am pretty sure I don't see how libtls would have protected
against Heartbleed (see above).
> _______________________________________________________________________>> As the OpenBSD 5.7 development effort comes to a close, so does the> LibreSSL 2.1.x branch. The next release will begin the 2.2.x development> branch.>> User-visible features:>> * Improvements to libtls:> - a new API for loading CA chains directly from memory instead of a> file, allowing verification with privilege separation in a chroot> without direct access to CA certificate files.> ________________________________________________________________________
This type of design is not provided by libtls itself, but libtls
provides the primitives for it. It is also possible to accomplish
this design through the OpenSSL 1.0.1g API using a series of
SSL_CTX_add0_chain_cert() calls (which is essentially what libtls does
internally), or just loading the certificate chain into X509 objects
prior to calling fork(2). It is important to note that the isolated
process still needs a copy of the X509 objects in memory in order to
perform cryptographic operations with the certificates (such as
setting up new TLS sessions), so the purpose of privilege separation
here would not be to "protect the keys." They are needed in order to
do cryptographic operations.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
>But openssl 1.1 has a different situation: Akamai and the Core>Infrastructure Initiative have come together to sponsor development>and maintenance of openssl since we switched, which means that there's>higher quality maintenance occuring now. They are also working on a>relicensing process, much like the libressl guys are doing, which has>a larger scope[1]. Meanwhile, the libressl guys have been removing>functionality we depend on, such as support for hardware accelerators>(ENGINE apis), switching from 64-bit TAIN date calculations to time_t>(because time_t is good enough on OpenBSD) and dropping openssl 1.0.1>APIs they see as unsuitable.>>libressl promised to retain compatibility with 1.0.1g APIs, but has>failed to do so.
These arguments sound reasonable, so despite having lobbied for the
switch to libressl at the time, I have no objection to switching back
to openssl now.
--
Laurent
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
I concur
On 8 Feb 2018 5:53 pm, "Laurent Bercot" <ska-devel@skarnet.org> wrote:
> But openssl 1.1 has a different situation: Akamai and the Core>> Infrastructure Initiative have come together to sponsor development>> and maintenance of openssl since we switched, which means that there's>> higher quality maintenance occuring now. They are also working on a>> relicensing process, much like the libressl guys are doing, which has>> a larger scope[1]. Meanwhile, the libressl guys have been removing>> functionality we depend on, such as support for hardware accelerators>> (ENGINE apis), switching from 64-bit TAIN date calculations to time_t>> (because time_t is good enough on OpenBSD) and dropping openssl 1.0.1>> APIs they see as unsuitable.>>>> libressl promised to retain compatibility with 1.0.1g APIs, but has>> failed to do so.>>>> These arguments sound reasonable, so despite having lobbied for the> switch to libressl at the time, I have no objection to switching back> to openssl now.>> --> Laurent>>>> ---> Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org> Help: alpine-devel+help@lists.alpinelinux.org> --->>
On Thu, 8 Feb 2018 11:23:26 -0600
> Meanwhile, the libressl guys have been removing> functionality we depend on, such as support for hardware accelerators> (ENGINE apis), switching from 64-bit TAIN date calculations to time_t> (because time_t is good enough on OpenBSD) and dropping openssl 1.0.1> APIs they see as unsuitable.
This is a strange take on the situation to say the least.
Apis were dropped for good reasons and they have committed to
implementing new API components that seem sensible and are most
desired. However the primary goal is security not functionality and if
anything you could argue that OpenSSL is still way too complex to be
fit for purpose.
Multiple CVEs have been avoided by LibreSSL already.
> > libressl promised to retain compatibility with 1.0.1g APIs, but has> failed to do so.
I am not clear on the versions but I do know that they promised to be a
replacement at the time and whilst I am not really involved I have seen
comments that OpenSSL seem to be purposefully causing issues.
> As such, there is an increasing workload to keep> packages compatible with libressl as it evolves. Therefore, it is> obviously not truly a suitable provider for the openssl package, and> we should switch back to proper openssl as the default. We will
Do you have a list of packages at all?
proper!?!? I guess LibreSSL has less resources and hope that is what
you meant.
I believe the key protection improvements were/are better in LibreSSL
and so the fix for heartbleed was properly done!
I understand your workload point and that Alpine is far from in
control over this but I don't like how this mail has been written and
wonder what environment caused that? Also, there are other libraries
like mbedtls and boring ssl, aren't these packages breaking
compatibility with them and reducing their scope? (Not an alpine issue
of course)
So maybe the packages like Python have an agenda or should slow down?
Python could also remove RWX memory requirements by default as a higher
priority?
(Python, saying they want to remove existing code for more security
(would it be compiled) but that the existing code is secure). Have they
audited the OpenSSL code themselves? I understand the joy of code
deletion however ;)
> however retain libressl for packages which require it (for example,> ones using the new libtls APIs).
A properly simple and secure API?
> If there is no objection to this proposed change, I intend to do the> swap next week.
No objection, just not impressed. Alpine could make a stand but what
difference would it make.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Thu, 8 Feb 2018 12:09:38 -0600
> > openssl 1.1 has a different situation: Akamai and the Core> > Infrastructure Initiative have come together to sponsor development> > and maintenance of openssl since we switched, which means that> > there's higher quality maintenance occuring now. > > This is good to hear, I didn't know about Akamai's involvement.
I am fairly sure that funding was never a real issue and certainly not
one that could explain heartbleed.
Akamai is probably also one of the lead reasons why people think
websites are secure when they are not necessarily too (akamai cert for
akamai server for download of acme.exe). Simplicity, cost issue?
Who's Responsibility? Just the download providers domain?
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Thu, 8 Feb 2018 12:53:06 -0600
> Hello,> > On Thu, Feb 8, 2018 at 12:05 PM, Kevin Chadwick <m8il1ists@gmail.com>> wrote:> > On Thu, 8 Feb 2018 11:23:26 -0600> >> > > >> Meanwhile, the libressl guys have been removing> >> functionality we depend on, such as support for hardware> >> accelerators (ENGINE apis), switching from 64-bit TAIN date> >> calculations to time_t (because time_t is good enough on OpenBSD)> >> and dropping openssl 1.0.1 APIs they see as unsuitable. > >> > This is a strange take on the situation to say the least. > > I would argue that 32-bit systems not being able to validate> certificates from CAs who have expiry dates past year 2038 is a major> security problem. This is caused by the elimination of the TAI64N> date calculation code.
That is not the part that I was referring to, however as I
understand it this isn't an issue on OpenBSD or any constrained
embedded system that I develop??
> > > Apis were dropped for good reasons and they have committed to> > implementing new API components that seem sensible and are most> > desired. However the primary goal is security not functionality and> > if anything you could argue that OpenSSL is still way too complex> > to be fit for purpose.> >> > Multiple CVEs have been avoided by LibreSSL already. > > Those CVEs were not avoided by removal of the functionality I listed> above. In fact, the removal of the functionality I listed above has> introduced security regressions.>
That wasn't the point and I doubt you actually know that, but nvm.
> >> libressl promised to retain compatibility with 1.0.1g APIs, but has> >> failed to do so. > >> > I am not clear on the versions but I do know that they promised to> > be a replacement at the time and whilst I am not really involved I> > have seen comments that OpenSSL seem to be purposefully causing> > issues. > > This is not the case; LibreSSL have removed APIs that were part of the> OpenSSL 1.0.1g set. It is possible today, to have a program which> successfully compiles under OpenSSL 1.0.1g (e.g. the release at the> time of the LibreSSL fork) and fails to compile under LibreSSL.> Accordingly, they broke their promise.>
Christian Heimes -
The situation is, LibreSSL hasn't been compatible with any supported
OpenSSL version since 2017-01-01. The lack of compatibility with the
industry standard OpenSSL either means: drop LibreSSL or don't improve
security of Python's ssl module. 1 reply 0 retweets 1 like
Mark Espie -
you've got to realize that openssl deliberately broke compatibility
with previous versions precisely to try to stop libressl. we're talking
crypto, more fluffy interfaces are not necessarily better. Especially
when they allow people to create insecure crypto.
> >> As such, there is an increasing workload to keep> >> packages compatible with libressl as it evolves. Therefore, it is> >> obviously not truly a suitable provider for the openssl package,> >> and we should switch back to proper openssl as the default. We> >> will > >> > Do you have a list of packages at all?> >> > proper!?!? I guess LibreSSL has less resources and hope that is what> > you meant. > > By proper, I mean an implementation that is conformant with the> OpenSSL 1.0.1g API, which is what was promised by LibreSSL.>
Is OpenSSL conformant, see above?
> > I believe the key protection improvements were/are better in> > LibreSSL and so the fix for heartbleed was properly done! > > The protection improvements are the same: the custom memory management> code has been removed from both.>
You clearly do not know about the extra protections and priviledge
separation in LibreSSL!!!
> > I understand your workload point and that Alpine is far from in> > control over this but I don't like how this mail has been written> > and wonder what environment caused that? Also, there are other> > libraries like mbedtls and boring ssl, aren't these packages> > breaking compatibility with them and reducing their scope? (Not an> > alpine issue of course) > > mbedtls has never implemented the OpenSSL API. BoringSSL is not> appropriate as a system openssl implementation, it is mostly to> support Chromium and other Google products.>
But packages like python have been demonstrated to run on the
constrained systems that they are designed for. OpenSSL is way too big.
I agree this is a Linux rather than Alpine issue, except for your desire
for more archs.
> > So maybe the packages like Python have an agenda or should slow> > down? Python could also remove RWX memory requirements by default> > as a higher priority? > > Any interpreter which has the ability to JIT (such as Python 3.6 with> an appropriate JIT module loaded) requires RWX. PaX will never allow> a page which has been marked PROT_WRITE to ever become PROT_EXEC. It> is what it is, and it's also unrelated to the LibreSSL vs OpenSSL 1.1> discussion.>
The point was that maybe Python should sort that out before removing
code here.
> > A stand for what? LibreSSL has removed support for things we want,> such as cryptographic accelerators and TAIN-based date calculations.> Neither of those functionality were removed for security reasons, but> instead because the OpenBSD developers did not want to deal with> maintaining them. I can understand their decision in doing so, but> that doesn't mean that the cost-benefit analysis works out favorably> for us anymore.
I disagree as explained at the time of their removal. You don't want
hairy/dangerous code in a security library.
I guess you think PAM is great too?
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Thu, 8 Feb 2018 13:33:58 -0600
> > You clearly do not know about the extra protections and priviledge> > separation in LibreSSL!!! > > You must be talking about Pledge, which allows LibreSSL to declare> what system calls it will and will not be using. Of course, Pledge> is only available in OpenBSD.
No, Pledge is not priviledge seperation or even close to it, though it
does benefit from it!
Buffer overflows are far less dangerous with priviledge separation
deployed and no the way you compile Alpine will not accomplish anything
like proper priviledge seperation.
I guess you can see how with libtls then heartbleed would have had
much less affect. OpenBSD have been pioneering in depth use of
priviledge seperation with layers of security on top for years,
_______________________________________________________________________
As the OpenBSD 5.7 development effort comes to a close, so does the
LibreSSL 2.1.x branch. The next release will begin the 2.2.x development
branch.
User-visible features:
* Improvements to libtls:
- a new API for loading CA chains directly from memory instead of a
file, allowing verification with privilege separation in a chroot
without direct access to CA certificate files.
________________________________________________________________________
Qmail, Postfix and Dovecot are the original examples of priviledge
separation though OpenBSD has taken it to new levels since throughout
it's daemons.
In fact. I don't think pledge was really around at the time anyway.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Thu, 8 Feb 2018 17:43:31 -0600
> Hello,> > On Thu, Feb 8, 2018 at 4:40 PM, Kevin Chadwick <m8il1ists@gmail.com>> wrote:> >> > You clearly do not know about the extra protections and> >> > priviledge separation in LibreSSL!!! > >>> >> You must be talking about Pledge, which allows LibreSSL to declare> >> what system calls it will and will not be using. Of course, Pledge> >> is only available in OpenBSD. > >> > No, Pledge is not priviledge seperation or even close to it, though> > it does benefit from it!> >> > Buffer overflows are far less dangerous with priviledge separation> > deployed and no the way you compile Alpine will not accomplish> > anything like proper priviledge seperation. > > Alpine has been using privilege separation for years where possible> regardless of using LibreSSL or not. Privilege separation would not> have prevented Heartbleed, as the unprivileged process would still> require a copy of the X509 objects in order to perform cryptographic> operations.
Cool, glad to hear it. My faith in Alpine is restored somewhat :)
That depends on the design which is also why I said compilation
wouldn't cut it.
http://insanecoding.blogspot.co.uk/2014/05/protecting-private-keys.htmlhttps://marc.info/?l=openbsd-cvs&m=139879883203226&w=2> > _______________________________________________________________________> >> > As the OpenBSD 5.7 development effort comes to a close, so does the> > LibreSSL 2.1.x branch. The next release will begin the 2.2.x> > development branch.> >> > User-visible features:> >> > * Improvements to libtls:> > - a new API for loading CA chains directly from memory instead> > of a file, allowing verification with privilege separation in a> > chroot without direct access to CA certificate files.> > ________________________________________________________________________ > > This type of design is not provided by libtls itself, but libtls> provides the primitives for it. It is also possible to accomplish> this design through the OpenSSL 1.0.1g API using a series of> SSL_CTX_add0_chain_cert() calls (which is essentially what libtls does> internally), or just loading the certificate chain into X509 objects> prior to calling fork(2).
And I am fairly sure the feature python wants is very simple and a lot
easier than that and not difficult security wise (oring etc.).
My question is, whether they have an agenda. Perhaps the build issues
here are different and not fully understood by me though.
I originally thought it was simply the following API call being desired
and I am under the impression LibreSSL will cater for it and it
wouldn't land in stable until 2019.
https://www.openssl.org/docs/man1.0.2/crypto/X509_VERIFY_PARAM_set1_host.html
A much larger list has been shown with build issues that I cannot look
into so...
It was just the tone of the message that made me respond.
Regards
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 02/09/18 12:18, Natanael Copa wrote:
> "Sorry but you can forget running alpine on your RPI/old x86,> but don't worry, you still have LibreSSL!"
...and MIPS SoCs, and routers, and AmigaOnes, and Power Mac G3/G4s, and
if RISC-V ever ships, and a lot of the phones and tablets that
postmarketOS are targeting...
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
On Thu, 8 Feb 2018 12:19:22 -0600
> This is a maintanence burden that prevents the Alpine community from> focusing on important issues. What is better: "making a stand" for> LibreSSL (which does not even care about Linux or ABI compatibility),
I just want to add that I think that this is unfair. OpenBSD goes out of
it's way for portability but they won't ignore things like encouraging
poor RNG handling which has ended with great improvements in Linux.
A more accurate statement would be that OpenBSD goals of simplicity and
security are not aligned with Linux goals of uptime and mass adoption.
OpenBSD also obviously has less man power as they desire to, in some
ways.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Fri, Feb 9, 2018 at 1:09 PM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
> On Fri, 9 Feb 2018 12:28:20 -0600>>>> > "Sorry but you can forget running alpine on your RPI/old x86,>> > but don't worry, you still have LibreSSL!">>>> ...and MIPS SoCs, and routers, and AmigaOnes, and Power Mac G3/G4s,>> and if RISC-V ever ships, and a lot of the phones and tablets that>> postmarketOS are targeting...>> I understand and I know this doesn't help now but how far away is the> Linux fix?
Syscall ABI is defined per architecture, but on the architectures we
care about, it will probably be a year or two before the new syscall
ABI is ready. Unfortunately, the Linux kernel does not have the same
advantages of rapid iteration that the OpenBSD guys have, since
OpenBSD has a small install base, it does not really matter if there
are problems in the short term, since enthusiasts are the ones who use
OpenBSD.
Linux developers are converting the syscalls one at a time.
> It is past the point where Linux needs to fix this before offline> devices are deployed that may still be running in 20 years.>> Admittedly Pi HW/flash may not last that long from the irresponsible> suppliers that may develop such devices but the number will be> increasing.
We certainly agree that time_t should have been moved to 64-bit a long time ago.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Fri, Feb 9, 2018 at 11:59 AM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> Natanael Copa <ncopa@alpinelinux.org> wrote:> |On Thu, 8 Feb 2018 11:23:26 -0600> |William Pitcock <nenolod@dereferenced.org> wrote:> |> |> libressl promised to retain compatibility with 1.0.1g APIs, but has> |> failed to do so. As such, there is an increasing workload to keep> |> packages compatible with libressl as it evolves. Therefore, it is> |> obviously not truly a suitable provider for the openssl package, and> |> we should switch back to proper openssl as the default. We will> |> however retain libressl for packages which require it (for example,> |> ones using the new libtls APIs).> |>> |> If there is no objection to this proposed change, I intend to do the> |> swap next week.> |> |I'd like to wait with the switch til we fully solved the kernel issues> |in stable branches.>> I live in fear of updating, especially the server, i get:>> 00:00:13.070040 emR3Debug: rc=VERR_PGM_INVALID_CR3_ADDR> 00:00:14.078859 Changing the VM state from 'RUNNING' to 'GURU_MEDITATION'.>> on an old VirtualBox with -vanilla 4.14.17.
Out of curiosity, do you get that with KPTI disabled? Boot with nopti
command-line option.
Smells like a regression...
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Fri, Feb 9, 2018 at 11:38 AM, Natanael Copa <ncopa@alpinelinux.org> wrote:
> Hi,>> On Thu, 8 Feb 2018 11:23:26 -0600> William Pitcock <nenolod@dereferenced.org> wrote:>>> libressl promised to retain compatibility with 1.0.1g APIs, but has>> failed to do so. As such, there is an increasing workload to keep>> packages compatible with libressl as it evolves. Therefore, it is>> obviously not truly a suitable provider for the openssl package, and>> we should switch back to proper openssl as the default. We will>> however retain libressl for packages which require it (for example,>> ones using the new libtls APIs).>>>> If there is no objection to this proposed change, I intend to do the>> swap next week.>> I'd like to wait with the switch til we fully solved the kernel issues> in stable branches.
Well, I can do the vanilla backports this weekend, but we still need
to decide what to do with hardened. I propose we keep the hardened
kernels around in stable branches and allow people to make their own
decision about it for now. That seems to be the easiest way forward.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Fri, Feb 9, 2018 at 2:09 PM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
> On Fri, 9 Feb 2018 14:00:55 -0600>>>> Unfortunately, the Linux kernel does not have the same>> advantages of rapid iteration that the OpenBSD guys have, since>> OpenBSD has a small install base, it does not really matter if there>> are problems in the short term, since enthusiasts are the ones who use>> OpenBSD.>> Yeah, just been looking into it again, can't believe it has been 4> years. Not sure I buy that, as the major distros have much longer> cycles than OpenBSD stable 6 months. Arch, alpine etc. tend to have the> same developer type users that could cope. It would make some nasty> publicity splashes no doubt though. I guess the filesystem issues were> the real blocker. Debian, Ubuntu and more likely Redhat installs on> ext3?
Unfortunately, the Linux kernel developers have to consider the needs
of Redhat, Ubuntu, Debian, too. Yes, we could handle such a migration
in Alpine (and also in Adelie), but Redhat and Canonical obviously
like to slow things down when it comes to such major changes.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Fri, Feb 9, 2018 at 2:12 PM, Natanael Copa <ncopa@alpinelinux.org> wrote:
> On Thu, 8 Feb 2018 11:23:26 -0600> William Pitcock <nenolod@dereferenced.org> wrote:>>> libressl promised to retain compatibility with 1.0.1g APIs, but has>> failed to do so. As such, there is an increasing workload to keep>> packages compatible with libressl as it evolves. Therefore, it is>> obviously not truly a suitable provider for the openssl package, and>> we should switch back to proper openssl as the default. We will>> however retain libressl for packages which require it (for example,>> ones using the new libtls APIs).>>>> If there is no objection to this proposed change, I intend to do the>> swap next week.>> I just learned that the time_t issue is resolved:> https://github.com/libressl-portable/openbsd/commit/362ffef32c0fcae703d57838e9f5704240a63213
According to who? They just try to make the math still work with
time_t. The only way to be truly conformant is to use TAI64N math.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 02/09/18 14:15, William Pitcock wrote:
> On Fri, Feb 9, 2018 at 2:12 PM, Natanael Copa <ncopa@alpinelinux.org> wrote:>> I just learned that the time_t issue is resolved:>> https://github.com/libressl-portable/openbsd/commit/362ffef32c0fcae703d57838e9f5704240a63213> > According to who? They just try to make the math still work with> time_t. The only way to be truly conformant is to use TAI64N math.
That also doesn't help with things like Qt 5, py-cryptography <1.9,
kamailio, rust/cargo, kleopatra, ...
Also, some of the patches Alpine carries are already showing age by
bringing packages to 2.5 API. As LibreSSL's ABI continues to churn,
these patches will need to be further maintained. Some upstreams do not
care or want to deal with it, and indeed some upstreams are dead with no
good replacements yet. The maintenance burden for a project as small as
Alpine seems disproportionate to the benefits LibreSSL would bring.
But at the end of the day, I suppose it isn't my call.
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
Apologies in advance for the offtopic.
>I just want to add that I think that this is unfair. OpenBSD goes out >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
---
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=1231734https://lwn.net/Articles/625506/
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hi,
On Thu, 8 Feb 2018 11:23:26 -0600
William Pitcock <nenolod@dereferenced.org> wrote:
> libressl promised to retain compatibility with 1.0.1g APIs, but has> failed to do so. As such, there is an increasing workload to keep> packages compatible with libressl as it evolves. Therefore, it is> obviously not truly a suitable provider for the openssl package, and> we should switch back to proper openssl as the default. We will> however retain libressl for packages which require it (for example,> ones using the new libtls APIs).> > If there is no objection to this proposed change, I intend to do the> swap next week.
I'd like to wait with the switch til we fully solved the kernel issues
in stable branches.
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org> wrote:
|On Thu, 8 Feb 2018 11:23:26 -0600
|William Pitcock <nenolod@dereferenced.org> wrote:
|
|> libressl promised to retain compatibility with 1.0.1g APIs, but has
|> failed to do so. As such, there is an increasing workload to keep
|> packages compatible with libressl as it evolves. Therefore, it is
|> obviously not truly a suitable provider for the openssl package, and
|> we should switch back to proper openssl as the default. We will
|> however retain libressl for packages which require it (for example,
|> ones using the new libtls APIs).
|>
|> If there is no objection to this proposed change, I intend to do the
|> swap next week.
|
|I'd like to wait with the switch til we fully solved the kernel issues
|in stable branches.
I live in fear of updating, especially the server, i get:
00:00:13.070040 emR3Debug: rc=VERR_PGM_INVALID_CR3_ADDR
00:00:14.078859 Changing the VM state from 'RUNNING' to 'GURU_MEDITATION'.
on an old VirtualBox with -vanilla 4.14.17.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Thu, 8 Feb 2018 12:53:06 -0600
William Pitcock <nenolod@dereferenced.org> wrote:
> Hello,> > On Thu, Feb 8, 2018 at 12:05 PM, Kevin Chadwick <m8il1ists@gmail.com> wrote:> > On Thu, 8 Feb 2018 11:23:26 -0600> >> > > >> Meanwhile, the libressl guys have been removing> >> functionality we depend on, such as support for hardware accelerators> >> (ENGINE apis), switching from 64-bit TAIN date calculations to time_t> >> (because time_t is good enough on OpenBSD) and dropping openssl 1.0.1> >> APIs they see as unsuitable. > >> > This is a strange take on the situation to say the least. > > I would argue that 32-bit systems not being able to validate> certificates from CAs who have expiry dates past year 2038 is a major> security problem. This is caused by the elimination of the TAI64N> date calculation code.
The fact that libressl developers are not willing to workaround 32 bit
linux time_t is the deal breaker for me. I am not happy to switch back
to openssl. I have been fairly happy with libressl and been willing to
sacrifice pretty much work for the extra security benefits libressl has
given, but the situation we are in now is that we have to choose
between:
- replace linux kernel with some other kernel
- do not support CAs with expiry date past year 2038
- drop 32 bit support
- replace libressl
I wish libressl could keep the 32 bit time_t workaround til linux
kernel had fixed the problem instead of knowingly break things. Now I
don't see we have much of an option since 32 bit linux is basically not
supported by libressl at this point.
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Fri, 9 Feb 2018 12:28:20 -0600
> > "Sorry but you can forget running alpine on your RPI/old x86,> > but don't worry, you still have LibreSSL!" > > ...and MIPS SoCs, and routers, and AmigaOnes, and Power Mac G3/G4s,> and if RISC-V ever ships, and a lot of the phones and tablets that> postmarketOS are targeting...
I understand and I know this doesn't help now but how far away is the
Linux fix?
It is past the point where Linux needs to fix this before offline
devices are deployed that may still be running in 20 years.
Admittedly Pi HW/flash may not last that long from the irresponsible
suppliers that may develop such devices but the number will be
increasing.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Thu, 8 Feb 2018 18:05:44 +0000
Kevin Chadwick <m8il1ists@gmail.com> wrote:
> > If there is no objection to this proposed change, I intend to do the> > swap next week. > > No objection, just not impressed. Alpine could make a stand but what> difference would it make.
I would love to make a stand. What do you suggest we do? Drop support
for 32 bit linux til they have solved the 32 bit time_t issue in the
kernel?
"Sorry but you can forget running alpine on your RPI/old x86,
but don't worry, you still have LibreSSL!"
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Fri, 9 Feb 2018 14:00:55 -0600
> Unfortunately, the Linux kernel does not have the same> advantages of rapid iteration that the OpenBSD guys have, since> OpenBSD has a small install base, it does not really matter if there> are problems in the short term, since enthusiasts are the ones who use> OpenBSD.
Yeah, just been looking into it again, can't believe it has been 4
years. Not sure I buy that, as the major distros have much longer
cycles than OpenBSD stable 6 months. Arch, alpine etc. tend to have the
same developer type users that could cope. It would make some nasty
publicity splashes no doubt though. I guess the filesystem issues were
the real blocker. Debian, Ubuntu and more likely Redhat installs on
ext3?
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Thu, 8 Feb 2018 11:23:26 -0600
William Pitcock <nenolod@dereferenced.org> wrote:
> libressl promised to retain compatibility with 1.0.1g APIs, but has> failed to do so. As such, there is an increasing workload to keep> packages compatible with libressl as it evolves. Therefore, it is> obviously not truly a suitable provider for the openssl package, and> we should switch back to proper openssl as the default. We will> however retain libressl for packages which require it (for example,> ones using the new libtls APIs).> > If there is no objection to this proposed change, I intend to do the> swap next week.
I just learned that the time_t issue is resolved:
https://github.com/libressl-portable/openbsd/commit/362ffef32c0fcae703d57838e9f5704240a63213
I think we should wait with replacing libressl.
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Sat, Feb 10, 2018 at 5:36 AM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
> On Fri, 9 Feb 2018 14:15:38 -0600>>>> > I just learned that the time_t issue is resolved:>> > https://github.com/libressl-portable/openbsd/commit/362ffef32c0fcae703d57838e9f5704240a63213>>>> According to who? They just try to make the math still work with>> time_t. The only way to be truly conformant is to use TAI64N math.>>>> William>> Hi William>> Perhaps you could clarify on the openbsd misc list?>> https://marc.info/?l=openbsd-misc&m=151826186428121&w=2>> I use long long/uint64_t on my embedded development and don't build for> linux so personally I don't understand especially with
This mailing list is for the discussion of Alpine Linux, not OpenBSD.
It appears you do not use Alpine nor develop Alpine, so why exactly
are you here?
For anyone else wanting to killfile this troll, note he also posts
from a yahoo.co.uk domain.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Sat, Feb 10, 2018 at 5:17 AM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
> This is my last cross post as I am in danger or have already abused> your list likely atleast in some peoples eyes.>> It seems like a strong argument to make upstreams reconsider to me. I> know security is an intangible asset and they likely won't care.> Though I think that lesson is becoming more widely understood, so maybe.
I did not discuss the OpenSSL 1.1 API in my proposal. I do not care about it.
I care about date comparisons that don't involve trusting anything
that overflows a time_t as being in the future and then naively trying
to prove it somehow.
I care about OpenSSL 1.0.1g functions continuing to exist. OpenSSL
1.1 does include those functions, but not the OpenSSL 0.9.8 deprecated
functions.
I care about cryptographic offload support.
Most importantly, I care about not using either LibreSSL or OpenSSL in
the first damned place wherever possible.
No, the abuse you are creating has nothing to do with cross posting,
but instead posting nonsense to a mailing list about a software you
keep pointing out you do not even use, and my patience is now
exceeded. Accordingly, I have configured my mail client to
automatically delete any future messages from you.
As for Theo, I mostly agree that the new OpenSSL 1.1 APIs for
certificate verification are crap, but I don't really care to hear any
more of your bad takes, so again, my mail client will be deleting any
future mail from you.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Sat, Feb 10, 2018 at 8:01 AM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
> On Sat, 10 Feb 2018 07:40:28 -0600>>>> > https://marc.info/?l=openbsd-misc&m=151826186428121&w=2>> >>> > I use long long/uint64_t on my embedded development and don't build>> > for linux so personally I don't understand especially with>>>> This mailing list is for the discussion of Alpine Linux, not OpenBSD.>> It appears you do not use Alpine nor develop Alpine, so why exactly>> are you here?>> That link talks about TAI64N not being in the standards which you> raised as an issue for alpine?
I did not say that TAI64N is part of the TLS standard, I said that it
was a portable way to hold a date that ensures Y2038 safety.
I said that OpenSSL uses TAI64N-like date calculations to ensure Y2038
safety, which it does.
I also said that OpenBSD uses a 64-bit time_t to ensure Y2038 safety
on OpenBSD, which it does.
I also said that Alpine uses a 32-bit time_t on 32-bit systems, which
is not Y2038 safe, which it does.
Natanael pointed out a workaround that LibreSSL did, that tests the
32-bit time_t for overflow and then accepts the certificate as valid
if it did, which is still not Y2038 safe, still completely missing the
point, still dodgy, and arguably an actual security vulnerability. In
other words, it got WORSE, not BETTER.
At no time did I say that LibreSSL was unsafe on OpenBSD 32-bit, in
fact, I explicitly said "OpenBSD uses a 64-bit time_t which is good
enough."
> I was trying to help.>> I dabbled with Alpine for a few use cases and really like it. I have> respect for Natanael and recommend alpine where OpenBSD does not suit> which isn't many cases. I am also subscribed to hardened Gentoo out of> interest.>>> For anyone else wanting to killfile this troll, note he also posts>> from a yahoo.co.uk domain.>> I regret saying you may have an agenda and apologise for it looking> back if that is what you mean by trolling.
My only agenda is to make sure that programs stuck with the dumpster
fire known as OpenSSL have an implementation that works CORRECTLY and
SAFELY for the people using it on 32-bit systems. It certainly is not
to promote the use of OpenSSL, if you got that idea, you have a
serious misunderstanding on my position regarding both LibreSSL and
OpenSSL: they're both garbage, and programs should use neither.
> On reflection your original email was mainly vexing for the "proper" and as I feel I have> demonstrated (by standing on peers shoulders), largely incorrect.
You have demonstrated nothing.
Instead, you cross-post my mail, and that of several other people, out
of context, to openbsd-misc and therefore invite a bunch of people to
troll privately.
> I have no trolling intentions and have not used yahoo for many years?
If this is not about trolling, then Iran-Contra wasn't about weapons
for hostages.
Killfiled for real this time.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Sat, Feb 10, 2018 at 8:11 AM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
> On Sat, 10 Feb 2018 07:50:22 -0600>>>> I did not discuss the OpenSSL 1.1 API in my proposal. I do not care>> about it.>>>> I care about date comparisons that don't involve trusting anything>> that overflows a time_t as being in the future and then naively trying>> to prove it somehow.>>>> Wow>> What are you telling Alpine for, you should be telling them> conclusions and using evidence to back it up, not opinion. LibreSSL devs> appear to disagree about much of your justification! Have you even> asked them in the first place or yet? Perhaps you are doing it wrong?,> perhaps they have missed a Linux development?
For the n-th time, there is nothing to discuss, LibreSSL removed SAFE
date calculation code and replaced it with code that is only SAFE
under a specific precondition: 64-bit time_t. Then they made it
blindly accept ANY certificate that overflows the time_t if it's
smaller than 64-bit, which is COMPLETELY UNSAFE AND ARGUABLY A
SECURITY PROBLEM BECAUSE IT MEANS A CERT THAT EXPIRES BEFORE 1970 IS
NOW POTENTIALLY VALID. Don't believe me? Generate a certificate that
computes as 0xfffffff time_t on 32-bit and you win. Really, you do!
If they care about portability, they should revert this change.
ps: I'm only replying to this because it arrived before I added you to
my killfile. Expect no further replies from me.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hi,
On Sat, Feb 10, 2018 at 5:32 AM, Alba Pompeo <albapompeo@gmail.com> wrote:
>>switching from 64-bit TAIN date calculations to time_t> Is there a specific upstream commit that did that?> Couldn't in theory Alpine just revert the commit and keep it as local patch?> Just throwing the idea out there...>
The date calculation code change is quite invasive (many commits would
need to be reverted, for example). I would rather spend time porting
software to not use OpenSSL/LibreSSL APIs at all instead of
maintaining that patch.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Sat, Feb 10, 2018 at 3:10 AM, Consus <consus@ftml.net> wrote:
> On 12:19 Thu 08 Feb, A. Wilcox wrote:>> It isn't just this. Qt 5.10 introduces new dependency on OpenSSL 1.1>> APIs for improved security, and LibreSSL does not implement those APIs>> at all.>> Perphaps it's worth a try to notify Qt developers about the issue.
The Qt developers are vehemently opposed to LibreSSL and there are
serious hacks to the SSL code inside Qt to make it work with LibreSSL.
This vehement opposition probably has something to do with the
harassment brought on them by droves of LibreSSL-advocating trolls,
for example: http://lists.qt-project.org/pipermail/interest/2015-November/019750.html
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
>switching from 64-bit TAIN date calculations to time_t
Is there a specific upstream commit that did that?
Couldn't in theory Alpine just revert the commit and keep it as local patch?
Just throwing the idea out there...
On Sat, Feb 10, 2018 at 9:17 AM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
> This is my last cross post as I am in danger or have already abused> your list likely atleast in some peoples eyes.>> It seems like a strong argument to make upstreams reconsider to me. I> know security is an intangible asset and they likely won't care.> Though I think that lesson is becoming more widely understood, so maybe.>>> Theo posted this> ________________________________________________________________________>>> It isn't just this. Qt 5.10 introduces new dependency on OpenSSL 1.1>> APIs for improved security, and LibreSSL does not implement those APIs>> at all.>> The 1.1 API does not improve security.>> If anything, the new API requires to you repeat the same or similar> arguments to many functions, and in many ways the API is much more> fragile. Also, more memory allocation and free is required, and as a> result quite a few software upgrades to 1.1 API have had memory leaks,> as well as use-after-free and double-free bugs.>> A very large patch for converting openssh to 1.1 was provided by folk> who very much know the API, and it had several stupid and quite> dangerous mistakes of that sort.>> Don't believe all the promises you hear.>>> ---> Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org> Help: alpine-devel+help@lists.alpinelinux.org> --->
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
This is my last cross post as I am in danger or have already abused
your list likely atleast in some peoples eyes.
It seems like a strong argument to make upstreams reconsider to me. I
know security is an intangible asset and they likely won't care.
Though I think that lesson is becoming more widely understood, so maybe.
Theo posted this
________________________________________________________________________
> It isn't just this. Qt 5.10 introduces new dependency on OpenSSL 1.1> APIs for improved security, and LibreSSL does not implement those APIs> at all.
The 1.1 API does not improve security.
If anything, the new API requires to you repeat the same or similar
arguments to many functions, and in many ways the API is much more
fragile. Also, more memory allocation and free is required, and as a
result quite a few software upgrades to 1.1 API have had memory leaks,
as well as use-after-free and double-free bugs.
A very large patch for converting openssh to 1.1 was provided by folk
who very much know the API, and it had several stupid and quite
dangerous mistakes of that sort.
Don't believe all the promises you hear.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 12:19 Thu 08 Feb, A. Wilcox wrote:
> It isn't just this. Qt 5.10 introduces new dependency on OpenSSL 1.1> APIs for improved security, and LibreSSL does not implement those APIs> at all.
Perphaps it's worth a try to notify Qt developers about the issue.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 02/10/18 09:45, Kevin Chadwick wrote:
> Where would they get a 1970 cert from that was trusted?
I like how it was already pointed out, by you and possibly others, on
openbsd-misc *and* this list, that most people do not use the CA / SAN
verification routines correctly.
Then you mention that "well, invalid certs like that shouldn't be trusted".
You can't have it both ways. In an ideal world none of this would
matter anyway because we'd have better libraries with better security
and an actually competently-designed API. Or, even, in a truly ideal
world, security wouldn't be necessary because there wouldn't be bad
actors and nation states that try to commit atrocities to others.
This isn't either of those ideal worlds. We have bad code written with
bad libraries in mind that have bad security and badly designed APIs.
(I'm including OpenSSL *and* LibreSSL in that. I'd probably add GnuTLS
for its terrible DANE fallback code and mbedTLS for terrible CRL API.)
On top of that, we have standards that are ignorant, we have deficient
ABIs that still exist so some companies and governments can continue to
run binaries from the Clinton administration, we have Google running the
Web, we have world hunger....
Alpine's goals do not include "fix the world". Adélie's goals are only
very tangentially related to "fix the world". Neither of our projects
goals are "port everything to LibreSSL", and if anything, I'd expect
that to be a LibreSSL or possibly OpenBSD project goal.
"But it isn't about the number of users! It's about quality!"
I can go three ways with this:
1) Quality in a vacuum is useless. If nobody uses it, you still haven't
improved the world at all.
2) If it isn't about the number of users, why does the LibreSSL
Evangelism Strikeforce come out every time a project says they want to
use OpenSSL instead?
3) If it's about quality and not number of users, why not just make a
brand new libtls that doesn't depend on *any* OpenSSL code and try to
convince people to use that, instead of making an API promise ("we are
1.0.1g compliant! honest!") you never actually intended to keep?
> I cross posted because reluctance to communicate> between Linux and OpenBSD devs is well known. OpenBSD devs are blunt> but they don't have time to be anything else.
Bluntness is not a problem for me. (Consider this message.) In fact,
bluntness is good, because it means there is no fluffy text to sift
through, just technical discussion.
The problem with the OpenBSD community is not bluntness. Arrogance and
trolling are problems for me. And you know what? Honestly, I don't
find too many OpenBSD devs have that problem. Their users, however...
their users...
Farewell,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
On Sat, 10 Feb 2018 07:40:28 -0600
> > https://marc.info/?l=openbsd-misc&m=151826186428121&w=2> >> > I use long long/uint64_t on my embedded development and don't build> > for linux so personally I don't understand especially with > > This mailing list is for the discussion of Alpine Linux, not OpenBSD.> It appears you do not use Alpine nor develop Alpine, so why exactly> are you here?
That link talks about TAI64N not being in the standards which you
raised as an issue for alpine?
I was trying to help.
I dabbled with Alpine for a few use cases and really like it. I have
respect for Natanael and recommend alpine where OpenBSD does not suit
which isn't many cases. I am also subscribed to hardened Gentoo out of
interest.
> For anyone else wanting to killfile this troll, note he also posts> from a yahoo.co.uk domain.
I regret saying you may have an agenda and apologise for it looking
back if that is what you mean by trolling. On reflection your original
email was mainly vexing for the "proper" and as I feel I have
demonstrated (by standing on peers shoulders), largely incorrect.
I have no trolling intentions and have not used yahoo for many years?
It fell apart after they sold out to Microsoft.
Goodbye
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Sat, 10 Feb 2018 07:50:22 -0600
> I did not discuss the OpenSSL 1.1 API in my proposal. I do not care> about it.> > I care about date comparisons that don't involve trusting anything> that overflows a time_t as being in the future and then naively trying> to prove it somehow.>
Wow
What are you telling Alpine for, you should be telling them
conclusions and using evidence to back it up, not opinion. LibreSSL devs
appear to disagree about much of your justification! Have you even
asked them in the first place or yet? Perhaps you are doing it wrong?,
perhaps they have missed a Linux development?
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Sat, 10 Feb 2018 08:31:26 -0600
> For the n-th time, there is nothing to discuss, LibreSSL removed SAFE> date calculation code and replaced it with code that is only SAFE> under a specific precondition: 64-bit time_t. Then they made it> blindly accept ANY certificate that overflows the time_t if it's> smaller than 64-bit, which is COMPLETELY UNSAFE AND ARGUABLY A> SECURITY PROBLEM BECAUSE IT MEANS A CERT THAT EXPIRES BEFORE 1970 IS> NOW POTENTIALLY VALID. Don't believe me? Generate a certificate that> computes as 0xfffffff time_t on 32-bit and you win. Really, you do!> If they care about portability, they should revert this change.
Yet there is no mention of TAI64N or this as far as I can see on the
libressl mailing list. I cross posted because reluctance to communicate
between Linux and OpenBSD devs is well known. OpenBSD devs are blunt
but they don't have time to be anything else.
I guess that issue PRE 1970 issue would not apply to OpenSSH but you
would probably find that your argument about a CERT expiring before
1970 has been considered and found to be a red herring or they would
help you but no YOU HAVEN'T EVEN DISCUSSED YOUR PROBLEM.
Where would they get a 1970 cert from that was trusted?
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
William Pitcock <nenolod@dereferenced.org> wrote:
|On Fri, Feb 9, 2018 at 11:59 AM, Steffen Nurpmeso <steffen@sdaoden.eu> \
|wrote:
|> Natanael Copa <ncopa@alpinelinux.org> wrote:
|>|On Thu, 8 Feb 2018 11:23:26 -0600
|>|William Pitcock <nenolod@dereferenced.org> wrote:
...
|>|I'd like to wait with the switch til we fully solved the kernel issues
|>|in stable branches.
|>
|> I live in fear of updating, especially the server, i get:
|>
|> 00:00:13.070040 emR3Debug: rc=VERR_PGM_INVALID_CR3_ADDR
|> 00:00:14.078859 Changing the VM state from 'RUNNING' to 'GURU_MEDITATION\
|> '.
|>
|> on an old VirtualBox with -vanilla 4.14.17.
|
|Out of curiosity, do you get that with KPTI disabled? Boot with nopti
|command-line option.
With nopti 4.14.18-vanilla boots and seems to work.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Sat, Feb 10, 2018 at 9:45 AM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
> On Sat, 10 Feb 2018 08:31:26 -0600>>>> For the n-th time, there is nothing to discuss, LibreSSL removed SAFE>> date calculation code and replaced it with code that is only SAFE>> under a specific precondition: 64-bit time_t. Then they made it>> blindly accept ANY certificate that overflows the time_t if it's>> smaller than 64-bit, which is COMPLETELY UNSAFE AND ARGUABLY A>> SECURITY PROBLEM BECAUSE IT MEANS A CERT THAT EXPIRES BEFORE 1970 IS>> NOW POTENTIALLY VALID. Don't believe me? Generate a certificate that>> computes as 0xfffffff time_t on 32-bit and you win. Really, you do!>> If they care about portability, they should revert this change.>> Yet there is no mention of TAI64N or this as far as I can see on the> libressl mailing list. I cross posted because reluctance to communicate> between Linux and OpenBSD devs is well known. OpenBSD devs are blunt> but they don't have time to be anything else.>> I guess that issue PRE 1970 issue would not apply to OpenSSH but you> would probably find that your argument about a CERT expiring before> 1970 has been considered and found to be a red herring or they would> help you but no YOU HAVEN'T EVEN DISCUSSED YOUR PROBLEM.
I described very clearly the problem: a certificate whose date
evaluates as 32-bit 0xffffffff due to overflow will be considered
valid, regardless of whether or not it is in the past or future.
> Where would they get a 1970 cert from that was trusted?
Who are "they"? It is trivial to generate the appropriate ASN.1
structure. Will an actual CA sign it? Probably not, but your local
sysadmin's CA might, since he doesn't care to look at what he is
signing. Point is, it's replacing coding that worked safely in all
circumstances with code that does not, which is the point. Code which
fails under certain preconditions is a security problem when it is
security code.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Sat, Feb 10, 2018 at 1:06 PM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
> On Sat, 10 Feb 2018 12:16:18 -0600>>>> I like how it was already pointed out, by you and possibly others, on>> openbsd-misc *and* this list, that most people do not use the CA / SAN>> verification routines correctly.>>>> Wasn't me!
It was in the form of your advocacy to use libtls instead. Nobody
disagrees with using libtls instead if it is appropriate for your
code.
>> Then you mention that "well, invalid certs like that shouldn't be>> trusted".>> You missed the point entirely, he didn't ask the question.>> From the commit message I'm inclined to think it clamps the year for> good or bad but I was just pointing out his argument was potentially> obviously flawed.>> OpenSSL only started in 1998! and any trusted CA that issues a pre 1970> cert is broken anyway. That was his assertion of it working that> way and being insecure.
This is not about trusted CAs, it's about insufficient code safety.
Obviously no "trusted CA" (whatever that means) will sign a
certificate that expired prior to 1970.[1] Unless they are using
LibreSSL on a 32-bit system, in which case, they will believe it
expires after 2038.
> The point wasn't that I knew but that he hadn't given LibreSSL the> chance despite it's merits over OpenSSL. I assure you that LibreSSL> devs know a lot more than us about LibreSSL. Not raising issue with> them is arrogance.
I was the one who pushed for LibreSSL adoption in the first place,
despite the lack of ENGINE support, despite it being proven in the
field. So clearly I have given LibreSSL the chance and considered
it's merits over OpenSSL.
You assume that an issue has not been raised either, the 32-bit
problem caused by their date code removal was raised here:
https://github.com/libressl-portable/portable/issues/207#issuecomment-232543488
Quoting Bob Beck in that thread:
=====
> Does your platform only have a 32 bit time_t? In this case this is working> as intended.>> Your platform is unable to deal with time_t after Y2038 - and so dealing> with certificates after such a date is dangerous. LibreSSL defensively> fails if time_t can not represent these times. So the safe thing is to> actually fail.>> You need to actually fix this at the operating system level.
=====
Which is a fine and correct position to take, but it means LibreSSL
cannot be used on 32-bit Linux systems because certificate chain
validation will fail.
Then they changed it later to use the clamp mechanism which makes it
accept any time_t overflow as valid, which is a completely unsafe hack
done for RFC 5280 conformance on 32-bit systems. As it stands, I am
inclined to revert that hack in our libressl packages because it is
worse than simply failing to validate: it means somebody can make a
fake CA root certificate and gets some bytes to play with since your
system won't correctly validate it when you install it by mistake.
What you do instead is what OpenSSL did: you convert the system time
into a format that is Y2038 safe and you do your validity checks in
that format. TAI64N being a safe format for this, for example.[2]
> But yes, I use public key crypto not CA certificates for anything I> implement, except a website where I hope letsencrypt start doing> things properly and less traditionally.>> I actually don't care one bit aside from dev time wasted for a> worse outcome. I simply saw a wrong>>> The problem with the OpenBSD community is not bluntness. Arrogance>> and trolling are problems for me. And you know what? Honestly, I>> don't find too many OpenBSD devs have that problem. Their users,>> however...their users....>> Atleast you did enter some discussion and William might have learnt> that passing imsgs can be more secure and protect the keys!
I have been isolating TLS code for over a decade. I did not learn
anything from you, other than that you're an arrogant prat.
Do not post here again.
William
[1]: Actually, this is debatable. I am pretty sure Symantec could be
tricked into doing it, for example.
[2]: Technically, OpenSSL converts ASN1 GMTTIME and GENERALIZEDTIME
into a structure that is functionally equivalent to TAI64N. By
conformant, I mean that it can safely handle >Y2038 dates; the
clamping method is not conformant. Eventually, somebody is going to
die because an intelligence agency managed to trick LibreSSL into
accepting a certificate it shouldn't have because of this code. When
looking at cryptographic code, I suggest always asking the question
"who will die when I screw this up?"
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Sat, 10 Feb 2018 12:16:18 -0600
> I like how it was already pointed out, by you and possibly others, on> openbsd-misc *and* this list, that most people do not use the CA / SAN> verification routines correctly.>
Wasn't me!
> Then you mention that "well, invalid certs like that shouldn't be> trusted".
You missed the point entirely, he didn't ask the question.
From the commit message I'm inclined to think it clamps the year for
good or bad but I was just pointing out his argument was potentially
obviously flawed.
OpenSSL only started in 1998! and any trusted CA that issues a pre 1970
cert is broken anyway. That was his assertion of it working that
way and being insecure.
The point wasn't that I knew but that he hadn't given LibreSSL the
chance despite it's merits over OpenSSL. I assure you that LibreSSL
devs know a lot more than us about LibreSSL. Not raising issue with
them is arrogance.
But yes, I use public key crypto not CA certificates for anything I
implement, except a website where I hope letsencrypt start doing
things properly and less traditionally.
I actually don't care one bit aside from dev time wasted for a
worse outcome. I simply saw a wrong
> The problem with the OpenBSD community is not bluntness. Arrogance> and trolling are problems for me. And you know what? Honestly, I> don't find too many OpenBSD devs have that problem. Their users,> however...their users....
Atleast you did enter some discussion and William might have learnt
that passing imsgs can be more secure and protect the keys!
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Sat, 10 Feb 2018 19:04:04 -0600
> > Then they changed it later to use the clamp mechanism which makes it> accept any time_t overflow as valid, which is a completely unsafe hack> done for RFC 5280 conformance on 32-bit systems. As it stands, I am> inclined to revert that hack in our libressl packages because it is> worse than simply failing to validate: it means somebody can make a> fake CA root certificate and gets some bytes to play with since your> system won't correctly validate it when you install it by mistake.> > What you do instead is what OpenSSL did: you convert the system time> into a format that is Y2038 safe and you do your validity checks in> that format. TAI64N being a safe format for this, for example.[2]>
Why would you revert it before raising it with them. I haven't the time
to write this mail or follow the code properly and didn't even find goto
out, but it appears it may still fail for completely broken systems. IF
there is a practical security issue then you have a DUTY to raise it no
matter how few systems it affects!
Perhaps it is only done for RFC compliance and this corner case is
deemed as too much work where Linux should be doing things right but
atleast you tried to upstream it. Perhaps these systems are seen as
being dangeorous to deploy in any case for any important task and so
supporting it is the wrong thing (aiding deployers) as their software
could do unpredictable things with a broken OS. It would be better to
know!
> >> > Atleast you did enter some discussion and William might have learnt> > that passing imsgs can be more secure and protect the keys! > > I have been isolating TLS code for over a decade. I did not learn> anything from you, other than that you're an arrogant prat.>
I guess you missed the point
>> Alpine has been using privilege separation for years where possible>> regardless of using LibreSSL or not. Privilege separation would not>> have prevented Heartbleed, as the unprivileged process would still>> require a copy of the X509 objects in order to perform cryptographic>> operations. > Cool, glad to hear it. My faith in Alpine is restored somewhat :)> That depends on the design which is also why I said compilation> wouldn't cut it.> http://insanecoding.blogspot.co.uk/2014/05/protecting-private-keys.html> https://marc.info/?l=openbsd-cvs&m=139879883203226&w=2
The Imsgs used here are not passing keys or sensitive x509 objects!
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
With systemd amongst other things I have abandoned Linux wherever
I can afford to (including lists) (Alpine still has consideration).
May I appeal to you guys to lobby on any Linux mailing lists to urge
the kernel devs (perhaps after spectre is sorted) to sort the y2038
problem.
Upgrade failures are a non issue and far more manageable in comparison
to unpredictable system behaviour.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 11:23 Thu 08 Feb, William Pitcock wrote:
> Hello,> > To start off, I would like to say that when we first switched to> libressl, it was largely as a reaction to what we perceived as bad> maintenance being done in openssl. At the time, it was a perfectly> reasonable and valid reaction.> > There were other reasons to care, too: the libressl guys were working> to relicense as much of libressl as possible under ISC license.> > But openssl 1.1 has a different situation: Akamai and the Core> Infrastructure Initiative have come together to sponsor development> and maintenance of openssl since we switched, which means that there's> higher quality maintenance occuring now. They are also working on a> relicensing process, much like the libressl guys are doing, which has> a larger scope[1]. Meanwhile, the libressl guys have been removing> functionality we depend on, such as support for hardware accelerators> (ENGINE apis), switching from 64-bit TAIN date calculations to time_t> (because time_t is good enough on OpenBSD) and dropping openssl 1.0.1> APIs they see as unsuitable.> > libressl promised to retain compatibility with 1.0.1g APIs, but has> failed to do so. As such, there is an increasing workload to keep> packages compatible with libressl as it evolves. Therefore, it is> obviously not truly a suitable provider for the openssl package, and> we should switch back to proper openssl as the default. We will> however retain libressl for packages which require it (for example,> ones using the new libtls APIs).> > If there is no objection to this proposed change, I intend to do the> swap next week.
Seems like LibreSSL team is starting to support OpenSSL 1.1 API:
commit 3a94b192e7c26a9092dae24d992de50398beaa1a
Author: jsing <jsing@openbsd.org>
Date: Wed Feb 14 16:32:06 2018 +0000
Start providing parts of the OpenSSL 1.1 API.
This will ease the burden on ports and others trying to make software
work with LibreSSL, while avoiding #ifdef mazes. Note that we are not
removing 1.0.1 API or making things opaque, hence software written to
use the older APIs will continue to work, as will software written to
use the 1.1 API (as more functionality become available).
Discussed at length with deraadt@ and others.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---