search

abrt / satyr

Automatic problem management with anonymous reports
GNU General Public License v2.0
19 stars 22 forks source link

Use GLib for computing SHA-1 digests #328

Closed mgrabovsky closed 3 years ago

mgrabovsky commented 3 years ago

In d5e2d95, we ported the generation of digests from a bundled library to Nettle. However, Red Hat security policies require that no package depend on Nettle directly. Since GLib provides functions to compute SHA-1 digests as well, we are migrating the code to use it as of now.

Related: https://bugzilla.redhat.com/show_bug.cgi?id=1956872

mzidek-gh commented 3 years ago

Same comment as in the libreport patch, let's stop using SHA-1 so some automatic tools do not bother us again for using older hash function (even if it does not really matter in this case), lets just switch to SHA-256.

t184256 commented 3 years ago

However, Red Hat security policies require that no package depend on Nettle directly. Since GLib provides functions to compute SHA-1 digests as well, we are migrating the code to use it as of now.

That also won't fly, sorry. Certified crypto library choice is gnutls, openssl, nss or libgcrypt.

(Why does glib even offer crypto hash functions?)

mgrabovsky commented 3 years ago

However, Red Hat security policies require that no package depend on Nettle directly. Since GLib provides functions to compute SHA-1 digests as well, we are migrating the code to use it as of now.

That also won't fly, sorry. Certified crypto library choice is gnutls, openssl, nss or libgcrypt.

(Why does glib even offer crypto hash functions?)

This is not crypto functionality so your point is moot.

t184256 commented 3 years ago

Oh. Yeah, if its not used for user data protection and no security properties depend on the hash strength, then it's not a problem. Maybe consider picking a decidedly non-crypto hash function to make it more clear?

mzidek-gh commented 3 years ago

I think from practical point of view using glib is a good choice as we already depend on it, so we do not pull new dependencies. We do not really care which algorithm is used to calculate the hash as it is only used to detect duplicate bugs and has no security implications. If there is a more suitable hash function in glib repertoire feel free to suggest one. I am dropping my requirement for changing the hash function to SHA-256 as I do not want to stale this review and the hash function choice can be made in later PR.

mzidek-gh commented 3 years ago

Let's drop the nettle for now and think about better hash function in later PR. ACK.

mgrabovsky commented 3 years ago

OK, I'll merge this now and we can discuss details later. Thanks for the review.

ernestask commented 2 years ago

However, Red Hat security policies require that no package depend on Nettle directly. Since GLib provides functions to compute SHA-1 digests as well, we are migrating the code to use it as of now.

That also won't fly, sorry. Certified crypto library choice is gnutls, openssl, nss or libgcrypt.

(Why does glib even offer crypto hash functions?)

Certified by whom? Sosedkin industries?

t184256 commented 2 years ago

:eyeroll: You wish. NIST FIPS certifications is what I had in mind when writing this. Guess a more correct RHEL term would be core crypto components.

While Fedora is not bound by FIPS certification requirements, it still should uphold at least the centralized configuration requirement codified in https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies. GnuTLS plays by this rules, nettle does not.