e23a6a Handle unsupported digests the same as disabled ones (RhBug:1652529)

1 file Authored by Panu Matilainen 4 years ago, Committed by Hunor Csomortáni 4 years ago,
1 file changed. 3 lines added. 0 lines removed.
    Handle unsupported digests the same as disabled ones (RhBug:1652529)
    
    A digest type unsupported by the underlying crypto library (whether
    technically or by configuration) does not mean the digest is invalid,
    it just cannot be used. Which for the purposes of verification is the
    same as if that digest didn't exist at all, and that's exactly how we
    handle digests and signatures disabled by configuration.
    
    One particular case is FIPS mode which globally disables the use of MD5,
    which we mishandled prior to this by showing it as OK in verification
    despite actually not verifying it at all.
    
    The exact place for handling this case is a bit subtle: the "obvious"
    place for checking for supported type is in rpmvsInitRange() but this
    doesn't work because of rpmDigestBundleAddID() return code semantics.
    The other "obvious" place would be rpmvsVerify(), but by that point
    we have even more funny cases to consider. So for now, it's actually
    easiest to check for this in rpmvsFiniRange() even if it's not the
    most obvious place for doing so. Might want to change the
    rpmDigestBundleAddID() semantics later, but this makes for a nicer
    backport (we'll need this in 4.14.x too).
    
        
file modified
+3 -0