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: Portfile dependencies relying on specific variant Mugvagut7

[Frank Dean]

Ryan Schmidt  writes:

> On Oct 5, 2021, at 05:36, Frank Dean wrote:
>> 
>> I've submitted a pull request [1] for a new Portfile, `mod_tile`, but the
>> checks are failing because this port requires the `mapnik` port to be
>> installed with a non-default variant, `+postgis`.  Similarly, it requires the
>> `osm2pgsql` port to have been installed with `+lua`.
>> 
>> [1]: https://github.com/macports/macports-ports/pull/12391
>> 
>> I've specified the dependency with:
>> 
>>require_active_variants mapnik postgis
>> 
>> If the dependent ports have not already been installed with the correct
>> variant, simply performing a `port install` on `mod_tile` fails due to this
>> dependency check, unless the install command includes the variant specifiers.
>> 
>> 1.  How should I handle this so that the automated builds complete
>>successfully?
>
> There is no solution. MacPorts base does not have the ability to depend on a 
> variant of a port. (https://trac.macports.org/ticket/126)
>
>
>> 2.  How can I improve the user experience in the same scenario?
>
> The user experience is already as good as it can get, given how things 
> currently work in MacPorts.
>
> Ideally, ports should be designed so that they can depend on other ports 
> wholesale without regard for variants.
>
> For example, if osm2pgsql's lua support is something that other ports want to 
> depend on, then either osm2pgsql should be modified so that it provides lua 
> support unconditionally, or osm2pgsql's lua support should be broken out into 
> another port (perhaps a subport) perhaps called osm2pgsql-lua.

Thanks Ryan, I'll submit PR's for the other ports and follow up with their
maintainers.