Control: tags -1 confirmed

Hi Paul,

Thanks for the report!

On 21:47 Fri 24 Aug     , Paul Gevers wrote:
> Source: ganeti
> Version: 2.16.0~rc2-4
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: needs-update
> Control: affects -1 src:openssl
> Control: block 907015 by -1
> 
> Dear maintainers,
> 
> With a recent upload of openssl the autopkgtest of ganeti started to
> fail in testing. I copied the output below.
> 
> Of course, openssl shouldn't just break your autopkgtest (or even worse,
> your package), but the change in openssl was intended and your package
> needs to update to the new situation. If needed, please change the bug's
> severity.
> 
> If this is a real problem in your package (and not only in your
> autopkgtest), the right binary package(s) from openssl should really add
> a versioned Breaks on the unfixed version of (one of your) package(s),
> hence I added a blocking relation on the openssl bug that tracks that.
> Note: the Breaks is nice even if the issue is only in the autopkgtest as
> it helps the migration software to figure out the right versions to
> combine in the tests.
> 
> A quote from the openssl maintainer about the openssl update:
> "
> This is probably the result of the default openssl.cfg now having:
> [system_default_sect]
> MinProtocol = TLSv1.2
> CipherString = DEFAULT@SECLEVEL=2
> 
> Where the SECLEVEL 2 requires a 112 / 2048 bit security level.
> "

>From the test artifacts I can dig out the following interesting bit:

 code: CurlSSLCertProblem, explanation: could not load PEM client certificate, 
OpenSSL error error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak

which I now saw was also present in the excerpt you attached with the 
bug report.

So, it turns out ganeti's internal CA is using SHA1 to sign all 
generated certificates, which - by the looks of it - is not acceptable 
by OpenSSL 1.1.

I'll need some time to investigate and see how we should handle this.

Regards,
Apollon

Reply via email to