Re: [Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

2018-03-04 Thread Steffan Karger 

On 04-03-18 23:23, Jeremie Courreges-Anglas wrote:
> On Sun, Mar 04 2018, Selva Nair  wrote:
>> Libressl developers break API compatibility with openssl in such
>> perverse ways that there are no easy ways to support it. Take, for
>> example, the patch I just sent out which checks for certain functions
>> instead of disabling using LIBRESSL_VERSION_NUMBER. It finds two "set"
>> functions defined in libressl but two related "get" ones are not
>> found. So the compat layer will get used for those. But there is no
>> guarantee that such mixed usage leads to logically correct code. In
>> fact, the compat layer functions for min/max proto-version are not the
>> same as those in openssl 1.1. Those are a work around meant for
>> cleanly handling multiple versions of openssl without using ifdefs all
>> over the code. If libressl has implemented those set functions as in
>> openssl 1.1, then those get functions from compat layer would not be
>> what you should be using, but that's what you will get.
> 
> I'd like to add more details here.
> 
> At the time LibreSSL added the setters (May 2017)[1], OpenSSL itself
> only provided said setters (since 2015)[2].  The getters were added to
> OpenSSL later (Sep 2017)[3].
> 
> [1] 
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/ssl.h.diff?r1=1.127=1.128
> [2] 
> https://github.com/openssl/openssl/commit/7946ab33cecce60afcc00afc8fc18f31f9e66bff
> [3] 
> https://github.com/openssl/openssl/commit/3edabd3ccb7aac89af5a63cfb2378e33a8be05d7
> 
> So I don't think the current situation can be summed up as a plain
> oversight or bad design choice.

Which is exactly why using OPENSSL_VERSION to determine the available
API would be so much cleaner.  No horribly slow configure checks and
easier to maintain code.

LibreSSL made the design choice to deviate from the OpenSSL API and put
lies into OPENSSL_VERSION, and then expects products that support
openssl to deal with the mess.  Yes, I think that's a bad design choice.
 But that's not the point - I guess every project makes bad choices
every now and then.  As soon as our official support warning is merged,
I'm fine with continuing the current practice of accepting patches to
keep LibreSSL working as long as they don't pollute the code.  If
LibreSSL is moving towards implementing the parts of the OpenSSL 1.1 API
we need, that hopefully will be just a few small patches.

If they then also set their OPENSSL_VERSION to match the API version
they are trying to support, I'd not have much left to complain about ;-)

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

2018-03-04 Thread Steffan Karger 
Hi,

Most has been said, so I won't reiterate that.  Gert++, Selva++.

On 04-03-18 13:43, Mina Barret via Openvpn-devel wrote:
> Ok, bummer, the (german) wikipedia experience again - rejected. The
> second and third read of the well distributed Changelog(s) and release
> note(s) does not bring up a 'We do no longer support LibreSSL' note. The
> sourcecode contains ifdefs that already take care about LibreSSL.

Exactly this is the reason why I've been reluctant to accept LibreSSL
patches in the past.  It might give people the idea that we ever
supported it.  We never claimed to support LibreSSL.  Even more, we've
broadcasted more than once [0,1,2] that we do *not* support libressl.

But I can't really blame you for assuming we did.  We can't expect
everyone to follow the mailing list.  In hindsight, we should have
immediately added a patch like I recently submitted, to leave no doubt
about the state of our LibreSSL support.  (Though I'd also like to
defend ourselves a bit, LibreSSL lured us into this mess by pretending
to be OpenSSL-compatible.)

> Steffan Karger: When the introduced block
> in 0e8a30c0b05c1e2b59a1dea0a6eab5daa1d9d9a1 really is 'not really
> needed', can we add a additional ifdef arround it to make it build
> with libressl?

This block is needed if the linked crypto lib does not support the API
we expect, namely the OpenSSL 1.1 API.  If LibreSSL claims to implement
the OpenSSL API, they should do so.  I don't have time to figure out how
they subtly broke the build this week.  (Yes, I think OpenSSL's choice
to use macro's is bad design.  But that is the API we do support.)

-Steffan

[0]
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg09221.html

[1]
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg11272.html

[2]
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15295.html

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

2018-03-04 Thread Jeremie Courreges-Anglas 
On Sun, Mar 04 2018, Selva Nair  wrote:

[...]

> Libressl developers break API compatibility with openssl in such
> perverse ways that there are no easy ways to support it. Take, for
> example, the patch I just sent out which checks for certain functions
> instead of disabling using LIBRESSL_VERSION_NUMBER. It finds two "set"
> functions defined in libressl but two related "get" ones are not
> found. So the compat layer will get used for those. But there is no
> guarantee that such mixed usage leads to logically correct code. In
> fact, the compat layer functions for min/max proto-version are not the
> same as those in openssl 1.1. Those are a work around meant for
> cleanly handling multiple versions of openssl without using ifdefs all
> over the code. If libressl has implemented those set functions as in
> openssl 1.1, then those get functions from compat layer would not be
> what you should be using, but that's what you will get.

I'd like to add more details here.

At the time LibreSSL added the setters (May 2017)[1], OpenSSL itself
only provided said setters (since 2015)[2].  The getters were added to
OpenSSL later (Sep 2017)[3].

[1] 
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/ssl.h.diff?r1=1.127=1.128
[2] 
https://github.com/openssl/openssl/commit/7946ab33cecce60afcc00afc8fc18f31f9e66bff
[3] 
https://github.com/openssl/openssl/commit/3edabd3ccb7aac89af5a63cfb2378e33a8be05d7

So I don't think the current situation can be summed up as a plain
oversight or bad design choice.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE


signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

2018-03-04 Thread Selva Nair 
Hi,

On Sun, Mar 4, 2018 at 11:47 AM, Jeremie Courreges-Anglas
 wrote:
> On Sun, Mar 04 2018, Gert Doering  wrote:
>
> [...]
>
>> "Please note that LibreSSL is not a supported crypto backend. We
>>  accept patches and we do test on OpenBSD 6.0 which comes with
>>  LibreSSL, but if newer versions of LibreSSL break API compatibility
>>  we do not take responsibility to fix that."
>>
>>
>> I think a patch adding these LIBRESSL_VERSION checks has a reasonable
>> chance of being ACKed and merged :-) - but LibreSSL support stuff has
>> to come from some who cares, so Steffan or Antonio are not going to
>> go out and check patches for "will it break LibreSSL?"...
>
> I don't think adding "&& !defined(LIBRESSL_VERSION_NUMBER)" in more
> places would be a good idea.  Those checks would do more harm than good
> in the long run, preventing the use of new interfaces when they get
> implemented by LibreSSL.  Better use function availability checks IMHO.

Libressl developers break API compatibility with openssl in such
perverse ways that there are no easy ways to support it. Take, for
example, the patch I just sent out which checks for certain functions
instead of disabling using LIBRESSL_VERSION_NUMBER. It finds two "set"
functions defined in libressl but two related "get" ones are not
found. So the compat layer will get used for those. But there is no
guarantee that such mixed usage leads to logically correct code. In
fact, the compat layer functions for min/max proto-version are not the
same as those in openssl 1.1. Those are a work around meant for
cleanly handling multiple versions of openssl without using ifdefs all
over the code. If libressl has implemented those set functions as in
openssl 1.1, then those get functions from compat layer would not be
what you should be using, but that's what you will get.

So IMO, it may be more worthwhile for those invested in libressl to
convince the developers to make more sane decisions. Either they want
libressl to be a better openssl or a different crypto library. They
can't behave as neither and both at the same time and expect
users/developers to work around their personal opinions of what
openssl should be.

Selva

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

2018-03-04 Thread Jeremie Courreges-Anglas 
On Sun, Mar 04 2018, Gert Doering  wrote:

[...]

> "Please note that LibreSSL is not a supported crypto backend. We
>  accept patches and we do test on OpenBSD 6.0 which comes with
>  LibreSSL, but if newer versions of LibreSSL break API compatibility
>  we do not take responsibility to fix that."
>
>
> I think a patch adding these LIBRESSL_VERSION checks has a reasonable
> chance of being ACKed and merged :-) - but LibreSSL support stuff has
> to come from some who cares, so Steffan or Antonio are not going to
> go out and check patches for "will it break LibreSSL?"...

I don't think adding "&& !defined(LIBRESSL_VERSION_NUMBER)" in more
places would be a good idea.  Those checks would do more harm than good
in the long run, preventing the use of new interfaces when they get
implemented by LibreSSL.  Better use function availability checks IMHO.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE


signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

2018-03-04 Thread Gert Doering 
Hi,

On Sun, Mar 04, 2018 at 07:43:14AM -0500, Mina Barret via Openvpn-devel wrote:
> The release last week was different than the releases before.
> Usually all i have to do is updating the version, rebuild and QA.
> The release notes state 'This is primarily a maintenance release,
> with further improved OpenSSL 1.1'. To my surprise the build-openvpn
> repository now uses the OpenSSL 1.1 dependency, but why should
> OpenSSL 1.0 no longer work right?

1.0 should work fine - most of the buildbots are on some version of 
openssl 1.0.x.  Windows builds were changed to 1.1 to get access to
the latest and greatest features (TLS 1.2 with cryptoapi, I think?)

It seems we broke 0.9.8 compilation by missing two #ifdef - this is an
issue we need to fix - our current buildbot farm uses the same settings 
for 2.4 and "master" testing, so pointing to an openssl version that is
no longer supported for "master" (to get the 2.4 testing) will break 
things.  Dedicated test setups for "2.4 with 0.9.8" are needed.


Which 1.0 version did we break?  1.0.0, 1.0.1 and 1.0.2 are quite 
different from what I can read in our commit logs - maybe it's the same
issue that broke 0.9.8 that also broke 1.0.0 (both are EOLed, but 
our goal is to never intentionally break a working dependency in the
middle of a release train).

> It does not, and this is fine as it's reaching EOL soon anyway.
> And maybe it is not breaking the OpenVPN API so its ok to increase
> only the last version digit. This adds more patch to my openvpn-build
> repository as now the 2.3.18 version _needs_ openssl 1.0 and cannot
> use 1.1 while 2.4.5 needs openssl 1.1 and does no longer build with
> 1.0 - but thats my problem i guess.

As I said, the aim was to have 2.4.5 build with the same libraries (exact
versions) that 2.4.4 worked with.   So 1.0. should be fine, but
there's large differences in the  here...

If we broke something that we say we support, please let us know which 
versions, and whether the already committed patch for 2.4 for older 
openssl versions (88abb911ea22a30) already fixes your problems as well.


> After the OpenSSL switch worked with 2.3.18 and 2.4.5, LibreSSL
> had one compile error - not what i experienced in the last years
> but ok, I can patch, and i have a system for patches anyway (eg for
> xor). To save other people the trouble - as long as they build the
> unmodified source - I'd like to contribute to your project with a
> simple pull request, one that makes the latest OpenVPN version work
> with the latest LibreSSL. Maybe you just do not build it this way,
> but soon others may run into this. In the end its not more than a
> typo/broken link on wikipedia.

This particular LibreSSL breakage is even more annoying than "normal" - 
we do test on OpenBSD 6.0 with the LibreSSL version on that system, and
it seems a *newer* LibreSSL version added API functions that they did
not have previously, adding them as a function where OpenSSL uses 
a macro.  This sort of API differences (while still defining an 
OPENSSL_VERSION that claims "of course we have all the cool stuff!")
is what annoys our crypto developers enough that they considered to
drop LibreSSL support completely... 

Since we do want OpenBSD support, we compromised on "we're not going
to intentionally break it, but if *they* break it, we're not going to
chase their changes to see what we have to do now".


[..]
> Ok, bummer, the (german) wikipedia experience again - rejected.
> The second and third read of the well distributed Changelog(s) and
> release note(s) does not bring up a 'We do no longer support LibreSSL'
> note. The sourcecode contains ifdefs that already take care about
> LibreSSL. There are recent patches that handle mbedSSL, so you must
> be interested in supporting other crypto libraries. Do i really
> have to write a email to the developer that made the last LibreSSL
> patch, bribe her or him with *hugs* or *backrubs* (sorry!) to get
> the simplest possible patch into upstream? What do i have to do
> then to get more complex stuff approved? Weekly meetings?

Well, first of all, the fact that we do not accept PRs is very well
documented *in* the PR form.  Github does not let us turn off PRs
completely, otherwise we'd have done that long ago - but we put
documentation in there to state this quite clearly.

Github is not our primary working platform.  We push there, to have
resiliency (and to sf.net and to gitlab) but our workflow is "incoming
mail with patches goes to the list, it gets reviewed, ACKed on the list 
[= archived], then merged".

The ChangeLog I was referring to can be found here:

https://openvpn.net/index.php/open-source/downloads.html

"Please note that LibreSSL is not a supported crypto backend. We
 accept patches and we do test on OpenBSD 6.0 which comes with
 LibreSSL, but if newer versions of LibreSSL break API compatibility
 we do not take responsibility to fix that."


I think a patch adding these LIBRESSL_VERSION checks has a reasonable

[Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

2018-03-04 Thread Mina Barret via Openvpn-devel 
Hallo OpenVPN developers,

The last years i closely follow your advances in the source. When you release a 
new version of the software, i will pull it, build it in different 
configurations and ship it to a small userbase.
To allow the users to choose the flavor of SSL, one of the configurations is 
'-libressl' and the other is '-openssl'. Personally i do not care, as they 
should do the same thing - encrypt and decrypt byte arrays with advanced 
mathematics - but there are situations and preferences where having a different 
library can be handy.

In order to have the builds reproducible, i maintain a private fork of 
openvpn/openvpn-build that adds support for libressl (and pulls all 
dependencies with https and always uses the very latest openssl 1.0 
patchlevel). This repository is used to build the openvpn executables for 
archlinux, debian, fedora, ubuntu, osx and windows in appropriate VM's.

The release last week was different than the releases before. Usually all i 
have to do is updating the version, rebuild and QA. The release notes state 
'This is primarily a maintenance release, with further improved OpenSSL 1.1'. 
To my surprise the build-openvpn repository now uses the OpenSSL 1.1 
dependency, but why should OpenSSL 1.0 no longer work right?

It does not, and this is fine as it's reaching EOL soon anyway. And maybe it is 
not breaking the OpenVPN API so its ok to increase only the last version digit. 
This adds more patch to my openvpn-build repository as now the 2.3.18 version 
_needs_ openssl 1.0 and cannot use 1.1 while 2.4.5 needs openssl 1.1 and does 
no longer build with 1.0 - but thats my problem i guess.

After the OpenSSL switch worked with 2.3.18 and 2.4.5, LibreSSL had one compile 
error - not what i experienced in the last years but ok, I can patch, and i 
have a system for patches anyway (eg for xor). To save other people the trouble 
- as long as they build the unmodified source - I'd like to contribute to your 
project with a simple pull request, one that makes the latest OpenVPN version 
work with the latest LibreSSL. Maybe you just do not build it this way, but 
soon others may run into this. In the end its not more than a typo/broken link 
on wikipedia.
I research other patches that 'fix LibreSSL' (not many) to make the change as 
close as possible to your accepted standards.
I research the patch that causes the build error and evaluate if my change may 
have any drawbacks.
I setup a GH identity to fork, apply the patch, push and create a Pull request, 
just to learn, that this is not the 'right' way.

Then i get the response "See the release notes for 2.4.5." and "if LibreSSL is 
then breaking the API
again, the active developers very much do not care."

Ok, bummer, the (german) wikipedia experience again - rejected. The second and 
third read of the well distributed Changelog(s) and release note(s) does not 
bring up a 'We do no longer support LibreSSL' note. The sourcecode contains 
ifdefs that already take care about LibreSSL. There are recent patches that 
handle mbedSSL, so you must be interested in supporting other crypto libraries. 
Do i really have to write a email to the developer that made the last LibreSSL 
patch, bribe her or him with *hugs* or *backrubs* (sorry!) to get the simplest 
possible patch into upstream? What do i have to do then to get more complex 
stuff approved? Weekly meetings?

Last try with the mailinglist, maybe someone copies the lines into the next 
release so i can drop the patch, I do not want attribution, I do not want to 
write emotional messages on a mailing list, nor do i want to have responses to 
them. I want to interact technically using a pull request for a issue i see.

Gert Doering: thanks for the quick response on GH
Steffan Karger: When the introduced block in 
0e8a30c0b05c1e2b59a1dea0a6eab5daa1d9d9a1 really is 'not really needed', can we 
add a additional ifdef arround it to make it build with libressl?

Everyone reading: Sorry for the rant, thank you for the latest release and the 
great work and have a nice sunday!

https://github.com/OpenVPN/openvpn/pull/102--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel