upgrade to openssl 3.0.0

Christopher Jones jonesc at hep.phy.cam.ac.uk
Thu Oct 7 16:16:09 UTC 2021

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> 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/20211007/3b6d0773/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1930 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20211007/3b6d0773/attachment.bin>

More information about the macports-dev mailing list