On Fri, Jul 03, 2026 at 03:23:03PM +0200, Julian Andres Klode wrote: > On Thu, Jun 25, 2026 at 08:54:01PM +0200, Sebastian Andrzej Siewior wrote: > > Control: reassign -1 apt 3.0.3 > > > > On 2026-06-19 09:37:09 [+0200], Julian Andres Klode wrote: > > > This seems to be a bug in OpenSSL, and the proposed workaround is > > > wholly inappropriate. This also points out there is _another_ bug > > > somewhere, as we _should_ have raised this error _before_ we enter > > > the Read/Write functions. > > > > Moving back to apt after consulting with upstream, the details are in > > https://github.com/openssl/openssl/issues/31624 > > > > There is: > > | The correct fix is for the application (apt in this case), to do what > > | postgresql did, and call ERR_clear_error(), prior to a subsequent SSL > > | call. > > > > and > > That is not a fix and not acceptable. We must not ignore random > errors. I will not accept quick hacks that can fundamentally break > security. > > PostgreSQL's work around is a potential security issue and should > be treated as such. It is not acceptable in production code to silently > discard the error queue, errors need to be raised at the appropriate > point in time (or discarded - with safety checks - at the appropriate > point in time). > > We should treat this as a release critical bug in postgresql tbh. > > > > > | I want to add one nuance after checking the source code of 3.5: I'm not > > | convinced that upstream libssl 3.5.6 is the source of the stale > > | MD5/MD5-SHA1 error described here. In the code, the optional digest > > | fetch helper ssl_evp_md_fetch uses ERR_set_mark / ERR_pop_to_mark, and > > | the sigalg probing code is also protected. > > | > > | Apt source code also uses OpenSSL EVP digest code outside the TLS path, > > | including MD5 hashing, so there may be more than one possible source of > > | a stale FIPS/provider error before the later TLS I/O. > >  > > > Thanks! > > > > Sebastian > > Right so the error is that the context is not correctly cleared where > an optional MD5 operation failed. > > The fix for that is identifying the failing MD5 operation, asserting > that the error queue is empty before the call, and then discarding the > error generated by the call after it.
I can offer https://salsa.debian.org/apt-team/apt/-/merge_requests/590 There are some more bugs in methods/connect.cc, HandleError() where we only look at the top error in the stack rather than all errors. Not yet sure how to fix this. Posted about the general issue in https://blog.jak-linux.org/2026/07/03/openssl-pandemic/ -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
