upgrade to openssl 3.0.0

Sat Nov 6 17:17:59 UTC 2021

Well thanks, Rene!  

I’m so glad to see this is actually happening now, after a momentary delay.

I think my comment about enabling the openssl3 FIPS mode was somehow missed; it has to be specifically turned on in openssl3, but it does allow more things to work with openssl3 I believe.

Ken

> On Nov 6, 2021, at 6:34 AM, Renee Otten <ottenr.work at gmail.com> wrote:
> 
> Dear all, 
> 
> 
> Chris has done the work to add the openssl3 port and openssl-1.0 PortGroup to ease the transition towards openssl v3. There is now an open PR (https://github.com/macports/macports-ports/pull/12807 <https://github.com/macports/macports-ports/pull/12807>) to switch en masse  the default openssl version to 3. The Apache-2 license of openssl3 will allow many ports that are currently not, to become distributable as there will be no license conflict anymore.
> 
> If maintainers want to pro-actively test whether “their” ports build properly with the latest openssl version please do so now. If that doesn’t work out-of-the-box then the status quo (i.e., building with openssl v1.1) can easily be restored by the adding the following code to the Portfile:
> 
> PortGroup openssl 1.0
> openssl.branch    1.1
> 
> and depending on the build-system one can also specify “openssl.configure” which takes the options: 'pkgconfig' (default), 'build_flags', or 'cmake’. 
> 
> For other options, please refer to the PortGroup code: https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/openssl-1.0.tcl <https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/openssl-1.0.tcl>. 
> 
> Given the number of maintainers and ports involved we should probably leave the above mentioned PR open for a bit more than the usual 72 hours, but I’d imagine that in about a week or so from now someone will re-run the script to revbump affected ports and push the merge button. Ideally most of the ports will just work with openssl3, whereas others might have been set to build with openssl1 by their maintainers by then. Yes, there will for sure be some breakage of unmaintained ports that will need fixing, but that will need to happen at some point anyway so we can as well just flip the switch soon and deal with it.
> 
> 
> 
> 
>> On Oct 7, 2021, at 12:16 PM, Christopher Jones <jonesc at hep.phy.cam.ac.uk <mailto:jonesc at hep.phy.cam.ac.uk>> wrote:
>> 
>> 
>> https://github.com/macports/macports-ports/pull/12514 <https://github.com/macports/macports-ports/pull/12514>
>> 
>> 
>>> On 6 Oct 2021, at 5:46 pm, Christopher Jones <jonesc at hep.phy.cam.ac.uk <mailto:jonesc at hep.phy.cam.ac.uk>> wrote:
>>> 
>>> I’m working on the basic changes to implement my suggestion at the moment. Once that is there testing specific ports against version 3 ’the canaries’ will be trivial. more in a bit.
>>> 
>>>> On 6 Oct 2021, at 5:40 pm, Ken Cunningham <ken.cunningham.webuse at gmail.com <mailto:ken.cunningham.webuse at gmail.com>> wrote:
>>>> 
>>>> For whoever gets up the enthusiasm to take on the storm of nay-sayers:
>>>> 
>>>> Although I found about 90% of the 100 or so ports I tried built without any changes against openssl 3.0.0 (rust, cargo, qt5, qt4-mac, etc, etc), and the rest were easy < 5 min fixes to use our openssl11 port, I noted in the openssl 3 migration guide that the FIPS mode is disabled by default on the openssl 3 build, and has to be expressly enabled.
>>>> 
>>>> I recall that most of the (very few) build failures I saw were in fact FIPS failures, so enabling that module might fix a bunch of them.
>>>> 
>>>> Best,
>>>> 
>>>> Ken
>>>> 
>>>> 
>>>> On Tue, Oct 5, 2021 at 12:54 PM Fred Wright <fw at fwright.net <mailto:fw at fwright.net>> wrote:
>>>> 
>>>> On Mon, 4 Oct 2021, Christopher Jones wrote:
>>>> >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham <ken.cunningham.webuse at gmail.com <mailto:ken.cunningham.webuse at gmail.com>> wrote:
>>>> >>
>>>> >> I was hoping to move this along for the overwhelming benefit of the 
>>>> >> license, but TBH the push-back so far is 99.99% negative about moving 
>>>> >> to openssl 3.0.0 this year, so too controversial for me to get involved 
>>>> >> with. I'll sit back for six to twelve months and see what you guys work 
>>>> >> out over the coming year.
>>>> >
>>>> > All the more reason to follow my suggested migration path then I would 
>>>> > say, as it allows an openssl30 port to be made available, and those 
>>>> > ports that wish to can use it via the new PG, but it doesn’t have to 
>>>> > become the default until some later date.
>>>> 
>>>> The PR thread contained (approximately) the following two statements:
>>>> 
>>>> 1) Unless v3 is the default, nobody will bother to use it.
>>>> 
>>>> 2) Everybody is really, *really* anxious to move to v3 for the more 
>>>> permissive license.
>>>> 
>>>> Clearly those two statements are in conflict.
>>>> 
>>>> At Google, we had a process called "canarying".  Although technically a 
>>>> misnomer, it referred to the "canary in the coal mine" concept, with the 
>>>> idea that rolling out new stuff with possible issues should start small, 
>>>> so that problems could be found (and hopefully fixed) before they caused 
>>>> large-scale breakage.
>>>> 
>>>> If the OpenSSL folks were committed to maintaining backward compatibility, 
>>>> then none of this nonsense would be necessary, but it's clear that they're 
>>>> not.  And there's no reason to assume that they won't pull the same crap 
>>>> again in the future (having done so at least twice already), so having a 
>>>> mechanism for multiple coexisting OpenSSL "major" versions could have 
>>>> long-term value beyond the v3 transition.
>>>> 
>>>> > TBH I also was quite dubious of making 3.0.0 the default any time ’soon’
>>>> 
>>>> I agree, especially if the only end benefit is the license.  Remember, 
>>>> OpenSSL is the poster child for why *not* to assume that that newer is 
>>>> more secure. :-)
>>>> 
>>>> Fred Wright
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20211106/d7efb204/attachment-0001.htm>