<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Well thanks, Rene! <div class=""><br class=""></div><div class="">I’m so glad to see this is actually happening now, after a momentary delay.<div class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Ken</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 6, 2021, at 6:34 AM, Renee Otten <<a href="mailto:ottenr.work@gmail.com" class="">ottenr.work@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Dear all, <div class=""><br class=""></div><div class=""><br class=""></div><div class="">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 (<a href="https://github.com/macports/macports-ports/pull/12807" class="">https://github.com/macports/macports-ports/pull/12807</a>) 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.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">PortGroup openssl 1.0</div><div class="">openssl.branch 1.1</div><div class=""><br class=""><div class="">and depending on the build-system one can also specify “openssl.configure” which takes the options: 'pkgconfig' (default), 'build_flags', or 'cmake’. </div><div class=""><br class=""></div><div class="">For other options, please refer to the PortGroup code: <a href="https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/openssl-1.0.tcl" class="">https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/openssl-1.0.tcl</a>. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 7, 2021, at 12:16 PM, Christopher Jones <<a href="mailto:jonesc@hep.phy.cam.ac.uk" class="">jonesc@hep.phy.cam.ac.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><a href="https://github.com/macports/macports-ports/pull/12514" class="">https://github.com/macports/macports-ports/pull/12514</a></div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 6 Oct 2021, at 5:46 pm, Christopher Jones <<a href="mailto:jonesc@hep.phy.cam.ac.uk" class="">jonesc@hep.phy.cam.ac.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 6 Oct 2021, at 5:40 pm, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" class="">ken.cunningham.webuse@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">For whoever gets up the enthusiasm to take on the storm of nay-sayers:</div><div class=""><br class=""></div>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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">Ken</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 5, 2021 at 12:54 PM Fred Wright <<a href="mailto:fw@fwright.net" class="">fw@fwright.net</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br class="">
On Mon, 4 Oct 2021, Christopher Jones wrote:<br class="">
>> On 4 Oct 2021, at 5:54 pm, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" target="_blank" class="">ken.cunningham.webuse@gmail.com</a>> wrote:<br class="">
>><br class="">
>> I was hoping to move this along for the overwhelming benefit of the <br class="">
>> license, but TBH the push-back so far is 99.99% negative about moving <br class="">
>> to openssl 3.0.0 this year, so too controversial for me to get involved <br class="">
>> with. I'll sit back for six to twelve months and see what you guys work <br class="">
>> out over the coming year.<br class="">
><br class="">
> All the more reason to follow my suggested migration path then I would <br class="">
> say, as it allows an openssl30 port to be made available, and those <br class="">
> ports that wish to can use it via the new PG, but it doesn’t have to <br class="">
> become the default until some later date.<br class="">
<br class="">
The PR thread contained (approximately) the following two statements:<br class="">
<br class="">
1) Unless v3 is the default, nobody will bother to use it.<br class="">
<br class="">
2) Everybody is really, *really* anxious to move to v3 for the more <br class="">
permissive license.<br class="">
<br class="">
Clearly those two statements are in conflict.<br class="">
<br class="">
At Google, we had a process called "canarying". Although technically a <br class="">
misnomer, it referred to the "canary in the coal mine" concept, with the <br class="">
idea that rolling out new stuff with possible issues should start small, <br class="">
so that problems could be found (and hopefully fixed) before they caused <br class="">
large-scale breakage.<br class="">
<br class="">
If the OpenSSL folks were committed to maintaining backward compatibility, <br class="">
then none of this nonsense would be necessary, but it's clear that they're <br class="">
not. And there's no reason to assume that they won't pull the same crap <br class="">
again in the future (having done so at least twice already), so having a <br class="">
mechanism for multiple coexisting OpenSSL "major" versions could have <br class="">
long-term value beyond the v3 transition.<br class="">
<br class="">
> TBH I also was quite dubious of making 3.0.0 the default any time ’soon’<br class="">
<br class="">
I agree, especially if the only end benefit is the license. Remember, <br class="">
OpenSSL is the poster child for why *not* to assume that that newer is <br class="">
more secure. :-)<br class="">
<br class="">
Fred Wright</blockquote></div>
</div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></body></html>