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?

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

On my Fedora 33 installation, that query returns 499 packages. Notable examples include "gdb" and "python3"....

SHA1 is not required by SQLite. You can strip out the SHA1 code your scanner found if you want.

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).

Ondrej,

thanks for working on cryptographic security in redhat/fedora!

You made

https://fedoraproject.org/wiki/Changes/Sqlite_SHA-1

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.

Thank you for your response and explanation. Due to this I am cancelling the proposed change in Fedora.

Regards, Ondrej