[Pkg-openssl-devel] Bug#918727: Bug#918727: Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0

[Sebastian Andrzej Siewior]

On 2020-04-21 21:39:43 [+0200], Kurt Roeckx wrote:
> On Tue, Apr 21, 2020 at 09:18:05PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2020-04-15 13:38:23 [+0200], Kurt Roeckx wrote:
> > > On Wed, Apr 15, 2020 at 12:19:24PM +0100, Simon McVittie wrote:
> > > > 
> > > > I think setting defaults in the shared library itself would be more
> > > > robust, and if a configuration file to override that is necessary,
> > > 
> > > This is also the route that Ubuntu took, because it's possible to
> > > install the library without the openssl package. I think we should
> > > do this too.
> > > 
> > > It causes various issues with the test suite because SHA1 is used
> > > for various tests. But I think that has been fixed in master, or has a
> > > pull request.
> > > 
> > > I would like to drop SHA1 support in testing/unstable anyway, so I
> > > think we should merge those patches once they've all been merged.
> > 
> > Ehm. I read this a few times but I have no idea what we are going to do.
> > Could you please enlighten me?
> 
> It's about building with -DOPENSSL_TLS_SECURITY_LEVEL=2, and
> something like the patch I've used before to set the default TLS
> version, instead of having both in openssl.cfg. Setting it in the
> config file should override the build time defaults.

So if this replaces the entry openssl.cnf file then it would get rid of
that incompatible part. However if someone downgrades it for some reason
(by editing the file) then we are back to the incompatibility part where
things break if the syntax changes.

> Building with that set will cause testsuite errors. Some of those
> are because SHA1 is being used.

Yes. I suggested once to ship that .cnf file as part of libssl but you
didn't like the  idea, dunno why. But I know that you said that openssl
is almost always installed due to ca-cert and so on so…

> In the master branch, things are changing so that SHA1 isn't
> allowed at security level 1 anymore. For the next release, if
> we're not shipping 3.0, I would like to at least change that.

No SHA1 at level1? Lovely. You remember this one CDN that signed the
key-exchange with SHA1 despite the fact that the client did not offer
it? I just checked it, it is still doing it. And ssllabs.com does not
report this "bug" as such. I hope the web browsers have SHA1 also on
their agande because otherwise…

> Kurt

Sebastian