© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
79ea94a
(Get the code!)
> This indicates that you are breaking compatibility with certain configs that would work today with the 5.6 package, which is not acceptable in SRU.
> I would accept either a package which uses a maintainer script to comment out the unsupported ssl_engine option, or a package which patches the code to make references to ssl_engine non-fatal. But we can't regress working user configs in an SRU.
Thanks for the review, Steve.
Here is a further analysis of the current squid status regarding OpenSSL 3 support and the ssh_engine directive suport.
Since it is a bit long, I will start with a short version of it:
- jammy and kinetic carry different patches to support OpenSSL3;
- jammy already includes the regression (crashes) on the ssl_engine configuration directive, kinetic does not;
- commenting out the directive on upgrades would be an improvement when a user upgrades to jammy, but a regression within kinetic, but seems to be the right approach (do we need a kinetic SRU bug?);
- the issue in question is with squid-openssl (universe).
Long version (or skip to the last paragraph):
In squid 5.7 (the version in lunar, being MRE'd through this bug), the upstream
code at
https:/
a macro to check the OpenSSL version. When it is >= 3 (which is our case since
jammy), it throws an exception and squid halts execution with
exception location: support.cc(681) Initialize
FATAL: Bungled (null) line 3: sslproxy_cert_sign signTrusted all
And the following message is logged to syslog:
FATAL: bad configuration: Cannot use ssl_engine in Squid built with OpenSSL 3.0 or newer
In jammy, we carry a set of patches for OpenSSL 3 support which were submitted
(and later merged upstream). However, this patch set was a very early version
of what ended up being merged upstream.
The relevant bit here is in
https:/
where the patch drops the support for the ssl_engine configuration directive.
When starting squid with the directive present in squid's configuration file,
it halts with:
FATAL: Your OpenSSL has no SSL engine support
Therefore, for jammy, there is actually no regressoin regarding the ssl_engine
directive, but a slight change on how squid fails.
However, in kinetic, the patch set we carried in jammy, which was still being
discussed upstream, was dropped in favor of
https:/
which was proposed by Debian in
https:/
This patch does not change or add any macros or logic in src/ssl/support.cc,
maintaining the possibility of configuration files having the ssl_engine
directive (although with undefined behavior since OpenSSL 3 does not support)
the feature.
Hence, the proposed MREs would not introduce a regression in jammy, but would
do so for kinetic.
From a user perspective, upgrading to jammy __already__ introduces a
behaviour change for squid-openssl users who rely on the ssl_engine
directive.
Allowing the ssh_engine directive to be used at this point (in jammy), given it
is not supported by openssl 3, would mean moving backwards. Turning the
directive into a comment (when present) in a postinst script and documenting it
seems to be an improvement from what we already have.
For kinetic, commenting the directive out would introduce a regression, but is
still a better approach than allowing the unsupported openssl feature to be
used. Would we need an additional SRU bug in this case (kinetic)?
Finally, FWIW, all the regression cases discussed above are only related to the
squid-openssl package, which is in universe (I am not saying we should not
support this, just emphasizing the fact that the issue being discussed is not
related to main).
Now, should we move forward with commenting the directive approach? Do we need
another SRU bug for kinetic?