Maybe /usr location is better. As those snippets should not need to be user editable.
Similarly we could ship "openssl-enable-tls1.0" snippet. Somehow users find it easy to install/remove packages to enable/disable configuration. On Thu, 16 Jul 2020, 03:57 Dimitri John Ledkov, <x...@ubuntu.com> wrote: > > > On Tue, 14 Jul 2020, 21:37 Kurt Roeckx, <k...@roeckx.be> wrote: > >> On Tue, Jul 14, 2020 at 06:22:50PM +0100, Dimitri John Ledkov wrote: >> > Package: libssl3 >> > Version: 3.0.0~~alpha4-1 >> > Severity: important >> > >> > Dear Maintainer, >> > >> > Please stop building legacy provider. None of the algorithms it >> > provides are useful, or needed at all. >> > >> > Please do not not build it nor ship it. Those who need to access that, >> > can self build that code. >> > >> > Alternatively you may choose to provide legacy provider in a separate >> > binary package, but imho it must not enter testing or stable releases. >> >> Applications that want to use the legacy provider will need to >> get changed to load them. By default the algorithms will not be >> available. >> >> I'm not sure that not shipping the file improves anything. >> > > To make installing them, automatically opt into using them by loading them > into default context with config files without changing applications. > > openssl package could ship `.include /etc/ssl/providers.d/` in ssl.conf. > > then libssl3-legacy and libssl3-fips could ship snippets in > /etc/ssl/providers.d/*.conf, that upon installation load those providers > system wide, in the default context. > > Without changing applications, a simple purge/install of a package would > disable/enable a provider and "make things work" (i.e. fips only, or legacy > enabled, etc.). > > This would also open up to have GOST and SM9 providers. > > Regards, > > Dimitri. > >>
