Revisions of openssl-1_1
Ana Guerrero (anag+factory)
accepted
request 1146592
from
Factory Maintainer (factory-maintainer)
(revision 58)
Automatic submission by obs-autosubmit
Ana Guerrero (anag+factory)
accepted
request 1141238
from
Pedro Monreal Gonzalez (pmonrealgonzalez)
(revision 56)
Ana Guerrero (anag+factory)
accepted
request 1130033
from
Factory Maintainer (factory-maintainer)
(revision 55)
Automatic submission by obs-autosubmit
Ana Guerrero (anag+factory)
accepted
request 1126787
from
Otto Hollmann (ohollmann)
(revision 54)
- Security fix: [bsc#1216922, CVE-2023-5678] * Fix excessive time spent in DH check / generation with large Q parameter value. * Applications that use the functions DH_generate_key() to generate an X9.42 DH key may experience long delays. Likewise, applications that use DH_check_pub_key(), DH_check_pub_key_ex () or EVP_PKEY_public_check() to check an X9.42 DH key or X9.42 DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service. * Add openssl-CVE-2023-5678.patch - Remove trailing spaces from changelog - Remove a hack for bsc#936563 bsc936563_hack.patch (bsc#936563) - Build with no-ssl3, for details on why this is needed read require us to patch dependant packages as the relevant functions are still available (SSLv3_(client|server)_method) - openssl.keyring: use Matt Caswells current key. - openSSL 1.0.1j - openssl.keyring: the 1.0.1i release was done by - 012-Fix-eckey_priv_encode.patch eckey_priv_encode should - 0001-Axe-builtin-printf-implementation-use-glibc-instead.patch it is already in RPM_OPT_FLAGS and is replaced by - Remove the "gmp" and "capi" shared engines, nobody noticed but they are just dummies that do nothing. - Use enable-rfc3779 to allow projects such as rpki.net - openssl-buffreelistbug-aka-CVE-2010-5298.patch fix - openssl-gcc-attributes.patch: fix thinko, CRYPTO_realloc_clean does - openssl-gcc-attributes.patch
Ana Guerrero (anag+factory)
accepted
request 1111406
from
Pedro Monreal Gonzalez (pmonrealgonzalez)
(revision 51)
Dominique Leuenberger (dimstar_suse)
accepted
request 1101937
from
Pedro Monreal Gonzalez (pmonrealgonzalez)
(revision 50)
Ana Guerrero (anag+factory)
accepted
request 1099670
from
Pedro Monreal Gonzalez (pmonrealgonzalez)
(revision 49)
Dominique Leuenberger (dimstar_suse)
accepted
request 1095762
from
Dominique Leuenberger (dimstar_suse)
(revision 48)
Reintroduce change, sync with openssl 3.0
Dominique Leuenberger (dimstar_suse)
committed
(revision 47)
Revert; change needs to be synced with openssl 3.0 update
Dominique Leuenberger (dimstar_suse)
accepted
request 1095609
from
Otto Hollmann (ohollmann)
(revision 46)
- Improve cross-package provides/conflicts [boo#1210313] * Add Provides/Conflicts: ssl-devel * Remove explicit conflicts with other devel-libraries
Dominique Leuenberger (dimstar_suse)
accepted
request 1089973
from
Otto Hollmann (ohollmann)
(revision 45)
- Update to 1.1.1u: * Mitigate for the time it takes for `OBJ_obj2txt` to translate gigantic OBJECT IDENTIFIER sub-identifiers to canonical numeric text form. OBJ_obj2txt() would translate any size OBJECT IDENTIFIER to canonical numeric text form. For gigantic sub-identifiers, this would take a very long time, the time complexity being O(n^2) where n is the size of that sub-identifier. (CVE-2023-2650, bsc#1211430) To mitigitate this, `OBJ_obj2txt()` will only translate an OBJECT IDENTIFIER to canonical numeric text form if the size of that OBJECT IDENTIFIER is 586 bytes or less, and fail otherwise. The basis for this restriction is RFC 2578 (STD 58), section 3.5. OBJECT IDENTIFIER values, which stipulates that OBJECT IDENTIFIERS may have at most 128 sub-identifiers, and that the maximum value that each sub- identifier may have is 2^32-1 (4294967295 decimal). For each byte of every sub-identifier, only the 7 lower bits are part of the value, so the maximum amount of bytes that an OBJECT IDENTIFIER with these restrictions may occupy is 32 * 128 / 7, which is approximately 586 bytes. Ref: https://datatracker.ietf.org/doc/html/rfc2578#section-3.5 * Reworked the Fix for the Timing Oracle in RSA Decryption (CVE-2022-4304, bsc#1207534). The previous fix for this timing side channel turned out to cause a severe 2-3x performance regression in the typical use case compared to 1.1.1s. The new fix uses existing constant time code paths, and restores the previous performance level while fully eliminating all existing timing side channels. The fix was developed by Bernd Edlinger with testing support by Hubert Kario. * Corrected documentation of X509_VERIFY_PARAM_add0_policy() to mention that it does not enable policy checking. Thanks to David Benjamin for discovering this issue. (CVE-2023-0466, bsc#1209873) * Fixed an issue where invalid certificate policies in leaf certificates are
Dominique Leuenberger (dimstar_suse)
accepted
request 1077221
from
Otto Hollmann (ohollmann)
(revision 44)
- Security Fix: [CVE-2023-0465, bsc#1209878] * Invalid certificate policies in leaf certificates are silently ignored * Add openssl-CVE-2023-0465.patch - Security Fix: [CVE-2023-0466, bsc#1209873] * Certificate policy check not enabled * Add openssl-CVE-2023-0466.patch
Dominique Leuenberger (dimstar_suse)
accepted
request 1074722
from
Otto Hollmann (ohollmann)
(revision 43)
- Security Fix: [CVE-2023-0464, bsc#1209624] * Excessive Resource Usage Verifying X.509 Policy Constraints * Add openssl-CVE-2023-0464.patch
Dominique Leuenberger (dimstar_suse)
accepted
request 1063743
from
Otto Hollmann (ohollmann)
(revision 42)
- Update to 1.1.1t: * Fixed X.400 address type confusion in X.509 GeneralName. There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but subsequently interpreted by GENERAL_NAME_cmp as an ASN1_TYPE. This vulnerability may allow an attacker who can provide a certificate chain and CRL (neither of which need have a valid signature) to pass arbitrary pointers to a memcmp call, creating a possible read primitive, subject to some constraints. Refer to the advisory for more information. Thanks to David Benjamin for discovering this issue. [bsc#1207533, CVE-2023-0286] This issue has been fixed by changing the public header file definition of GENERAL_NAME so that x400Address reflects the implementation. It was not possible for any existing application to successfully use the existing definition; however, if any application references the x400Address field (e.g. in dead code), note that the type of this field has changed. There is no ABI change. * Fixed Use-after-free following BIO_new_NDEF. The public API function BIO_new_NDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by end user applications. The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the caller. Under certain conditions, for example if a CMS recipient public key is invalid, the new filter BIO is freed and the function returns a NULL result indicating a failure. However, in this case, the BIO chain is not properly cleaned up and the BIO passed by the caller still retains internal pointers to the previously freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO then a use-after-free will occur. This will most likely result in a crash.
Dominique Leuenberger (dimstar_suse)
accepted
request 1062225
from
Pedro Monreal Gonzalez (pmonrealgonzalez)
(revision 41)
Dominique Leuenberger (dimstar_suse)
accepted
request 1042988
from
Pedro Monreal Gonzalez (pmonrealgonzalez)
(revision 40)
Dominique Leuenberger (dimstar_suse)
accepted
request 1032895
from
Pedro Monreal Gonzalez (pmonrealgonzalez)
(revision 39)
Displaying revisions 1 - 20 of 58