[1.0 breaking change] - consolidate checksum options about createrepo_c HOT 12 OPEN

@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?

from createrepo_c.

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.

from createrepo_c.

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.

from createrepo_c.

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?

from createrepo_c.

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

from createrepo_c.

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?

from createrepo_c.

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.

from createrepo_c.

If it permits SHA-3 and the RPM+DNF infrastructure can handle it, then we could shift to that.

from createrepo_c.

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.

from createrepo_c.

@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?

from createrepo_c.

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

from createrepo_c.

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
  

from createrepo_c.