Recently the news was released by the developers of the Fedora project and it is that they made known a plan to disable support for SHA-1 digital signatures for the release of "Fedora Linux 39".
It is mentioned that the plan to disable signatures implies eliminating trust in signatures that use SHA-1 hashes (SHA-224 will be declared as the minimum allowed in digital signatures), but keeping support for HMAC with SHA-1 and providing the ability to enable the LEGACY profile with SHA-1.
The main reason why the Fedora developers have come to this conclusion is that the end of support for SHA-1 based signatures is due to an increase in the efficiency of collision attacks with a given prefix (the cost of choosing a collision is estimated at several tens of thousands of dollars). In addition to browsers, certificates authenticated using the SHA-1 algorithm have been marked as not secure since mid-2016.
The main change this time will be to distrust SHA-1 signatures.
at the cryptographic library level, affecting more than just TLS.OpenSSL will start blocking the creation and verification of signatures by default,
with the anticipated precipitation that will be ample enough
for us to implement the change through multiple cycles
with multiple notices
to give developers and maintainers enough time to react.
It is worth mentioning that after applying the described changes, the OpenSSL library will by default block the generation and verification of signatures with SHA-1.
Deactivation is planned to be carried out in several stages, as in Fedora Linux 36 and 37 releases, SHA-1 based signatures will be removed from the "FUTURE" policy, plus I plan to provide a test policy TEST-FEDORA39 to disable SHA-1 on user request (update -crypto-policies –set TEST-FEDORA39), when creating and verifying SHA-1 based signatures, warnings will be displayed in the log.
For Fedora 39, the policies will be, in TLS perspective:
LEGACY
MAC: all HMACs with SHA1 or higher + all modern MACs (Poly1305, etc.)
Curves: all primes >= 255 bits (including Bernstein curves)
Signature algorithms: SHA-1 hash or better (no DSA)
Ciphers: all available > 112-bit key, >= 128-bit block (no RC4 or 3DES)
Key exchange: ECDHE, RSA, DHE (without DHE-DSS)
DH parameter size: >=2048
RSA Parameter Size: >=2048
TLS protocols: TLS >= 1.2
After that, during the pre-beta release of Fedora Linux 38, the repository will have a policy against SHA-1 signatures, but this change will not apply to the beta and release of Fedora Linux 38. With the release of Fedora Linux 39, the SHA-1 signature deprecation policy will be applied by default.
The proposed plan has not yet been reviewed by FESCo (Fedora Engineering Steering Committee), which is responsible for the technical part of the development of the Fedora distribution.
Moreover, It is also worth adding that in Red Hat has been warned about the end of support for the GTK 2 library, starting with the next branch of Red Hat Enterprise Linux.
The gtk2 package will not be included in the RHEL 10 release, which will only support GTK 3 and GTK 4. GTK 2 was removed due to the deprecation of the toolset and lack of support for modern technologies like Wayland, HiDPI, and HDR.
The toolkit served us gratefully, but it's beginning to show its age in regards to modern technologies like Wayland, HiDPI displays, HDR, and others.
Programs that remain bound to GTK 2, such as GIMP and Ardour, are expected to have time to migrate to new GTK branches before 2025, which is expected to release RHEL 10. In Ubuntu 22.04, 504 packages use libgtk2 as a dependency.
The reason for mentioning this is that such a change also ends up being implemented in some of the next versions of Fedora.
Finally if you are interested in knowing more about it about the list of changes that are planned on the disabling of signatures, you can consult the details in the following link