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> 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 >
smime.p7s
Description: S/MIME cryptographic signature
