Revisions of openssl-1_1

Ana Guerrero's avatar Ana Guerrero (anag+factory) accepted request 1146592 from Factory Maintainer's avatar Factory Maintainer (factory-maintainer) (revision 58)
Automatic submission by obs-autosubmit
Ana Guerrero's avatar Ana Guerrero (anag+factory) accepted request 1130033 from Factory Maintainer's avatar Factory Maintainer (factory-maintainer) (revision 55)
Automatic submission by obs-autosubmit
Ana Guerrero's avatar Ana Guerrero (anag+factory) accepted request 1126787 from Otto Hollmann's avatar 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
Dominique Leuenberger's avatar Dominique Leuenberger (dimstar_suse) accepted request 1095762 from Dominique Leuenberger's avatar Dominique Leuenberger (dimstar_suse) (revision 48)
Reintroduce change, sync with openssl 3.0
Dominique Leuenberger's avatar Dominique Leuenberger (dimstar_suse) committed (revision 47)
Revert; change needs to be synced with openssl 3.0 update
Dominique Leuenberger's avatar Dominique Leuenberger (dimstar_suse) accepted request 1095609 from Otto Hollmann's avatar 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's avatar Dominique Leuenberger (dimstar_suse) accepted request 1089973 from Otto Hollmann's avatar 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's avatar Dominique Leuenberger (dimstar_suse) accepted request 1077221 from Otto Hollmann's avatar 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's avatar Dominique Leuenberger (dimstar_suse) accepted request 1074722 from Otto Hollmann's avatar 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's avatar Dominique Leuenberger (dimstar_suse) accepted request 1063743 from Otto Hollmann's avatar 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.
Displaying revisions 1 - 20 of 58
openSUSE Build Service is sponsored by