<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=""><div class=""><br class=""></div><div><a href="https://github.com/macports/macports-ports/pull/12514" class="">https://github.com/macports/macports-ports/pull/12514</a></div><div><br class=""></div><div><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=""></body></html>