rpms/squid
7
0
Fork 0
Code Issues Pull Requests Releases Activity

Resolves: RHEL-107994 - squid does not work with post-quantum crypto

Browse Source 
- update the patch to match upstream changes
This commit is contained in:
Luboš Uhliarik 2025-09-24 10:17:43 +02:00
parent a376c7bce3
commit 00d5540e37
2 changed files with 39 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
squid-6.10-provider-keys-digest.patch
View File

@ -1,36 +1,59 @@
diff --git a/src/ssl/gadgets.cc b/src/ssl/gadgets.cc
index 09bad6d..59171b7 100644
index 1f8ac9d..3f54e3d 100644
--- a/src/ssl/gadgets.cc
+++ b/src/ssl/gadgets.cc
@@ -15,6 +15,19 @@
@@ -13,6 +13,42 @@
#include "security/Io.h"
#include "ssl/gadgets.h"
+/// whether the given key requires a digest when signing
+/// whether to supply a digest algorithm name when calling X509_sign() with the given key
+static bool
+keyNeedsDigest(const EVP_PKEY * const pkey) {
+ if (EVP_PKEY_is_a(pkey, "ML-DSA-44") ||
+ EVP_PKEY_is_a(pkey, "ML-DSA-65") ||
+ EVP_PKEY_is_a(pkey, "ML-DSA-87") ||
+ EVP_PKEY_is_a(pkey, "ED25519") ||
+ EVP_PKEY_is_a(pkey, "ED448"))
+ return false; // no digest needed
+signWithDigest(const Security::PrivateKeyPointer &key) {
+ Assure(key); // TODO: Add and use Security::PrivateKey (here and in caller).
+ const auto pkey = key.get();
+
+ return true; // require a digest for all other types
+ // OpenSSL does not define a maximum name size, but does terminate longer
+ // names without returning an error to the caller. Many similar callers in
+ // OpenSSL sources use 80-byte buffers.
+ char defaultDigestName[80] = "";
+ const auto nameGetterResult = EVP_PKEY_get_default_digest_name(pkey, defaultDigestName, sizeof(defaultDigestName));
+ debugs(83, 3, "nameGetterResult=" << nameGetterResult << " defaultDigestName=" << defaultDigestName);
+ if (nameGetterResult <= 0) {
+ debugs(83, 3, "ERROR: EVP_PKEY_get_default_digest_name() failure: " << Ssl::ReportAndForgetErrors);
+ // Backward compatibility: On error, assume digest should be used.
+ // TODO: Return false for -2 nameGetterResult as it "indicates the
+ // operation is not supported by the public key algorithm"?
+ return true;
+ }
+
+ // The name "UNDEF" signifies that a digest must (for return value 2) or may
+ // (for return value 1) be left unspecified.
+ if (nameGetterResult == 2 && strcmp(defaultDigestName, "UNDEF") == 0)
+ return false;
+
+ // Defined mandatory algorithms and "may be left unspecified" cases mentioned above.
+ return true;
+}
+
+/// OpenSSL X509_sign() wrapper
+static auto
+Sign(Security::Certificate &cert, const Security::PrivateKeyPointer &key, const EVP_MD &availableDigest) {
+ const auto digestOrNil = signWithDigest(key) ? &availableDigest : nullptr;
+ return X509_sign(&cert, key.get(), digestOrNil);
+}
+
void
Ssl::ForgetErrors()
{
@@ -677,9 +690,9 @@ static bool generateFakeSslCertificate(Security::CertPointer & certToStore, Secu
@@ -618,9 +654,9 @@ static bool generateFakeSslCertificate(Security::CertPointer & certToStore, Secu
assert(hash);
/*Now sign the request */
if (properties.signAlgorithm != Ssl::algSignSelf && properties.signWithPkey.get())
- ret = X509_sign(cert.get(), properties.signWithPkey.get(), hash);
+ ret = X509_sign(cert.get(), properties.signWithPkey.get(), keyNeedsDigest(properties.signWithPkey.get()) ? hash : nullptr);
+ ret = Sign(*cert, properties.signWithPkey, *hash);
else //else sign with self key (self signed request)
- ret = X509_sign(cert.get(), pkey.get(), hash);
+ ret = X509_sign(cert.get(), pkey.get(), keyNeedsDigest(pkey.get()) ? hash : nullptr);
+ ret = Sign(*cert, pkey, *hash);
if (!ret)
return false;

4
squid.spec
View File

@ -2,7 +2,7 @@
Name: squid
Version: 6.10
Release: 7%{?dist}
Release: 8%{?dist}
Summary: The Squid proxy caching server
Epoch: 7
# See CREDITS for breakdown of non GPLv2+ code
@ -331,7 +331,7 @@ fi
%changelog
* Fri Sep 12 2025 Luboš Uhliarik <luhliari@redhat.com> - 7:6.10-7
* Fri Sep 12 2025 Luboš Uhliarik <luhliari@redhat.com> - 7:6.10-8
- Resolves: RHEL-107994 - squid does not work with post-quantum crypto
* Thu Apr 10 2025 Luboš Uhliarik <luhliari@redhat.com> - 7:6.10-6