createrepo_c
createrepo_c copied to clipboard
rpm-software-management
[1.0 breaking change] - consolidate checksum options
Remove externally (cli)-facing support for checksum types weaker than sha256. Probably we should continue being able to republish such repos, and thus shouldn't entirely remove support? At least from the Python API, we will still need to parse such repos, as users will be managing EL6 and EL7 repos (of which some use sha1 checksums) for a long time to come. Maybe md5 could be permanently ditched, though.
Even more aggressive suggestion - is there a strong need for --repomd-checksum to exist? It appears the original justification was "because Spacewalk allows it", but as a developer on the successor to Spacewalk, we don't have this requirement nor do I really see the purpose.
I would be OK with its removal.
@kontura I know you didn't want to go quite this far but I thought there was going to be some functionality deprecated with warnings?
Unfortunately I didn't find the time to do any additional work on createrepo_c and we needed to get the other changes released at least a bit in advance in case there are some problems.
Therefore this was postponed.
We should still be able to use sha1 for people who need to (re)publish repos for systems that don't support it. RHEL 5 and older can't handle SHA256.
We should still be able to use sha1 for people who need to (re)publish repos for systems that don't support it. RHEL 5 and older can't handle SHA256.
To be clear I'm not suggesting that we remove support for parsing them, we could even probably make --update continue to work.
But also the current idea was just to deprecate them with warnings, and remove them in some future version probably at least 2 years away. So even if support was removed entirely, it kinda feels like a reasonable cutoff given we're talking about EL5?
Separate topic: while there isn't anything technically "wrong" with sha384 and sha512, nobody really uses them. I don't know that we would want to remove them any time soon (since in case sha256 is ever broken, a fallback is needed), but I don't suppose we could discourage them for current use in favor of adopting sha3 or blake3 (which obviously would require some additional ecosystem work to widely support)?
Maybe we should upgrade the default hashes for 1.0? We already use SHA-512 in a bunch of other places for similar reasons. Can we use SHA3 or BLAKE3 with FIPS?
Well, technically 1.0 is already out, as of the other week... I'd rather not see sha512 be the default purely on the basis of being twice as long without any structural benefits over sha256 otherwise. Especially now that "filelists_ext" with checksums exists.
I believe FIPS permits SHA-3. I don't think any members of the BLAKE family are on the list, though, or SHA-3 derivatives like K12. Which is a bit of a shame.
If it permits SHA-3 and the RPM+DNF infrastructure can handle it, then we could shift to that.
and the RPM+DNF infrastructure can handle it
I haven't checked but I don't think it does, support would need to be added.
edit: nope, not supported. https://github.com/openSUSE/libsolv/blob/86717630b78f015ed3e0d41aa299cdde532b9c6f/src/chksum.c#L122-L139
I just think it's probably a good time to start thinking about that future, anyway.
My only gripe with SHA-3 is that it was massively overbuilt and is therefore pretty slow compared to everything else, without hardware acceleration, which we probably won't see for 15 years.
But it's in FIPS so we probably ought to support it whether or not we also consider BLAKE3.
@DemiMarie, what do you think about the above discussion? Would it be worthwhile to start thinking about adopting SHA-3 and/or BLAKE(3|2b|2s) as an alternate checksum type for metadata (createrepo_c & libsolv & dnf) and possibly RPMs?
@dralley Security-wise, SHA3 and Blake2b are equivalent to SHA-512, and Blake3 and Blake2s are equivalent to SHA-256. Blake3 has some performance advantage but I am not sure if that matters for your use-case.
sha1:
-
https://releases.jfrog.io/artifactory/artifactory-pro-rpms/repodata/repomd.xml -
https://packages.gitlab.com/runner/gitlab-runner/el/9/x86_64/repodata/repomd.xml -
https://rpm.releases.hashicorp.com/RHEL/9/x86_64/stable/repodata/repomd.xml -
https://yum.puppetlabs.com/puppet/el/9/x86_64/repodata/repomd.xml
