Rebased to openssl-3.0.7 with corresponding minor bugfixes
- C99 compatibility in downstream-only 0032-Force-fips.patch
Resolves: rhbz#2152504
- Adjusting include for the FIPS_mode macro
Resolves: rhbz#2083876
Our backported patch unconditionally uses assembly instructions for
Power9 and later, which triggers SIGILL on Power8 machines:
| [ 3705.137658] sshd[1703]: illegal instruction (4) at 7fff85526aac nip 7fff85526aac lr 7fff854828e0 code 1 in libcrypto.so.3.0.5[7fff85240000+300000]
Backport upstream's fix for this.
Resolves: rhbz#2124845
Signed-off-by: Clemens Lang <cllang@redhat.com>
Fedora supports TLS down to 1.0 in LEGACY crypto-policy, but TLS 1.0
defaults to rsa_pkcs1_md5_sha1 with RSA certificates by default.
However, MD5-SHA1 would require SECLEVEL=0, because its 67 bits of
security do not meet SECLEVEL=1's requirement of 80 bits.
Instead of setting SECLEVEL to 0 in the LEGACY crypto-policy (which
would include all algorithms, regardless of their security level), allow
MD5-SHA1 if rh-allow-sha1-signatures is yes and SECLEVEL is 1.
Related: rhbz#2069239
ELN should ideally be ahead of CentOS and RHEL with policy changes, but
due to time constraints was not. Fix that by bringing the current CentOS
9 / RHEL 9 state of SHA-1 disabling to ELN.
Due to differences in their lifecycles, Fedora's packages will stay at
allowing SHA-1 by default for now. There is a plan to gradually catch up
to the ELN state over the next few releases.
Signed-off-by: Clemens Lang <cllang@redhat.com>
capi.so is only useful on Windows, it does not matter that it does not
have dependency information.
The invalid URL warnings are expected for packages with hobbled source
code archives.
We explicitly allow the use of SSL_CTX_set_cipher_list in the openssl(1)
binary.
Signed-off-by: Clemens Lang <cllang@redhat.com>
NOTE: This patch is ported from CentOS 9 / RHEL 9, where it defaults to
denying SHA1 signatures. On Fedora, the default is – for now – to allow
SHA1 signatures.
In order to phase out SHA1 signatures, introduce a new configuration
option in the alg_section named 'rh-allow-sha1-signatures'. This option
defaults to true. If set to false, any signature creation or
verification operations that involve SHA1 as digest will fail.
This also affects TLS, where the signature_algorithms extension of any
ClientHello message sent by OpenSSL will no longer include signatures
with the SHA1 digest if rh-allow-sha1-signatures is false. For servers
that request a client certificate, the same also applies for
CertificateRequest messages sent by them.
Resolves: rhbz#2070977
Related: rhbz#2031742, rhbz#2062640
Signed-off-by: Clemens Lang <cllang@redhat.com>
Also some small TLS protocol fixes/changes:
Disallow dropping Extended Master Secret extension on renegotiation
Return alert from s_server if ALPN protocol does not match
