This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "IPFire 2.x development tree".
The branch, next has been updated via 50771922cb4ed29804e19a8080ebcec15593ea83 (commit) from 417263c76c0d428398ee6188c22cee4bce035c87 (commit)
Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below.
- Log ----------------------------------------------------------------- commit 50771922cb4ed29804e19a8080ebcec15593ea83 Author: Michael Tremer michael.tremer@ipfire.org Date: Wed Aug 2 09:52:02 2023 +0000
openssl: Update to 3.1.2
* Fix excessive time spent checking DH q parameter value.
The function DH_check() performs various checks on DH parameters. After fixing CVE-2023-3446 it was discovered that a large q parameter value can also trigger an overly long computation during some of these checks. A correct q value, if present, cannot be larger than the modulus p parameter, thus it is unnecessary to perform these checks if q is larger than p.
If DH_check() is called with such q parameter value, DH_CHECK_INVALID_Q_VALUE return flag is set and the computationally intensive checks are skipped.
([CVE-2023-3817])
*Tomáš Mráz*
* Fix DH_check() excessive time with over sized modulus.
The function DH_check() performs various checks on DH parameters. One of those checks confirms that the modulus ("p" parameter) is not too large. Trying to use a very large modulus is slow and OpenSSL will not normally use a modulus which is over 10,000 bits in length.
However the DH_check() function checks numerous aspects of the key or parameters that have been supplied. Some of those checks use the supplied modulus value even if it has already been found to be too large.
A new limit has been added to DH_check of 32,768 bits. Supplying a key/parameters with a modulus over this size will simply cause DH_check() to fail.
([CVE-2023-3446])
*Matt Caswell*
* Do not ignore empty associated data entries with AES-SIV.
The AES-SIV algorithm allows for authentication of multiple associated data entries along with the encryption. To authenticate empty data the application has to call `EVP_EncryptUpdate()` (or `EVP_CipherUpdate()`) with NULL pointer as the output buffer and 0 as the input buffer length. The AES-SIV implementation in OpenSSL just returns success for such call instead of performing the associated data authentication operation. The empty data thus will not be authenticated. ([CVE-2023-2975])
Thanks to Juerg Wullschleger (Google) for discovering the issue.
The fix changes the authentication tag value and the ciphertext for applications that use empty associated data entries with AES-SIV. To decrypt data encrypted with previous versions of OpenSSL the application has to skip calls to `EVP_DecryptUpdate()` for empty associated data entries.
*Tomáš Mráz*
* When building with the `enable-fips` option and using the resulting FIPS provider, TLS 1.2 will, by default, mandate the use of an extended master secret (FIPS 140-3 IG G.Q) and the Hash and HMAC DRBGs will not operate with truncated digests (FIPS 140-3 IG G.R).
*Paul Dale*
Signed-off-by: Michael Tremer michael.tremer@ipfire.org
-----------------------------------------------------------------------
Summary of changes: lfs/openssl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Difference in files: diff --git a/lfs/openssl b/lfs/openssl index 5b60c3369..7ac39cf0e 100644 --- a/lfs/openssl +++ b/lfs/openssl @@ -24,7 +24,7 @@
include Config
-VER = 3.1.1 +VER = 3.1.2
THISAPP = openssl-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -70,7 +70,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_BLAKE2 = 094f7e28f16de6528016fcd21df1d7382b0dbdcd80ec469d37add9c37f638c059dda3ffb4415eba890a33d146ddc9016bcc7192df101c73be5e70faf6e3b1097 +$(DL_FILE)_BLAKE2 = 7b4ba35df7d5680c5f13a1986e4c6abaf4592690647dcfa84d7f14c196326355e8ad0ea62f81f8269f0605f0d29f18e9def9c2158fcbe00baefabf819f82374d
install : $(TARGET)
hooks/post-receive -- IPFire 2.x development tree