[oi-dev] phasing out openssl 1.0.2 (mostly)

[Goetz T. Fischer]

On Sat, 24 Feb 2024 19:23:33 +0100, Marcel Telka wrote:
> Hi,
>
> On Sat, Feb 24, 2024 at 06:27:30PM +0100, Goetz T. Fischer wrote:
>> as you know there're still some packages in the repo that use openssl 1.0.2.
>> so
>> far this had the unpleasant implication that all new packages had to be
>> hardcoded to newer ssl versions one way or the other, because the
>> buildsystem's
>> ssl mediator had to remain at 1.0.
>
> Sorry, this is not true.

see ##1 below ...

> It is already the other way around because the default OpenSSL version
> in the build framework is 3.1:
>
> $ grep OPENSSL_DEFAULT make-rules/shared-macros.mk
> OPENSSL_DEFAULT = 3.1
> OPENSSL_VERSION ?= $(OPENSSL_DEFAULT)
> $
>
> So in other words when a component needs non-default OpenSSL then it
> needs to specify the desired version via the OPENSSL_VERSION macro in
> its Makefile.

which can be omitted if the desired version is the default 3.1 according to 
https://github.com/OpenIndiana/oi-userland/pull/16202#discussion_r1496941478

> And, in an ideal world this should be all that is needed re the OpenSSL
> support and versions for a component (see cryptography above for an
> example).

as we all know, the ideal case is not the case all the time. hence ...

>> i.e. only hardcoding the handful of packages which, for whatever reason,
>> still
>> need 1.0.2 and having the buildsystem's ssl mediator set to whatever is
>
> The openssl mediator (on build machine) is orthogonal to that. All
> components builds should produce same results with any openssl mediator
> setting.

... exactly that's what i wanted to "optimize out" so to speak.
my recent tries with userland showed that the mentioned shared macros are not 
enough to make the buildsystems of various programs recognize an ssl version, 
other than what the mediator is set to, as default. therefore having the 
mediator set to whatever is considered the default at the time would be the 
most efficient option, because it requires the least extra work for each 
package.

> Provided the OpenSSL support in a packaged component is done
> properly.

##1 that's the (potentially unnecessary) work i refered to.

> A package needing old(er) OpenSSL is not a problem

oh that depends on the package. having nginx still use 1.0.2 for example is not 
good for more than just one reason.

> Somebody just needs to
> sit down and do the work (and then create a PR). Things do not
> materialize from nowhere.

i never said they would.
in fact the reason why i brought this up is to end up with a priority list of 
packages that should be taken care of next. by myself and whoever else is 
interested.

> Please do not look at solaris-userland too much. We already diverged
> significantly so very often what you see in oi-userland or in
> solaris-userland makes no sense in the other project.

i'm aware but the example i mentioned in this case is a good example of what i 
meant.