upgrade to openssl 3.0.0

[Ken Cunningham]

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> 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> 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/20211006/e1fe5c75/attachment.htm>