Re: upgrade to openssl 3.0.0

[Steven Smith]

FYSA `postfix +tls` must also be updated after the jump to OpenSSL 3. Please 
see https://github.com/macports/macports-ports/pull/12856.

Re: upgrade to openssl 3.0.0

[Renee Otten]

Admittedly, I didn’t do much (or any) of the actual work… Just thought it was a 
good idea to mention this on the mailing list as it seems that GitHub only tags 
the first 50 maintainers and there are more here ;) 

Anyway, regarding the FIPS provides, I opened a PR 
(https://github.com/macports/macports-ports/pull/12835) to enable that.

Renee


> On Nov 6, 2021, at 1:17 PM, Ken Cunningham  
> wrote:
> 
> Well thanks, Rene!  
> 
> I’m so glad to see this is actually happening now, after a momentary delay.
> 
> 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.
> 
> Ken
> 
> 
> 
> 
>> On Nov 6, 2021, at 6:34 AM, Renee Otten > > wrote:
>> 
>> Dear all, 
>> 
>> 
>> 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 
>> (https://github.com/macports/macports-ports/pull/12807 
>> ) 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.
>> 
>> 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:
>> 
>> PortGroup openssl 1.0
>> openssl.branch1.1
>> 
>> and depending on the build-system one can also specify “openssl.configure” 
>> which takes the options: 'pkgconfig' (default), 'build_flags', or 'cmake’. 
>> 
>> For other options, please refer to the PortGroup code: 
>> https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/openssl-1.0.tcl
>>  
>> .
>>  
>> 
>> 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.
>> 
>> 
>> 
>> 
>>> On Oct 7, 2021, at 12:16 PM, Christopher Jones >> > wrote:
>>> 
>>> 
>>> https://github.com/macports/macports-ports/pull/12514 
>>> 
>>> 
>>> 
 On 6 Oct 2021, at 5:46 pm, Christopher Jones >>> > 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 
>  > 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  > wrote:
> 
> On Mon, 4 Oct 2021, Christopher Jones wrote:
> >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham 
> >>  >> > 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 

Re: upgrade to openssl 3.0.0

[Ken Cunningham]

Well thanks, Rene!  

I’m so glad to see this is actually happening now, after a momentary delay.

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.

Ken




> On Nov 6, 2021, at 6:34 AM, Renee Otten  wrote:
> 
> Dear all, 
> 
> 
> 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 
> (https://github.com/macports/macports-ports/pull/12807 
> ) 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.
> 
> 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:
> 
> PortGroup openssl 1.0
> openssl.branch1.1
> 
> and depending on the build-system one can also specify “openssl.configure” 
> which takes the options: 'pkgconfig' (default), 'build_flags', or 'cmake’. 
> 
> For other options, please refer to the PortGroup code: 
> https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/openssl-1.0.tcl
>  
> .
>  
> 
> 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.
> 
> 
> 
> 
>> On Oct 7, 2021, at 12:16 PM, Christopher Jones > > wrote:
>> 
>> 
>> https://github.com/macports/macports-ports/pull/12514 
>> 
>> 
>> 
>>> On 6 Oct 2021, at 5:46 pm, Christopher Jones >> > 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 >>> > 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 >>> > wrote:
 
 On Mon, 4 Oct 2021, Christopher Jones wrote:
 >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham 
 >> >>> >> > 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 

Re: upgrade to openssl 3.0.0

[Renee Otten]

Dear all, 


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 
(https://github.com/macports/macports-ports/pull/12807 
) 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.

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:

PortGroup openssl 1.0
openssl.branch1.1

and depending on the build-system one can also specify “openssl.configure” 
which takes the options: 'pkgconfig' (default), 'build_flags', or 'cmake’. 

For other options, please refer to the PortGroup code: 
https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/openssl-1.0.tcl
 
.
 

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.


> On Oct 7, 2021, at 12:16 PM, Christopher Jones  
> wrote:
> 
> 
> https://github.com/macports/macports-ports/pull/12514 
> 
> 
> 
>> On 6 Oct 2021, at 5:46 pm, Christopher Jones > > 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 >> > 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 >> > wrote:
>>> 
>>> On Mon, 4 Oct 2021, Christopher Jones wrote:
>>> >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham 
>>> >> >> >> > 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" 

Re: upgrade to openssl 3.0.0

[Christopher Jones]

https://github.com/macports/macports-ports/pull/12514 



> On 6 Oct 2021, at 5:46 pm, Christopher Jones  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 > > 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 > > wrote:
>> 
>> On Mon, 4 Oct 2021, Christopher Jones wrote:
>> >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham 
>> >> > >> > 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

Re: upgrade to openssl 3.0.0

[Christopher Jones]

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  
> 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  > wrote:
> 
> On Mon, 4 Oct 2021, Christopher Jones wrote:
> >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham  >> > 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

Re: 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  wrote:

>
> On Mon, 4 Oct 2021, Christopher Jones wrote:
> >> On 4 Oct 2021, at 5:54 pm, Ken Cunningham <
> 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

Re: upgrade to openssl 3.0.0

[Fred Wright]

On Mon, 4 Oct 2021, Christopher Jones wrote:

On 4 Oct 2021, at 5:54 pm, Ken Cunningham  
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

Re: upgrade to openssl 3.0.0

[Vincent Habchi]

> On 5 Oct 2021, at 20:10, Daniel J. Luke  wrote:
> 
> I suspect if we wait, we'll just end up doing this same thing later - so 
> might as well get it over with now. The sooner we get to a state where 
> (mostly) things all work with the latest openssl, the better.

Just my tuppence:

While I usually agree with that politics (don’t defer until tomorrow that which 
you can do today), please don’t forget that the official release of MacOS 12 
‘Monterey’ is about to be announced, so both would more or less clash. It might 
be wise to delay the upgrade to 3.0.0 once everyone has upgraded to the new 
version (or at least, a couple of weeks after).

Vincent

And I apologise dearly if someone has already raised this point, I simply don’t 
feel like reading the thread from the get-go :p :S 

Re: upgrade to openssl 3.0.0

[Daniel J. Luke]

On Oct 4, 2021, at 12:54 PM, Ken Cunningham  
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.

I haven't chimed in here, but I think Ken's approach is the right one (and also 
matches what we've previously done pretty closely).

I suspect if we wait, we'll just end up doing this same thing later - so might 
as well get it over with now. The sooner we get to a state where (mostly) 
things all work with the latest openssl, the better.

-- 
Daniel J. Luke

Re: upgrade to openssl 3.0.0

[Renee Otten]

to gradually move the 758 
>> >>>> ports to openssl 3.0.0 as they get to it.
>> >>>>
>> >>>> Although that is possible with suitable effort, I don’t think that 
>> >>>> is workable for many reasons, the most obvious being that we would 
>> >>>> then have to modify every single port in some way to find an openssl 
>> >>>> installed into a non-default prefix. Creating the PG and adding it 
>> >>>> to 758 ports might be work enough, but then finding the right way to 
>> >>>> force all 758 ports to build properly against an openssl that is not 
>> >>>> in the default prefix is the real horror, and seems like a nightmare 
>> >>>> of wasted labours.
>> >>>>
>> >>>> So it would appear that the same option that was chosen last time, 
>> >>>> ie upgrade the default openssl in ${prefix} to the newer openssl, 
>> >>>> and then fix the subset of ports that will not build against it to 
>> >>>> use an older openssl appears both the better option and lot less 
>> >>>> work (assuming most ports do build against openssl 3.0.0, which 
>> >>>> seems to be the case so far). Some will disagree, but I put it to 
>> >>>> you that it is going to be far less work in the end to force a few % 
>> >>>> of the ports to a specific alternate openssl than force all of them, 
>> >>>> all the time, forever.
>> >>>>
>> >>>> Most things I have attempted to rebuild over the past few days have 
>> >>>> rebuilt without any issues, but a few things don’t build with 
>> >>>> openssl 3.0.0 yet and will need to stay with openssl 1.1.1 for a 
>> >>>> while until patched or updated (or forever). That will require both 
>> >>>> forcing those ports to find an alternate openssl installation, and 
>> >>>> also (the tricky part) forcing them to ignore the openssl in the 
>> >>>> default prefix.
>> >>>>
>> >>>> To support this, there is a new openssl11 port that provides openssl 
>> >>>> 1.1.1 tucked away in a subdir, much like we have openssl10, and a 
>> >>>> few new options were added to the old_openssl PortGroup to allow 
>> >>>> most ports to be forced to the alternate openssl with minimal fuss. 
>> >>>> Add the PortGroup, spec the branch, and choose the method, for the 
>> >>>> most part.
>> >>>>
>> >>>> If this plan holds, I would anticipate that we move ports that we 
>> >>>> find need to stay on openssl 1.1.1 to openssl11 using the 
>> >>>> old_openssl PortGroup soon or now, before we upgrade to openssl 
>> >>>> 3.0.0 to minimize fuss. Then once we have done that, upgrading the 
>> >>>> default openssl to 3.0.0 and revbumping the deps would occur.
>> >>>>
>> >>>> So I am asking that anyone with an interest in a port that uses 
>> >>>> openssl please try building it against openssl 3.0.0 in the PR 
>> >>>> below, and if there is a problem that can’t be solved by an update 
>> >>>> or a patch, consider trying to use the old_openssl PortGroup to fix 
>> >>>> the build and move it over. As there are so many ports, it would 
>> >>>> help if people pitched in with the ones that are important to them.
>> >>>>
>> >>>> The openssl 3.0.0 upgrade PR is here:
>> >>>>
>> >>>> https://github.com/macports/macports-ports/pull/12410 
>> >>>> <https://github.com/macports/macports-ports/pull/12410> 
>> >>>> <https://github.com/macports/macports-ports/pull/12410 
>> >>>> <https://github.com/macports/macports-ports/pull/12410>>
>> >>>>
>> >>>> and my own WIP repo of a few ports that I have found won’t build 
>> >>>> with openssl 3.0.0 at present and fixed to use the old_openssl PG is 
>> >>>> here:
>> >>>>
>> >>>> https://github.com/kencu/mybigsuroverlay/ 
>> >>>> <https://github.com/kencu/mybigsuroverlay/> 
>> >>>> <https://github.com/kencu/mybigsuroverlay/ 
>> >>>> <https://github.com/kencu/mybigsuroverlay/>>
>> >>>>
>> >>>> the idea is that the ports in that repo would be moved into the main 
>> >>>> repo as we work through the main ones that use openssl at least.
>> >>>>
>> >>>>
>> >>>> K
>> >>>>
>> >>>> PS. One thing I have not yet sorted out how to do is how to support 
>> >>>> libressl in the setting of needing to force a port to openssl 1.1.1 
>> >>>> using the old_openssl PortGroup. Open to any thoughts on this. This 
>> >>>> case wsa basically just ignored last time with openssl10, and we may 
>> >>>> have to do the same again unless someone has a bright idea.
>> >>>>
>> >>>>
>> >>
>> > 
> 

Re: upgrade to openssl 3.0.0

[Christopher Jones]

gt;
> >>> On Oct 2, 2021, at 12:02 PM, Chris Jones  >>> <mailto:jon...@hep.phy.cam.ac.uk> 
> >>> <mailto:jon...@hep.phy.cam.ac.uk <mailto:jon...@hep.phy.cam.ac.uk>>> 
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Personally I would strongly recommend following a migration path that 
> >>> does not require an enmass change but allows ports to migrate  at 
> >>> their own pace. I would personally very much recommend an approach 
> >>> similar to that we used for boost recently
> >>>
> >>> 1. Introduced a set of new isolated opensslXYZ ports that install 
> >>> specific versions into isolated install areas under libexec.
> >>> 2. Create a new portgroup that handles the confirmation of ports to 
> >>> pick the openssl version they wish to use, with some default, and 
> >>> performs various standard configurations for standard build systems 
> >>> such that for most ports they work out the box with the new 
> >>> portgroup. For those that don’t provide various proc methods that 
> >>> return the configured install paths such that ports can used them to 
> >>> configure themselves as required.
> >>> 3. Make the current openssl port a basic shim port that just installs 
> >>> sym links into the primary install area to the default openssl 
> >>> version (for now 1.1.1), so ports building against the current 
> >>> openssl port carry on working just as they are now, but are 
> >>> redirected to use the same versioned 1.1.1 port as those using the PG.
> >>>
> >>> Once this is in place, ports can be migrated to use the new PG 
> >>> individually as and when we want.
> >>>
> >>> Chris
> >>>
> >>>> On 2 Oct 2021, at 6:17 pm, Ken Cunningham 
> >>>>  >>>> <mailto:ken.cunningham.web...@gmail.com> 
> >>>> <mailto:ken.cunningham.web...@gmail.com 
> >>>> <mailto:ken.cunningham.web...@gmail.com>>> wrote:
> >>>>
> >>>> 
> >>>> openssl 3.0.0 is out, with a new and very favourable Apache-2 
> >>>> license that will let many previously non-distributable ports become 
> >>>> distributable.  However, there are 758 ports that indicate they link 
> >>>> against openssl. That is a daunting number of ports indeed.
> >>>>
> >>>> One option might be to move all of our openssl ports (1.0, 1.1, and 
> >>>> 3.x) into subdirectories out of ${prefix}, have no default openssl 
> >>>> installed in $[prefix} directly, create a new PortGroup, 
> >>>> openssl_select or some such, add that PG to all 758 ports, default 
> >>>> it to openssl 1.1.1, and then allow people to gradually move the 758 
> >>>> ports to openssl 3.0.0 as they get to it.
> >>>>
> >>>> Although that is possible with suitable effort, I don’t think that 
> >>>> is workable for many reasons, the most obvious being that we would 
> >>>> then have to modify every single port in some way to find an openssl 
> >>>> installed into a non-default prefix. Creating the PG and adding it 
> >>>> to 758 ports might be work enough, but then finding the right way to 
> >>>> force all 758 ports to build properly against an openssl that is not 
> >>>> in the default prefix is the real horror, and seems like a nightmare 
> >>>> of wasted labours.
> >>>>
> >>>> So it would appear that the same option that was chosen last time, 
> >>>> ie upgrade the default openssl in ${prefix} to the newer openssl, 
> >>>> and then fix the subset of ports that will not build against it to 
> >>>> use an older openssl appears both the better option and lot less 
> >>>> work (assuming most ports do build against openssl 3.0.0, which 
> >>>> seems to be the case so far). Some will disagree, but I put it to 
> >>>> you that it is going to be far less work in the end to force a few % 
> >>>> of the ports to a specific alternate openssl than force all of them, 
> >>>> all the time, forever.
> >>>>
> >>>> Most things I have attempted to rebuild over the past few days have 
> >>>> rebuilt without any issues, but a few things don’t build with 
> >>>> openssl 3.0.0 yet and will need to stay with openssl 1.1.1

Re: upgrade to openssl 3.0.0

[Ken Cunningham]

der libexec.
> >>> 2. Create a new portgroup that handles the confirmation of ports to
> >>> pick the openssl version they wish to use, with some default, and
> >>> performs various standard configurations for standard build systems
> >>> such that for most ports they work out the box with the new
> >>> portgroup. For those that don’t provide various proc methods that
> >>> return the configured install paths such that ports can used them to
> >>> configure themselves as required.
> >>> 3. Make the current openssl port a basic shim port that just installs
> >>> sym links into the primary install area to the default openssl
> >>> version (for now 1.1.1), so ports building against the current
> >>> openssl port carry on working just as they are now, but are
> >>> redirected to use the same versioned 1.1.1 port as those using the PG.
> >>>
> >>> Once this is in place, ports can be migrated to use the new PG
> >>> individually as and when we want.
> >>>
> >>> Chris
> >>>
> >>>> On 2 Oct 2021, at 6:17 pm, Ken Cunningham
> >>>>  >>>> <mailto:ken.cunningham.web...@gmail.com>> wrote:
> >>>>
> >>>> 
> >>>> openssl 3.0.0 is out, with a new and very favourable Apache-2
> >>>> license that will let many previously non-distributable ports become
> >>>> distributable.  However, there are 758 ports that indicate they link
> >>>> against openssl. That is a daunting number of ports indeed.
> >>>>
> >>>> One option might be to move all of our openssl ports (1.0, 1.1, and
> >>>> 3.x) into subdirectories out of ${prefix}, have no default openssl
> >>>> installed in $[prefix} directly, create a new PortGroup,
> >>>> openssl_select or some such, add that PG to all 758 ports, default
> >>>> it to openssl 1.1.1, and then allow people to gradually move the 758
> >>>> ports to openssl 3.0.0 as they get to it.
> >>>>
> >>>> Although that is possible with suitable effort, I don’t think that
> >>>> is workable for many reasons, the most obvious being that we would
> >>>> then have to modify every single port in some way to find an openssl
> >>>> installed into a non-default prefix. Creating the PG and adding it
> >>>> to 758 ports might be work enough, but then finding the right way to
> >>>> force all 758 ports to build properly against an openssl that is not
> >>>> in the default prefix is the real horror, and seems like a nightmare
> >>>> of wasted labours.
> >>>>
> >>>> So it would appear that the same option that was chosen last time,
> >>>> ie upgrade the default openssl in ${prefix} to the newer openssl,
> >>>> and then fix the subset of ports that will not build against it to
> >>>> use an older openssl appears both the better option and lot less
> >>>> work (assuming most ports do build against openssl 3.0.0, which
> >>>> seems to be the case so far). Some will disagree, but I put it to
> >>>> you that it is going to be far less work in the end to force a few %
> >>>> of the ports to a specific alternate openssl than force all of them,
> >>>> all the time, forever.
> >>>>
> >>>> Most things I have attempted to rebuild over the past few days have
> >>>> rebuilt without any issues, but a few things don’t build with
> >>>> openssl 3.0.0 yet and will need to stay with openssl 1.1.1 for a
> >>>> while until patched or updated (or forever). That will require both
> >>>> forcing those ports to find an alternate openssl installation, and
> >>>> also (the tricky part) forcing them to ignore the openssl in the
> >>>> default prefix.
> >>>>
> >>>> To support this, there is a new openssl11 port that provides openssl
> >>>> 1.1.1 tucked away in a subdir, much like we have openssl10, and a
> >>>> few new options were added to the old_openssl PortGroup to allow
> >>>> most ports to be forced to the alternate openssl with minimal fuss.
> >>>> Add the PortGroup, spec the branch, and choose the method, for the
> >>>> most part.
> >>>>
> >>>> If this plan holds, I would anticipate that we move ports that we
> >>>> find need to stay on openssl 1

Re: upgrade to openssl 3.0.0

[Chris Jones]

owever, there are 758 ports that indicate they link 
against openssl. That is a daunting number of ports indeed.


One option might be to move all of our openssl ports (1.0, 1.1, and 
3.x) into subdirectories out of ${prefix}, have no default openssl 
installed in $[prefix} directly, create a new PortGroup, 
openssl_select or some such, add that PG to all 758 ports, default 
it to openssl 1.1.1, and then allow people to gradually move the 758 
ports to openssl 3.0.0 as they get to it.


Although that is possible with suitable effort, I don’t think that 
is workable for many reasons, the most obvious being that we would 
then have to modify every single port in some way to find an openssl 
installed into a non-default prefix. Creating the PG and adding it 
to 758 ports might be work enough, but then finding the right way to 
force all 758 ports to build properly against an openssl that is not 
in the default prefix is the real horror, and seems like a nightmare 
of wasted labours.


So it would appear that the same option that was chosen last time, 
ie upgrade the default openssl in ${prefix} to the newer openssl, 
and then fix the subset of ports that will not build against it to 
use an older openssl appears both the better option and lot less 
work (assuming most ports do build against openssl 3.0.0, which 
seems to be the case so far). Some will disagree, but I put it to 
you that it is going to be far less work in the end to force a few % 
of the ports to a specific alternate openssl than force all of them, 
all the time, forever.


Most things I have attempted to rebuild over the past few days have 
rebuilt without any issues, but a few things don’t build with 
openssl 3.0.0 yet and will need to stay with openssl 1.1.1 for a 
while until patched or updated (or forever). That will require both 
forcing those ports to find an alternate openssl installation, and 
also (the tricky part) forcing them to ignore the openssl in the 
default prefix.


To support this, there is a new openssl11 port that provides openssl 
1.1.1 tucked away in a subdir, much like we have openssl10, and a 
few new options were added to the old_openssl PortGroup to allow 
most ports to be forced to the alternate openssl with minimal fuss. 
Add the PortGroup, spec the branch, and choose the method, for the 
most part.


If this plan holds, I would anticipate that we move ports that we 
find need to stay on openssl 1.1.1 to openssl11 using the 
old_openssl PortGroup soon or now, before we upgrade to openssl 
3.0.0 to minimize fuss. Then once we have done that, upgrading the 
default openssl to 3.0.0 and revbumping the deps would occur.


So I am asking that anyone with an interest in a port that uses 
openssl please try building it against openssl 3.0.0 in the PR 
below, and if there is a problem that can’t be solved by an update 
or a patch, consider trying to use the old_openssl PortGroup to fix 
the build and move it over. As there are so many ports, it would 
help if people pitched in with the ones that are important to them.


The openssl 3.0.0 upgrade PR is here:

https://github.com/macports/macports-ports/pull/12410 
<https://github.com/macports/macports-ports/pull/12410>


and my own WIP repo of a few ports that I have found won’t build 
with openssl 3.0.0 at present and fixed to use the old_openssl PG is 
here:


https://github.com/kencu/mybigsuroverlay/ 
<https://github.com/kencu/mybigsuroverlay/>


the idea is that the ports in that repo would be moved into the main 
repo as we work through the main ones that use openssl at least.



K

PS. One thing I have not yet sorted out how to do is how to support 
libressl in the setting of needing to force a port to openssl 1.1.1 
using the old_openssl PortGroup. Open to any thoughts on this. This 
case wsa basically just ignored last time with openssl10, and we may 
have to do the same again unless someone has a bright idea.

Re: upgrade to openssl 3.0.0

[Christopher Jones]

 also (the tricky part) forcing them to 
>>> ignore the openssl in the default prefix.
>>> 
>>> To support this, there is a new openssl11 port that provides openssl 1.1.1 
>>> tucked away in a subdir, much like we have openssl10, and a few new options 
>>> were added to the old_openssl PortGroup to allow most ports to be forced to 
>>> the alternate openssl with minimal fuss. Add the PortGroup, spec the 
>>> branch, and choose the method, for the most part.
>>> 
>>> If this plan holds, I would anticipate that we move ports that we find need 
>>> to stay on openssl 1.1.1 to openssl11 using the old_openssl PortGroup soon 
>>> or now, before we upgrade to openssl 3.0.0 to minimize fuss. Then once we 
>>> have done that, upgrading the default openssl to 3.0.0 and revbumping the 
>>> deps would occur.
>>> 
>>> So I am asking that anyone with an interest in a port that uses openssl 
>>> please try building it against openssl 3.0.0 in the PR below, and if there 
>>> is a problem that can’t be solved by an update or a patch, consider trying 
>>> to use the old_openssl PortGroup to fix the build and move it over. As 
>>> there are so many ports, it would help if people pitched in with the ones 
>>> that are important to them.
>>> 
>>> The openssl 3.0.0 upgrade PR is here:
>>> 
>>> https://github.com/macports/macports-ports/pull/12410 
>>> <https://github.com/macports/macports-ports/pull/12410>
>>> 
>>> and my own WIP repo of a few ports that I have found won’t build with 
>>> openssl 3.0.0 at present and fixed to use the old_openssl PG is here:
>>> 
>>> https://github.com/kencu/mybigsuroverlay/ 
>>> <https://github.com/kencu/mybigsuroverlay/>
>>> 
>>> the idea is that the ports in that repo would be moved into the main repo 
>>> as we work through the main ones that use openssl at least.
>>> 
>>> 
>>> K
>>> 
>>> PS. One thing I have not yet sorted out how to do is how to support 
>>> libressl in the setting of needing to force a port to openssl 1.1.1 using 
>>> the old_openssl PortGroup. Open to any thoughts on this. This case wsa 
>>> basically just ignored last time with openssl10, and we may have to do the 
>>> same again unless someone has a bright idea.
>>> 
>>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: upgrade to openssl 3.0.0

[Christopher Jones]

ectories out of ${prefix}, have no default openssl installed in 
>>>> $[prefix} directly, create a new PortGroup, openssl_select or some such, 
>>>> add that PG to all 758 ports, default it to openssl 1.1.1, and then allow 
>>>> people to gradually move the 758 ports to openssl 3.0.0 as they get to it.
>>>> 
>>>> Although that is possible with suitable effort, I don’t think that is 
>>>> workable for many reasons, the most obvious being that we would then have 
>>>> to modify every single port in some way to find an openssl installed into 
>>>> a non-default prefix. Creating the PG and adding it to 758 ports might be 
>>>> work enough, but then finding the right way to force all 758 ports to 
>>>> build properly against an openssl that is not in the default prefix is the 
>>>> real horror, and seems like a nightmare of wasted labours.
>>>> 
>>>> So it would appear that the same option that was chosen last time, ie 
>>>> upgrade the default openssl in ${prefix} to the newer openssl, and then 
>>>> fix the subset of ports that will not build against it to use an older 
>>>> openssl appears both the better option and lot less work (assuming most 
>>>> ports do build against openssl 3.0.0, which seems to be the case so far). 
>>>> Some will disagree, but I put it to you that it is going to be far less 
>>>> work in the end to force a few % of the ports to a specific alternate 
>>>> openssl than force all of them, all the time, forever.
>>>> 
>>>> Most things I have attempted to rebuild over the past few days have 
>>>> rebuilt without any issues, but a few things don’t build with openssl 
>>>> 3.0.0 yet and will need to stay with openssl 1.1.1 for a while until 
>>>> patched or updated (or forever). That will require both forcing those 
>>>> ports to find an alternate openssl installation, and also (the tricky 
>>>> part) forcing them to ignore the openssl in the default prefix.
>>>> 
>>>> To support this, there is a new openssl11 port that provides openssl 1.1.1 
>>>> tucked away in a subdir, much like we have openssl10, and a few new 
>>>> options were added to the old_openssl PortGroup to allow most ports to be 
>>>> forced to the alternate openssl with minimal fuss. Add the PortGroup, spec 
>>>> the branch, and choose the method, for the most part.
>>>> 
>>>> If this plan holds, I would anticipate that we move ports that we find 
>>>> need to stay on openssl 1.1.1 to openssl11 using the old_openssl PortGroup 
>>>> soon or now, before we upgrade to openssl 3.0.0 to minimize fuss. Then 
>>>> once we have done that, upgrading the default openssl to 3.0.0 and 
>>>> revbumping the deps would occur.
>>>> 
>>>> So I am asking that anyone with an interest in a port that uses openssl 
>>>> please try building it against openssl 3.0.0 in the PR below, and if there 
>>>> is a problem that can’t be solved by an update or a patch, consider trying 
>>>> to use the old_openssl PortGroup to fix the build and move it over. As 
>>>> there are so many ports, it would help if people pitched in with the ones 
>>>> that are important to them.
>>>> 
>>>> The openssl 3.0.0 upgrade PR is here:
>>>> 
>>>> https://github.com/macports/macports-ports/pull/12410 
>>>> <https://github.com/macports/macports-ports/pull/12410>
>>>> 
>>>> and my own WIP repo of a few ports that I have found won’t build with 
>>>> openssl 3.0.0 at present and fixed to use the old_openssl PG is here:
>>>> 
>>>> https://github.com/kencu/mybigsuroverlay/ 
>>>> <https://github.com/kencu/mybigsuroverlay/>
>>>> 
>>>> the idea is that the ports in that repo would be moved into the main repo 
>>>> as we work through the main ones that use openssl at least.
>>>> 
>>>> 
>>>> K
>>>> 
>>>> PS. One thing I have not yet sorted out how to do is how to support 
>>>> libressl in the setting of needing to force a port to openssl 1.1.1 using 
>>>> the old_openssl PortGroup. Open to any thoughts on this. This case wsa 
>>>> basically just ignored last time with openssl10, and we may have to do the 
>>>> same again unless someone has a bright idea.
>>>> 
>>>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: upgrade to openssl 3.0.0

[Ken Cunningham]

That is exactly the approach that I don't find workable, Chris.

Specifically:

1. every single port (think: rust, ghc, blah blah) will have to be needlessly 
managed to build against an alternate openssl location.
2. there will be no default openssl ever in prefix.

So I am not on board for trying to implement that myself, but should that be 
the selected course I will watch from the sidelines as others proceed down that 
path.

K

> On Oct 2, 2021, at 12:02 PM, Chris Jones  wrote:
> 
> Hi,
> 
> Personally I would strongly recommend following a migration path that does 
> not require an enmass change but allows ports to migrate  at their own pace. 
> I would personally very much recommend an approach similar to that we used 
> for boost recently
> 
> 1. Introduced a set of new isolated opensslXYZ ports that install specific 
> versions into isolated install areas under libexec.
> 2. Create a new portgroup that handles the confirmation of ports to pick the 
> openssl version they wish to use, with some default, and performs various 
> standard configurations for standard build systems such that for most ports 
> they work out the box with the new portgroup. For those that don’t provide 
> various proc methods that return the configured install paths such that ports 
> can used them to configure themselves as required.
> 3. Make the current openssl port a basic shim port that just installs sym 
> links into the primary install area to the default openssl version (for now 
> 1.1.1), so ports building against the current openssl port carry on working 
> just as they are now, but are redirected to use the same versioned 1.1.1 port 
> as those using the PG.
> 
> Once this is in place, ports can be migrated to use the new PG individually 
> as and when we want.
> 
> Chris
> 
>> On 2 Oct 2021, at 6:17 pm, Ken Cunningham  
>> wrote:
>> 
>> 
>> openssl 3.0.0 is out, with a new and very favourable Apache-2 license that 
>> will let many previously non-distributable ports become distributable.  
>> However, there are 758 ports that indicate they link against openssl. That 
>> is a daunting number of ports indeed.
>> 
>> One option might be to move all of our openssl ports (1.0, 1.1, and 3.x) 
>> into subdirectories out of ${prefix}, have no default openssl installed in 
>> $[prefix} directly, create a new PortGroup, openssl_select or some such, add 
>> that PG to all 758 ports, default it to openssl 1.1.1, and then allow people 
>> to gradually move the 758 ports to openssl 3.0.0 as they get to it.
>> 
>> Although that is possible with suitable effort, I don’t think that is 
>> workable for many reasons, the most obvious being that we would then have to 
>> modify every single port in some way to find an openssl installed into a 
>> non-default prefix. Creating the PG and adding it to 758 ports might be work 
>> enough, but then finding the right way to force all 758 ports to build 
>> properly against an openssl that is not in the default prefix is the real 
>> horror, and seems like a nightmare of wasted labours.
>> 
>> So it would appear that the same option that was chosen last time, ie 
>> upgrade the default openssl in ${prefix} to the newer openssl, and then fix 
>> the subset of ports that will not build against it to use an older openssl 
>> appears both the better option and lot less work (assuming most ports do 
>> build against openssl 3.0.0, which seems to be the case so far). Some will 
>> disagree, but I put it to you that it is going to be far less work in the 
>> end to force a few % of the ports to a specific alternate openssl than force 
>> all of them, all the time, forever.
>> 
>> Most things I have attempted to rebuild over the past few days have rebuilt 
>> without any issues, but a few things don’t build with openssl 3.0.0 yet and 
>> will need to stay with openssl 1.1.1 for a while until patched or updated 
>> (or forever). That will require both forcing those ports to find an 
>> alternate openssl installation, and also (the tricky part) forcing them to 
>> ignore the openssl in the default prefix.
>> 
>> To support this, there is a new openssl11 port that provides openssl 1.1.1 
>> tucked away in a subdir, much like we have openssl10, and a few new options 
>> were added to the old_openssl PortGroup to allow most ports to be forced to 
>> the alternate openssl with minimal fuss. Add the PortGroup, spec the branch, 
>> and choose the method, for the most part.
>> 
>> If this plan holds, I would anticipate that we move ports that we find need 
>> to stay on openssl 1.1.1 to openssl11 using the old_openssl PortGroup soon 
>&g

Re: upgrade to openssl 3.0.0

[Chris Jones]

Hi,

Personally I would strongly recommend following a migration path that does not 
require an enmass change but allows ports to migrate  at their own pace. I 
would personally very much recommend an approach similar to that we used for 
boost recently

1. Introduced a set of new isolated opensslXYZ ports that install specific 
versions into isolated install areas under libexec.
2. Create a new portgroup that handles the confirmation of ports to pick the 
openssl version they wish to use, with some default, and performs various 
standard configurations for standard build systems such that for most ports 
they work out the box with the new portgroup. For those that don’t provide 
various proc methods that return the configured install paths such that ports 
can used them to configure themselves as required.
3. Make the current openssl port a basic shim port that just installs sym links 
into the primary install area to the default openssl version (for now 1.1.1), 
so ports building against the current openssl port carry on working just as 
they are now, but are redirected to use the same versioned 1.1.1 port as those 
using the PG.

Once this is in place, ports can be migrated to use the new PG individually as 
and when we want.

Chris

> On 2 Oct 2021, at 6:17 pm, Ken Cunningham  
> wrote:
> 
> 
> openssl 3.0.0 is out, with a new and very favourable Apache-2 license that 
> will let many previously non-distributable ports become distributable.  
> However, there are 758 ports that indicate they link against openssl. That is 
> a daunting number of ports indeed.
> 
> One option might be to move all of our openssl ports (1.0, 1.1, and 3.x) into 
> subdirectories out of ${prefix}, have no default openssl installed in 
> $[prefix} directly, create a new PortGroup, openssl_select or some such, add 
> that PG to all 758 ports, default it to openssl 1.1.1, and then allow people 
> to gradually move the 758 ports to openssl 3.0.0 as they get to it.
> 
> Although that is possible with suitable effort, I don’t think that is 
> workable for many reasons, the most obvious being that we would then have to 
> modify every single port in some way to find an openssl installed into a 
> non-default prefix. Creating the PG and adding it to 758 ports might be work 
> enough, but then finding the right way to force all 758 ports to build 
> properly against an openssl that is not in the default prefix is the real 
> horror, and seems like a nightmare of wasted labours.
> 
> So it would appear that the same option that was chosen last time, ie upgrade 
> the default openssl in ${prefix} to the newer openssl, and then fix the 
> subset of ports that will not build against it to use an older openssl 
> appears both the better option and lot less work (assuming most ports do 
> build against openssl 3.0.0, which seems to be the case so far). Some will 
> disagree, but I put it to you that it is going to be far less work in the end 
> to force a few % of the ports to a specific alternate openssl than force all 
> of them, all the time, forever.
> 
> Most things I have attempted to rebuild over the past few days have rebuilt 
> without any issues, but a few things don’t build with openssl 3.0.0 yet and 
> will need to stay with openssl 1.1.1 for a while until patched or updated (or 
> forever). That will require both forcing those ports to find an alternate 
> openssl installation, and also (the tricky part) forcing them to ignore the 
> openssl in the default prefix.
> 
> To support this, there is a new openssl11 port that provides openssl 1.1.1 
> tucked away in a subdir, much like we have openssl10, and a few new options 
> were added to the old_openssl PortGroup to allow most ports to be forced to 
> the alternate openssl with minimal fuss. Add the PortGroup, spec the branch, 
> and choose the method, for the most part.
> 
> If this plan holds, I would anticipate that we move ports that we find need 
> to stay on openssl 1.1.1 to openssl11 using the old_openssl PortGroup soon or 
> now, before we upgrade to openssl 3.0.0 to minimize fuss. Then once we have 
> done that, upgrading the default openssl to 3.0.0 and revbumping the deps 
> would occur.
> 
> So I am asking that anyone with an interest in a port that uses openssl 
> please try building it against openssl 3.0.0 in the PR below, and if there is 
> a problem that can’t be solved by an update or a patch, consider trying to 
> use the old_openssl PortGroup to fix the build and move it over. As there are 
> so many ports, it would help if people pitched in with the ones that are 
> important to them.
> 
> The openssl 3.0.0 upgrade PR is here:
> 
> https://github.com/macports/macports-ports/pull/12410
> 
> and my own WIP repo of a few ports that I have found won’t build with openssl 

Re: upgrade to openssl 3.0.0

[Ken Cunningham]

All the pythons build against openssl 3.0.0, so that python issue with all it's 
trail-down conflicts will disappear with the upgrade and python revbump.

A very very large % of ports do as well (and those that don't now soon will, as 
everyone moves to openssl 3.0.0 as the default, which homebrew did pretty much 
the second openssl 3 came out).

So I am hoping that this upgrade is the beginning of the end of this particular 
PITA for all of us.

Ken


> On Oct 2, 2021, at 11:37 AM, Jason Liu  wrote:
> 
> That was also the Blender devs' claim, which I assume is why they decided it 
> wasn't necessary to include the GPL-OpenSSL exception text, since any 
> licensing conflicts would self-resolve once Blender starts using OpenSSL 3.0. 
> But currently, their pre-built release binary downloads and compiles OpenSSL 
> 1.1.1g, which is still under the OpenSSL license, not Apache 2.0.
> 
> -- 
> Jason Liu
> 
> 
> On Sat, Oct 2, 2021 at 2:25 PM Joshua Root  > wrote:
> Blender is GPL-2+, which means it can be distributed when linked with 
> OpenSSL 3.0, since GPL-3 is compatible with Apache-2.
> 
> - Josh
> 
> On 2021-10-3 05:09 , Jason Liu wrote:
> > I hope the question that I'm about to ask doesn't induce 
> > "Inception"-style migraines, but since it directly relates to one of the 
> > ports I maintain, here goes. What if one of my ports indirectly uses 
> > openssl through one of its dependencies, and the licensing terms in the 
> > current version of my port only covers openssl 1.1.1, but not 3.0?
> > 
> > To use a specific example, Blender uses openssl 1.1.1 indirectly, by way 
> > of using networking through python. I contacted the Blender devs about 
> > this, and even though they acknowledged that they were unknowingly using 
> > OpenSSL without including the OpenSSL license, the only thing they ended 
> > up doing was to add the OpenSSL license to their licenses directory. 
> > They refuse, even now, to add the chunk of text specifying the 
> > GPL-OpenSSL exception to their licenses. Somehow their legal team seems 
> > to think that's enough to allow them to distribute pre-compiled 
> > binaries, but the MacPorts automatic license checking is flagging my 
> > Blender port as being non-distributable. Since my port is a couple of 
> > versions behind the latest release of Blender (there are some new 
> > dependent libraries that I need to submit first), how should we specify 
> > in our Portfiles that one of the dependencies should continue using the 
> > old openssl11, without adding the old_openssl PortGroup, and thus a 
> > direct dependency on openssl? Does this mean that the dependencies which 
> > are directly dependent on openssl will need new variants, e.g. +openssl 
> > and +openssl11?
> > 
> > -- 
> > Jason Liu

Re: upgrade to openssl 3.0.0

[Jason Liu]

That was also the Blender devs' claim, which I assume is why they decided
it wasn't necessary to include the GPL-OpenSSL exception text, since any
licensing conflicts would self-resolve once Blender starts using OpenSSL
3.0. But currently, their pre-built release binary downloads and compiles
OpenSSL 1.1.1g, which is still under the OpenSSL license, not Apache 2.0.

-- 
Jason Liu


On Sat, Oct 2, 2021 at 2:25 PM Joshua Root  wrote:

> Blender is GPL-2+, which means it can be distributed when linked with
> OpenSSL 3.0, since GPL-3 is compatible with Apache-2.
>
> - Josh
>
> On 2021-10-3 05:09 , Jason Liu wrote:
> > I hope the question that I'm about to ask doesn't induce
> > "Inception"-style migraines, but since it directly relates to one of the
> > ports I maintain, here goes. What if one of my ports indirectly uses
> > openssl through one of its dependencies, and the licensing terms in the
> > current version of my port only covers openssl 1.1.1, but not 3.0?
> >
> > To use a specific example, Blender uses openssl 1.1.1 indirectly, by way
> > of using networking through python. I contacted the Blender devs about
> > this, and even though they acknowledged that they were unknowingly using
> > OpenSSL without including the OpenSSL license, the only thing they ended
> > up doing was to add the OpenSSL license to their licenses directory.
> > They refuse, even now, to add the chunk of text specifying the
> > GPL-OpenSSL exception to their licenses. Somehow their legal team seems
> > to think that's enough to allow them to distribute pre-compiled
> > binaries, but the MacPorts automatic license checking is flagging my
> > Blender port as being non-distributable. Since my port is a couple of
> > versions behind the latest release of Blender (there are some new
> > dependent libraries that I need to submit first), how should we specify
> > in our Portfiles that one of the dependencies should continue using the
> > old openssl11, without adding the old_openssl PortGroup, and thus a
> > direct dependency on openssl? Does this mean that the dependencies which
> > are directly dependent on openssl will need new variants, e.g. +openssl
> > and +openssl11?
> >
> > --
> > Jason Liu
>

Re: upgrade to openssl 3.0.0

[Joshua Root]

Blender is GPL-2+, which means it can be distributed when linked with 
OpenSSL 3.0, since GPL-3 is compatible with Apache-2.


- Josh

On 2021-10-3 05:09 , Jason Liu wrote:
I hope the question that I'm about to ask doesn't induce 
"Inception"-style migraines, but since it directly relates to one of the 
ports I maintain, here goes. What if one of my ports indirectly uses 
openssl through one of its dependencies, and the licensing terms in the 
current version of my port only covers openssl 1.1.1, but not 3.0?


To use a specific example, Blender uses openssl 1.1.1 indirectly, by way 
of using networking through python. I contacted the Blender devs about 
this, and even though they acknowledged that they were unknowingly using 
OpenSSL without including the OpenSSL license, the only thing they ended 
up doing was to add the OpenSSL license to their licenses directory. 
They refuse, even now, to add the chunk of text specifying the 
GPL-OpenSSL exception to their licenses. Somehow their legal team seems 
to think that's enough to allow them to distribute pre-compiled 
binaries, but the MacPorts automatic license checking is flagging my 
Blender port as being non-distributable. Since my port is a couple of 
versions behind the latest release of Blender (there are some new 
dependent libraries that I need to submit first), how should we specify 
in our Portfiles that one of the dependencies should continue using the 
old openssl11, without adding the old_openssl PortGroup, and thus a 
direct dependency on openssl? Does this mean that the dependencies which 
are directly dependent on openssl will need new variants, e.g. +openssl 
and +openssl11?


--
Jason Liu

Re: upgrade to openssl 3.0.0

[Jason Liu]

I hope the question that I'm about to ask doesn't induce "Inception"-style
migraines, but since it directly relates to one of the ports I maintain,
here goes. What if one of my ports indirectly uses openssl through one
of its dependencies, and the licensing terms in the current version of my
port only covers openssl 1.1.1, but not 3.0?

To use a specific example, Blender uses openssl 1.1.1 indirectly, by way
of using networking through python. I contacted the Blender devs about
this, and even though they acknowledged that they were unknowingly using
OpenSSL without including the OpenSSL license, the only thing they ended up
doing was to add the OpenSSL license to their licenses directory. They
refuse, even now, to add the chunk of text specifying the GPL-OpenSSL
exception to their licenses. Somehow their legal team seems to think that's
enough to allow them to distribute pre-compiled binaries, but the MacPorts
automatic license checking is flagging my Blender port as being
non-distributable. Since my port is a couple of versions behind the latest
release of Blender (there are some new dependent libraries that I need to
submit first), how should we specify in our Portfiles that one of the
dependencies should continue using the old openssl11, without adding the
old_openssl PortGroup, and thus a direct dependency on openssl? Does this
mean that the dependencies which are directly dependent on openssl will
need new variants, e.g. +openssl and +openssl11?

-- 
Jason Liu


On Sat, Oct 2, 2021 at 1:17 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> openssl 3.0.0 is out, with a new and very favourable Apache-2 license that
> will let many previously non-distributable ports become distributable.
> However, there are 758 ports that indicate they link against openssl. That
> is a daunting number of ports indeed.
>
> One option might be to move all of our openssl ports (1.0, 1.1, and 3.x)
> into subdirectories out of ${prefix}, have no default openssl installed in
> $[prefix} directly, create a new PortGroup, openssl_select or some such,
> add that PG to all 758 ports, default it to openssl 1.1.1, and then allow
> people to gradually move the 758 ports to openssl 3.0.0 as they get to it.
>
> Although that is possible with suitable effort, I don’t think that is
> workable for many reasons, the most obvious being that we would then have
> to modify every single port in some way to find an openssl installed into a
> non-default prefix. Creating the PG and adding it to 758 ports might be
> work enough, but then finding the right way to force all 758 ports to build
> properly against an openssl that is not in the default prefix is the real
> horror, and seems like a nightmare of wasted labours.
>
> So it would appear that the same option that was chosen last time, ie
> upgrade the default openssl in ${prefix} to the newer openssl, and then fix
> the subset of ports that will not build against it to use an older openssl
> appears both the better option and lot less work (assuming most ports do
> build against openssl 3.0.0, which seems to be the case so far). Some will
> disagree, but I put it to you that it is going to be far less work in the
> end to force a few % of the ports to a specific alternate openssl than
> force all of them, all the time, forever.
>
> Most things I have attempted to rebuild over the past few days have
> rebuilt without any issues, but a few things don’t build with openssl 3.0.0
> yet and will need to stay with openssl 1.1.1 for a while until patched or
> updated (or forever). That will require both forcing those ports to find an
> alternate openssl installation, and also (the tricky part) forcing them to
> ignore the openssl in the default prefix.
>
> To support this, there is a new openssl11 port that provides openssl 1.1.1
> tucked away in a subdir, much like we have openssl10, and a few new options
> were added to the old_openssl PortGroup to allow most ports to be forced to
> the alternate openssl with minimal fuss. Add the PortGroup, spec the
> branch, and choose the method, for the most part.
>
> If this plan holds, I would anticipate that we move ports that we find
> need to stay on openssl 1.1.1 to openssl11 using the old_openssl PortGroup
> soon or now, before we upgrade to openssl 3.0.0 to minimize fuss. Then once
> we have done that, upgrading the default openssl to 3.0.0 and revbumping
> the deps would occur.
>
> So I am asking that anyone with an interest in a port that uses openssl
> please try building it against openssl 3.0.0 in the PR below, and if there
> is a problem that can’t be solved by an update or a patch, consider trying
> to use the old_openssl PortGroup to fix the build and move it over. As
> there are so many ports, it would help if people pitched in with the ones
> that are 

upgrade to openssl 3.0.0

[Ken Cunningham]

openssl 3.0.0 is out, with a new and very favourable Apache-2 license that will 
let many previously non-distributable ports become distributable.  However, 
there are 758 ports that indicate they link against openssl. That is a daunting 
number of ports indeed.

One option might be to move all of our openssl ports (1.0, 1.1, and 3.x) into 
subdirectories out of ${prefix}, have no default openssl installed in $[prefix} 
directly, create a new PortGroup, openssl_select or some such, add that PG to 
all 758 ports, default it to openssl 1.1.1, and then allow people to gradually 
move the 758 ports to openssl 3.0.0 as they get to it.

Although that is possible with suitable effort, I don’t think that is workable 
for many reasons, the most obvious being that we would then have to modify 
every single port in some way to find an openssl installed into a non-default 
prefix. Creating the PG and adding it to 758 ports might be work enough, but 
then finding the right way to force all 758 ports to build properly against an 
openssl that is not in the default prefix is the real horror, and seems like a 
nightmare of wasted labours.

So it would appear that the same option that was chosen last time, ie upgrade 
the default openssl in ${prefix} to the newer openssl, and then fix the subset 
of ports that will not build against it to use an older openssl appears both 
the better option and lot less work (assuming most ports do build against 
openssl 3.0.0, which seems to be the case so far). Some will disagree, but I 
put it to you that it is going to be far less work in the end to force a few % 
of the ports to a specific alternate openssl than force all of them, all the 
time, forever.

Most things I have attempted to rebuild over the past few days have rebuilt 
without any issues, but a few things don’t build with openssl 3.0.0 yet and 
will need to stay with openssl 1.1.1 for a while until patched or updated (or 
forever). That will require both forcing those ports to find an alternate 
openssl installation, and also (the tricky part) forcing them to ignore the 
openssl in the default prefix.

To support this, there is a new openssl11 port that provides openssl 1.1.1 
tucked away in a subdir, much like we have openssl10, and a few new options 
were added to the old_openssl PortGroup to allow most ports to be forced to the 
alternate openssl with minimal fuss. Add the PortGroup, spec the branch, and 
choose the method, for the most part.

If this plan holds, I would anticipate that we move ports that we find need to 
stay on openssl 1.1.1 to openssl11 using the old_openssl PortGroup soon or now, 
before we upgrade to openssl 3.0.0 to minimize fuss. Then once we have done 
that, upgrading the default openssl to 3.0.0 and revbumping the deps would 
occur.

So I am asking that anyone with an interest in a port that uses openssl please 
try building it against openssl 3.0.0 in the PR below, and if there is a 
problem that can’t be solved by an update or a patch, consider trying to use 
the old_openssl PortGroup to fix the build and move it over. As there are so 
many ports, it would help if people pitched in with the ones that are important 
to them.

The openssl 3.0.0 upgrade PR is here:

https://github.com/macports/macports-ports/pull/12410 
<https://github.com/macports/macports-ports/pull/12410>

and my own WIP repo of a few ports that I have found won’t build with openssl 
3.0.0 at present and fixed to use the old_openssl PG is here:

https://github.com/kencu/mybigsuroverlay/ 
<https://github.com/kencu/mybigsuroverlay/>

the idea is that the ports in that repo would be moved into the main repo as we 
work through the main ones that use openssl at least.


K

PS. One thing I have not yet sorted out how to do is how to support libressl in 
the setting of needing to force a port to openssl 1.1.1 using the old_openssl 
PortGroup. Open to any thoughts on this. This case wsa basically just ignored 
last time with openssl10, and we may have to do the same again unless someone 
has a bright idea.