Panu Matilainen <pmati...@redhat.com> writes: > On 11/1/21 14:07, Justus Winter wrote: >> Neal Gompa <ngomp...@gmail.com> writes: >> >>> On Thu, Oct 28, 2021 at 11:17 AM Justus Winter <jus...@sequoia-pgp.org> >>> wrote: >>>> >>>> Panu Matilainen <pmati...@redhat.com> writes: >>>> >>>>>> https://tests.sequoia-pgp.org/rpmsop.html#Detached_Sign-Verify_roundtrip_with_key__Bob___MD5 >>>>>> >>>>>> - accepts MD5 signatures !!! >>>>>> >>>>>> https://tests.sequoia-pgp.org/rpmsop.html#Signature_over_the_shattered_collision >>>>>> >>>>>> - accepts SHA1 signatures !!! >>>>> >>>>> Rpm needs to be able to work with content from the nineties, when MD5 >>>>> was still the hottest thing around, ditto with SHA1. >>>> >>>> Contemporary versions of RPM need to work with content from the >>>> nineties? I find that hard to believe. >>>> >>> >>> I still sometimes deal with RPMs created in the early 2000s, it's not >>> terribly hard to believe people wind up working with older stuff. Lots >>> of old Linux games were released as RPMs back in the 90s too. >> >> I see. But, that doesn't mean that the RPMs are signed, or that the >> signer's key is trusted by you, or that the signer's key uses a public >> key signing algorithm and key size that is still cryptographically >> relevant today. >> >> I'm of the firm belief that signatures with weak hash algorithms should >> be considered either bad or non-existent, and explicit override by the >> administrator should be necessary to override that. > > FWIW, non-existence is how rpm treats such things when encountered, such > as in FIPS mode. > >> >> In the pull request, Panu writes: >> >>> I'm saying that deciding what is an acceptable algorithm and what is >>> not, is a question that does not belong to rpm at all. It's a matter >>> of distro/system policies, including but not limited to FIPS >> >> I'm worried about that. First of all, considering signatures using MD5 >> or SHA1 bad is not a policy, that is baseline footgun protection. Any >> distro policy should be on top of that, i.e. a refinement. > > I'm not arguing that MD5 or SHA1 is a secure algorithm by now, it's just > that questions like "what is and what is not a secure algorithm" leads > into the kind of political crap that I simply refuse to touch in rpm. > > This is just a side-track of the agenda at hand, now can we please just > agree to disagree and move on.
Well, I need to get a feel of the status quo, and how receptive a community is with respect to changes and contributions before I start putting in considerable effort. >> Also, I don't quite understand how this policy is enabled or enforced. >> As far as I can see, you defer the decision on what algorithm is >> acceptable to the cryptographic backend. > > Yes. > >> First, RPM makes no effort to put either openssl nor gcrypt into FIPS >> mode, so it has to be a distro-wide or system wide configuration. > > It's not RPM's business to configure such a thing even if it could! It's > a system policy that somebody needs to set, and rpm will happily comply. > >> https://www.gnupg.org/documentation/manuals/gcrypt/Enabling-FIPS-mode.html >> https://wiki.openssl.org/index.php/FIPS_mode_set() >> >> System-wide FIPS mode is not enabled by default on Fedora 35 or Debian >> Bullseye. > > I've only been using FIPS mode as an example of a policy that does > enforce obsolete hashes not getting used. FIPS is a whole lot more > though, it's not something the average user will want to have enabled. > My point is that there are mechanisms to deal with this on central > level, and that's where it should be handled. If MD5 is considered > insecure then disable the damn thing in the crypto library, and rpm will > merrily comply. I am also using FIPS as a stand-in for any kind of policy, mostly because it is the only one I know that enjoys widespread support in software and I kind of know how to get the crypto libraries into that policy. >> Second, OpenPGP separates digest computation and signature verification >> into two steps. When RPM hands off the digest to the cryptographic >> library, then the library doesn't have enough context to understand >> which hash algorithm produced the digest (with the exception of RSA >> signature verification, where the hash algorithm is passed along with >> the digest). >> >> Therefore, whether a hash algorithm is accepted for signature >> verification comes down to whether it is produced by the backend or >> not. I wrote a small test program to explore this. >> >> This is the result on Fedora 35: >> >> [liveuser@localhost-live ~]$ ./fipstest >> gcrypt allows MD5 >> gcrypt allows SHA1 >> WARN: The current version of OpenSSL is not FIPS-capable. >> openssl has MD5 >> openssl has SHA1 >> openssl allows SHA1 >> [liveuser@localhost-live ~]$ ./fipstest enable fips mode please >> gcrypt allows MD5 >> gcrypt allows SHA1 >> WARN: The current version of OpenSSL is not FIPS-capable. >> openssl has MD5 >> openssl has SHA1 >> openssl allows SHA1 >> >> This is the result on Debian Bullseye: >> >> % ./fipstest >> gcrypt allows MD5 >> gcrypt allows SHA1 >> openssl has MD5 >> openssl allows MD5 >> openssl has SHA1 >> openssl allows SHA1 >> % ./fipstest fips mode please >> WARN: The current version of OpenSSL is not FIPS-capable. >> WARN: Failed to get openssl into FIPS mode >> gcrypt allows MD5 >> gcrypt allows SHA1 >> openssl has MD5 >> openssl allows MD5 >> openssl has SHA1 >> openssl allows SHA1 >> >> Some observations: >> >> - On both systems, FIPS mode has no influence on the availability of >> MD5 or SHA1 in gcrypt or openssl. > > I've no idea whether FIPS is supposed to work on either. I only know it > from RHEL business where eg on RHEL 8, both MD5 and SHA1 are disabled > entirely. Centos 8 is the closest I can get to RHEL 8 without considerable effort, and neither MD5 nor SHA1 are disabled there: $ ./fipstest gcrypt allows MD5 gcrypt allows SHA1 openssl has MD5 openssl allows MD5 openssl has SHA1 openssl allows SHA1 $ ./fipstest skdljhfgsfd WARN: The current version of OpenSSL is not FIPS-capable. gcrypt allows MD5 gcrypt allows SHA1 openssl has MD5 openssl has SHA1 openssl allows SHA1 $ cat /proc/sys/crypto/fips_enabled ; test -e /etc/gcrypt/fips_enabled ; echo "gcrypt override: $?" 0 gcrypt override: 1 So, it is not in FIPS mode by default, but even if I put gcrypt and openssl into FIPS mode, gcrypt still does MD5 and SHA1, and openssl does SHA1. >> - Fedora seems to have patched openssl to unconditionally disable MD5. >> >> - On Fedora, RPM links against openssl, on Debian against gcrypt. >> >> Based on these observations, I conclude that ---unless I missed a >> different mechanism that enforces a different policy--- >> >> - on Fedora, RPM accepts SHA1 signatures >> >> - on Debian, RPM accepts MD5 and SHA1 signatures >> >> independent of whether FIPS mode is enabled, and that applies both for >> signatures over data (i.e. RPM authentication) and binding signatures >> (i.e. OpenPGP certificate canonicalization). > > I'm blissfully unaware of the crypto configuration details of distros, > but if Fedora disables MD5 then that'd be a fine example of how I think > this all should work. Wiring these insecure algorithms time and time and > time and time and time after time into each individual program just > doesn't fly. But, not every individual program decides to incorporate an OpenPGP implementation. Most defer this kind of policy to some library that takes care of sunsetting insecure algorithms. Pointing to openssl or gcrypt doesn't really fly. gcrypt and openssl (at least the interface that RPM uses) are providing mechanisms without policy. You cannot simply drop SHA1, because unfortunately many things (like e.g. v4 OpenPGP Fingerprint computation, content addressable storage like git) depend on that. That doesn't mean that it is safe to use SHA1 to verify binary OpenPGP signatures. But, neither gcrypt nor openssl is in a position to make that distinction, because they are so low-level that they lack context. That context is the OpenPGP implementation. Justus
signature.asc
Description: PGP signature
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
