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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> On Mon, 4 Oct 2021, Christopher Jones wrote: >>>> >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham >>>> >> <[email protected] >>>> >> <mailto:[email protected]>> 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 >>> >> >
