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.<x> should be fine, but there's large differences in the <x> 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 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?"... gert -- now what should I write here... Gert Doering - Munich, Germany g...@greenie.muc.de
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
