© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0f7b58d
(Get the code!)
This bug tracks the following MRE updates for the Squid package:
kinetic (22.10): Squid 5.7
jammy (22.04): Squid 5.7
This update includes bugfixes following the SRU policy exception defined at https:/
[Upstream changes]
http://
(kinetic: 5.6..5.7); (jammy: 5.2..5.7)
Major changes introduced in this release
- Upstream OpenSSL 3.0 support added for features that were already supported by squid. No new OpenSSL 3.0 feature support added at this time.
- Support for the libssl custom Engine feature for builds linked to OpenSSL 3.0 has been dropped. Therefore, the configuration directive ssl_engine is no longer supported for builds using OpenSSL >= 3.
Moreover, the following changes are worth mentioning for jammy, from the updates between 5.2 and 5.6:
- Fixed regression that made the default value for the esi_parser configuration directive behave differently from its documented behavior. It now correctly uses libxml2 if available and falls back to libexpat otherwise.
- Fixed unexpected dispatch of client CA certificates to https_port clients when OpenSSL SSL_MODE_
[Test Plan]
TODO: link the build log containing all tests being executed
TODO: All tests are passing during build time, as shown in the build log (builds would fail otherwise, see LP: #2004050).
TODO: add results of local autopkgtest run against all the new Squid versions being uploaded here
[Regression Potential]
Upstream tests are always executed during build-time. Failures would prevent builds from succeeding.
Squid does not have many reverse dependencies. However, any upgrade is a risk to introduce breakage to other packages. Whenever a regression occurs in autopkgtests, we will investigate and provide fixes.
The two changes worth mentioning here are the ones related to the configuration directives.
First, the ssl_engine directive is being dropped for builds linked with OpenSSL >= 3 (which is the case for both jammy and kinetic), meaning squid will fail to start for installations using that configuration directive. There is no current workaround for the issue, since squid does not provide support for OpenSSL >= 3 Providers yet.
We consider this __feature__ change to be worth in this particular case, since shipping the upstream version with declared OpenSSL 3 support will reduce the risks and uncertainty around the patches being carried to add OpenSSL 3 support. More upstream context on that particular change is available at https:/
Second, the default behavior for the esi_parser configuration directive is also changing. While this is a bug fix since documentation always described the behavior being set in this MRE, users may face issues in their workflows when libxml2 starts being used. This change only applies to the jammy MRE.
[Other Info]
No CVEs are being addressed this time. Therefore, this should go through the updates pockets.