Activate the default provider by default

[beldmit]

Currently installed openssl.cnf contain the following section:

openssl/apps/openssl.cnf

Lines 63 to 64 in 08e9ff7

	[default_sect]
	# activate = 1

If there are no other provider sections, we load and activate the default provider according to https://github.com/openssl/openssl/blame/3e3ad3c54855dd534437871a0c78858de5e3d246/README-PROVIDERS.md#L31-L35

Today I by accident and misunderstanding added the legacy section and didn't uncomment the activate=1 line. It caused impossibility to login into the machine via ssh, because only legacy algorithms persisted enabled.

Major Linux distributions can fix it via the downstream patch, but I'm afraid such defaults make the installation rather fragile.

[t184256]

Defaulting to "enabled if not other provider is enabled" makes it an unorthogonal and counterintuitive control. Enabling something else shouldn't disable what was already enabled and lock people out.

But I can't help but note this complexity suggests it was intentional. Could somebody please shed some light on the rationale behind this decision?

[t8m]

The rationale is: If you do not configure or explicitly load any provider, your openssl 3.0 installation should work out of the box - which means default provider is autoloaded. If you configure or explicitly load any provider, you know what you're doing and that you need to also load a default (or fips+base) provider(s) to have reasonably working installation.

Please do not expect this model to be changed at this point after the beta2 has been already released and the final release is imminent. If you had some concerns about this they should have been voiced much earlier. (I am sorry for sounding harsh a little bit, but this design part was there (almost?) from start).

[t8m]

I'd expect the distributions that want to ship a default configuration file which loads some providers to be able to properly enable/activate the default provider in the same configuration file.

[beldmit]

@t8m I clearly understand the rationale and my proposal is just a chance to avoid shooting in own leg by accident.

[t184256]

But I can't help but note this [defaulting to neither 0 nor 1] complexity suggests it was intentional. Could somebody please shed some light on the rationale behind this decision?

The rationale is: If you do not configure or explicitly load any provider, your openssl 3.0 installation should work out of the box - which means default provider is autoloaded.

There's more than one way to do it. Defaulting to having it enabled unless it's = 0'd explicitly would be simpler, yet a more complex default was selected, and I suspect I don't fully grasp why.

Alternatively, the complex behaviour on not having it specified can be preserved as is, but the default config can have an explicit = 1.

If you configure or explicitly load any provider, you know what you're doing and that you need to also load a default (or fips+base) provider(s) to have reasonably working installation.

Yes, but non-orthogonal control doesn't exactly help achieve this.

Please do not expect this model to be changed at this point

Could you please clarify, what exactly you don't envision changing that late in the cycle: the behaviour on unspecified value, the = 1 in the vanilla config being commented out or both?

... after the beta2 has been already released and the final release is imminent. If you had some concerns about this they should have been voiced much earlier. (I am sorry for sounding harsh a little bit, but this design part was there (almost?) from start).

Nah, that's, indeed, a request that would ideally come a couple of years earlier =)

[mattcaswell]

OTC: This should be handled by adding additional comments to the default config file.

[mattcaswell]

There's more than one way to do it. Defaulting to having it enabled unless it's = 0'd explicitly would be simpler, yet a more complex default was selected, and I suspect I don't fully grasp why.

We are aiming for backwards compatibility. Providers are a new concept in 3.0. We want it to work out-of-the-box for as many applications as possible. Even for applications that have no knowledge of providers. Therefore if you haven't explicitly configured any providers then we assume its because the application/configuration was inherited from 1.1.1 and should (as much as possible) "just work".

OTOH, if you explicitly load providers then we don't want "extra" providers beyond those you have explicitly configured being available. This is particularly important with (say) the fips provider, where in many situations you really do not want any other provider to be available. Therefore we made the decision that if you really want the default provider in addition to other providers then you must explicitly configure it.

[t184256]

Thank you for the clarifications, this makes much more sense to me now.