On 2026-11-07 20:41:31 [-0300], Daniel Ramos wrote:
> Hello Sebastian,
Hi Daniel,
> thank you, the debdiff against 3.6.5-1 is attached.
>
> It does three things:
> 1. A Debian patch appends `.include /etc/ssl/openssl.cnf.d` to
> apps/openssl.cnf, with a comment for whoever writes a snippet.
> 2. debian/openssl.dirs ships /etc/ssl/openssl.cnf.d empty.
> 3. A new autopkgtest, drop-in-directory, puts a snippet there that activates
> the legacy provider, checks that MD4 and SHA-256 work, then removes it and
> checks that legacy is gone.
>
> What I measured in a testing container, on 3.6.5-1 and on the built 3.6.5-2:
> - An empty or a missing directory changes nothing, so the copy of openssl.cnf
> in libcrypto3-udeb is safe.
> - A snippet with `legacy = legacy_sect` in [provider_sect] and `activate = 1`
> in [default_sect] gives both providers.
> - A snippet that activates legacy alone drops the default provider, which is
> why the comment asks for `activate = 1` in [default_sect].
> - A snippet that cannot be parsed makes OpenSSL ignore the whole
> configuration, as a broken openssl.cnf does today.
> - OpenSSL reads the directory in readdir order (OPENSSL_DIR_read in
> crypto/conf/conf_def.c), so the comment asks snippets not to set the same
> name.
> - The package builds and its test suite passes (4980 tests).
> - The new test script, run as root, fails on 3.6.5-1 with the directory made
> by hand and passes after upgrading to 3.6.5-2; the unmodified conffile is
> replaced on upgrade.
>
> Fedora ships the same idea as /etc/pki/tls/openssl.d (its openssl.spec
> creates it and lists it as %dir).
> If you prefer another name or another place for the include, I will change it.
I kept it as-is, doesn't look that bad. Could you forward that upstream?
It looks usefull and I don't think it needs to be limited to Debian.
I picked it for the unstable branch.
https://salsa.debian.org/debian/openssl/-/jobs/10615896
> Daniel
Sebastian
