Admittedly, I didn’t do much (or any) of the actual work… Just thought it was a good idea to mention this on the mailing list as it seems that GitHub only tags the first 50 maintainers and there are more here ;)
Anyway, regarding the FIPS provides, I opened a PR (https://github.com/macports/macports-ports/pull/12835) to enable that. Renee > On Nov 6, 2021, at 1:17 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> > wrote: > > 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.w...@gmail.com >> <mailto:ottenr.w...@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 <jon...@hep.phy.cam.ac.uk >>> <mailto:jon...@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 <jon...@hep.phy.cam.ac.uk >>>> <mailto:jon...@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.web...@gmail.com >>>>> <mailto:ken.cunningham.web...@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 <f...@fwright.net >>>>> <mailto:f...@fwright.net>> wrote: >>>>> >>>>> On Mon, 4 Oct 2021, Christopher Jones wrote: >>>>> >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham >>>>> >> <ken.cunningham.web...@gmail.com >>>>> >> <mailto:ken.cunningham.web...@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 >>>> >>> >> >
