usage of SHA-1
(1) By Ondrej Dubaj (odubaj) on 2021-04-14 11:44:58 [source]
Hello, I would like to ask about the implementation and usage of SHA-1 algorithm. Currently in RHEL-9, usage or implementation of SHA-1 will be deprecated. Is there a way to disable usage of the SHA-1 implementations? More info about the official analysis about the context here: The use of SHA-1 in RHEL9 is deprecated. This package has been found to implement and/or use SHA-1. If possible, please attempt to resolve this issue before the RHEL-9 beta deadline. See below for details. The use of SHA-1 is no longer permitted for Digital Signatures or authentication. There are a few exceptions to this rule, such as for some legacy protocols. These restrictions are enforced by the system wide crypto policies in RHEL-9, provided the core set of validated crypto libraries such as openssl, nss or gnutls, are used. To avoid your package from breaking due to SHA-1 being disabled via the System Wide Crypto Policies, please ensure that the use of SHA-1 is disabled where-ever possible. If this is not possible, please explain why this is the case. - If SHA-1 is used for Digital Signatures or authentication, where possible replace it with SHA-2. If this is not possible, please contact the rhel-crypto team. - If SHA-1 is used for signatures, ensure to only use it for signature validation. Prevent the code from generating new SHA-1 based signatures. - If SHA-1 is part of any default configuration list of hashing methods, please remove it from the default configuration list. Add SHA-2 if there would otherwise be no defaults left. - If SHA-1 is used for any other purpose, such as generating unique object IDs, switch to SHA-2 when possible. If this is not possible, attempt to limit the creation of further SHA-1 based identifiers and only use SHA-1 to consume existing object identifiers. This will make it easier to remove SHA-1 in the future. - If this package implements DNSSEC validation code, please ensure that a failure of SHA-1 results in "insecure DNS answers" and does not fail using ServFail. - If this package requires SHA-1 for Digital Signature verification, please create a documentation file (eg README-SHA1.md) with documentation to assist the rhel-crypto team in future reviews. For example, a mail program that wants to be able to validate emails sent 10 years would need to be able to keep using SHA-1 - If your package uses a protocol that dictates the use of SHA-1 for Signature validation or authentication, and there is no standarized alternative, please contact the rhel-crypto team for an exception. - Note that all of these recommendations for SHA-1 also apply to MD5. Feel free to apply the SHA-1 rules to any MD5 implementation or usage that is implemented or used as well. Package specific details: - Contains THREE(!) SHA-1 implementation, in mksourceid to checksum files, dbhash for database checksums, Thanks for your advice!
(2) By Warren Young (wyoung) on 2021-04-14 12:14:40 in reply to 1 [link] [source]
I would like to ask
As far as I can tell, you're making demands, not asking anything.
Maybe instead of sending around sternly-worded broad-based form letters, you could make an effort to try to understand the projects you're sending them to first and tailor the message accordingly?
Oh, and out of personal interest, would you mind linking us to the copy of this same form letter that your organization has presumably sent to the Git project? I really want to see the resulting firestorm from dropping this little bomblet on 'em.
To avoid your package from breaking due to SHA-1 being disabled...
This is what I'm getting at when I say you haven't done your homework before sending this message off.
Are you sitting down? If not, please do, because you need to let this command's output bake your noodle for a time before you reply:
$ sudo dnf remove sqlite-libs Error: Problem: The operation would result in removing the following protected packages: dnf
With the understanding resulting from this demonstration of the direction the dependency arrow actually points, would you perhaps reconsider coming across all strong-arm on this matter?
— Signed, a CentOS user who's taken a shot to the jewels from y'all once already this year and doesn't want another, thanks.
P.S. I support your desire to remove SHA-1 everywhere possible, but Red Hat needs to realize it's dependent on the FOSS software community to provide a large chunk of the software it makes those billions off. How about you dial that arrogance back a bit, 'kay?
(3) By Warren Young (wyoung) on 2021-04-14 13:14:05 in reply to 2 [link] [source]
The operation would result in removing the following protected packages: dnf
On further reflection, I've realized that the above command only reports a short-circuit failure case. While that single dependency problem may be enough reason in and of itself not to be making threats about removing SQLite from RHEL 9 if the SQLite project developers don't accede to IBM/Red Hat's demands, the actual situation is much more fraught.
On my CentOS 8 box, I get this result:
$ dnf repoquery -q --installed --whatrequires sqlite-libs --recursive | wc -l 130
(4) By anonymous on 2021-04-14 13:50:08 in reply to 3 [link] [source]
On my Fedora 33 installation, that query returns 499 packages. Notable examples include "gdb" and "python3"....
(5) By Ondrej Dubaj (odubaj) on 2021-04-14 13:59:47 in reply to 2 [link] [source]
Apologies, if you might think there is any arrogance in the message, sorry for that, it definitely wasn't meant that way. The reason I copy-pasted the message I received from our crypto team is to provide all of the information I have, as I couldn't linked the bugzilla issue, as it is private. If it was interpreted somehow badly, sorry for that. To the technical side, please let me try it more more time from the beginning. The aim of this thread is simple question. I just want to kindly ask sqlite maintainers, if there is any possibility of disabling the implementation or usage of SHA-1 algorithms. If yes, can you please share your knowledge? But if no, I appreciate it and it's up to me to explain and deal with it in RHEL. No other things are needed, I just wanted a short discussion about the possibilities, that's all. Thanks for understanding.
(6) By Richard Hipp (drh) on 2021-04-14 14:03:42 in reply to 1 [link] [source]
SHA1 is not required by SQLite. You can strip out the SHA1 code your scanner found if you want.
(7) By Ondrej Dubaj (odubaj) on 2021-04-14 14:14:56 in reply to 6 [link] [source]
Thank you for your quick response!
(8) By Ondrej Dubaj (odubaj) on 2021-04-19 08:15:24 in reply to 6 [link] [source]
Are there any plans to remove SHA-1 from sqlite in the future ? I can propose a patch if needed
(9) By ddevienne on 2021-04-19 08:59:29 in reply to 8 [link] [source]
You don't seem to get it. SHA-1 is part of the SQLite extensions,
to add additional functions and virtual tables on top of the SQLite core,
which anyone is free to add to their SQLite build or load as dynamic extensions.
In this case, it adds a function to compute SHA1 hashes. That's not bad
in and of itself, just as there's nothing wrong with computing a CRC32,
which is even more unsecure as SHA1...
How people use theses hashes is not SQLite's problem. Nor is SHA1 bad.
It's for what SHA1 hashes are used that matters. And SQLite doesn't use them.
SQLite also provides a SHA3 extension, right next to the SHA1 extension,
so no one is forced to use SHA1 either.
e.g. Fossil uses SHA3 now, used to use SHA1. But backward-compatibility
with older repos requires SHA1 support too, of course. So both are needed and useful.
Removing SHA1 from the SQLite repo would be a deservice to anyone that depends on it.
And is highly unlikely to be removed (I hope so at least).
(10) By Ondrej Dubaj (odubaj) on 2021-04-19 09:18:35 in reply to 9 [link] [source]
Understand, thank you for your quick response!
(11) By anonymous on 2021-07-09 16:26:02 in reply to 10 [link] [source]
thanks for working on cryptographic security in redhat/fedora!
but I'm not sure you actually understand what you're doing here. How does removing a hash function that is not used for any auth/signature purposes on its own increase security? Are you also removing libsd's
md5 routine? For what purpose?
Let's go through your list of "sensible exception reasons: "
- If SHA-1 is used for Digital Signatures or authentication
Not the case here. This is but a function that is available to users.
- If SHA-1 is used for signatures,
Not the case.
- If SHA-1 is part of any default configuration list of hashing methods,
Not the case.
- If SHA-1 is used for any other purpose, such as generating unique object IDs, switch to SHA-2 when possible. If this is not possible, attempt to limit the creation of further SHA-1 based identifiers and only use SHA-1 to consume existing object identifiers. This will make it easier to remove SHA-1 in the future.
Not possible, because this is a database system. The purpose of databases is to store data, permanently. So, there's already SHA-1 in such databases, and you removing the function to compute SHA-1 hashes doesn't change that; it only breaks existing software.
- If this package implements DNSSEC
Not the case
- If this package requires SHA-1 for Digital Signature verification,
Not the case
- If your package uses a protocol that dictates the use of SHA-1 for Signature validation or authentication
Not the case
I'd ask you to not remove functionality that your users (paying customers!) might be relying on from redhat/fedora because your scanner said there was a SHA-1 implementation. A SHA-1 implementation in itself isn't dangerous, it's using it for the wrong things that is dangerous.
(12) By Ondrej Dubaj (odubaj) on 2021-07-12 06:50:54 in reply to 11 [link] [source]
Thank you for your response and explanation. Due to this I am cancelling the proposed change in Fedora.