I don't see any reason not to only use SHA-256, and not SHA-512.
Note that we are required to not include SHA-1 checksums.
We are not required to generate new checksums for old versions that are still available for download.

New Policy from yesterday, not yet linked publicly:

TLDR;

The release distribution checksum policy requires new releases to use SHA-512 or SHA-256 and not SHA-1 for verification. Existing releases do not need to be changed. Releases still need to be signed via detached PGP signatures.

Details:

Recently, a successful penetration of SHA-1 was verified, and SHA-1 is no longer considered safe for crypto hashes 
https://www.pcworld.com/article/3173791/security/stop-using-sha1-it-s-now-completely-unsafe.html


[1] http://www.apache.org/legal/release-policy.html#release-announcements
[2] https://www.apache.org/dev/release-distribution#download-links
[3] https://www.apache.org/dev/release-distribution#sigs-and-sums


Announcements of Apache project releases must contain a link to the relevant
download page, which might be hosted on an Apache site or a third party site
such as github.com. [1]

All official releases must be uploaded to the official distribution channel,
www.apache.org/dist.

The download page must provide public download links where current official
source releases and accompanying cryptographic files may be obtained. [2]

The policy on release distribution has been changed to require SHA-512 or SHA-256
and disallow new artifacts to use SHA-1. [3]

Links to the download artifacts must support downloads from mirrors, e.g. via links to
dyn/closer. Links to metadata (SHA, ASC) must be from 
https://www.apache.org/dist/<project>/<release> and specifically not from 
dist.apache.org/repos/dist

MD5 is no longer considered useful and should not be used. SHA is required.
Similarly, SHA-1 is no longer considered useful and should not be used.
SHA-512 (preferred) or SHA-256 are required for new releases. Older releases
need not be updated, may continue unchanged, and might use MD5 or SHA-1.

Links to KEYS must be from https://www.apache.org/dist/<project>/ not release
specific.

Announcements that contain a link to the dyn/closer page alone will be
rejected by the moderators.

Announcements that contain a link to a web page that does not include a link
to a mirror to the artifact plus links to the signature and at least one sha
checksum will be rejected.

Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo

Sha256 backend and frontend support for rule updates is already in place with 3.4 branch and trunk in sa-update and the rule generation system/rules mirror.

This will be more for the actual upcoming 3.4.2 release and similar.

KAM

Note, I'm confirming the exact sha1 and sha256 behavior for rules updates.  We'll be creating both for at least the near future since we are cryptographically verifying updates anyway the sha-1 risk is infinitesimally low IMO.

(In reply to Kevin A. McGrail from comment #4)
> Note, I'm confirming the exact sha1 and sha256 behavior for rules updates. 
> We'll be creating both for at least the near future since we are
> cryptographically verifying updates anyway the sha-1 risk is infinitesimally
> low IMO.

I would suggest that (in new code) if both are available then both should be checked and should both verify the content. At some point in the future we can completely disable SHA-1 generation and verification.

Interesting suggestion.  

The sha-1 issue is going to require a policy exemption from ASF.  I think they will grant it since we are ALSO using crypto verification along with the sha1.

Otherwise we turn off rule generation for anything pre 3.4.2 and leave them on a static rule set with sha-1 available.

Just confirmed that code for the support to use sha256 by default for rule signatures and that sha1 is used as secondary if sha256 does not exist IS in 3.4 and trunk.

Rules updates will continue to create sha1 and sha256 signatures along with the cryptographic signature.

For 3.4.2 code release, we'll add a sha256 and/or sha512 signature per the new policy and NOT publish a sha1 signature.

dropping sha1 support for rule publication is not currently under consideration due to legacy installations but we will mention that it's a concern to upgrade to 3.4.2+ in the near future.

(In reply to Kevin A. McGrail from comment #7)
> Just confirmed that code for the support to use sha256 by default for rule
> signatures and that sha1 is used as secondary if sha256 does not exist IS in
> 3.4 and trunk.

Oh, good.

I'd suggest again: if both are present we should validate both. It sounds like that would be a minor code change.

It's been my position for about 20 years now that a lot of the panic over hash attacks could have been minimized by using multiple hash algorithms for validation.

(In reply to John Hardin from comment #8)
> (In reply to Kevin A. McGrail from comment #7)
> > Just confirmed that code for the support to use sha256 by default for rule
> > signatures and that sha1 is used as secondary if sha256 does not exist IS in
> > 3.4 and trunk.
> 
> Oh, good.
> 
> I'd suggest again: if both are present we should validate both. It sounds
> like that would be a minor code change.

Not at all. It would be a non-change. It's how the code was designed from the start.

(In reply to Bill Cole from comment #9)
> (In reply to John Hardin from comment #8)
> > (In reply to Kevin A. McGrail from comment #7)
> > > Just confirmed that code for the support to use sha256 by default for rule
> > > signatures and that sha1 is used as secondary if sha256 does not exist IS in
> > > 3.4 and trunk.
> > 
> > Oh, good.
> > 
> > I'd suggest again: if both are present we should validate both. It sounds
> > like that would be a minor code change.
> 
> Not at all. It would be a non-change. It's how the code was designed from
> the start.

OK, good. I didn't actually look a the code, I was interpreting "if sha256 does not exist" as "fallback", not "as well".

(In reply to Kevin A. McGrail from comment #2)
> New Policy from yesterday, not yet linked publicly:
> 

> Details:
> 
> Recently, a successful penetration of SHA-1 was verified, and SHA-1 is no
> longer considered safe for crypto hashes 

This is an exaggeration, Google demonstrated a successful collision attack.

A collision attack against a release would require that both the legitimate tarball and the fake be created together, so only one of you lot could pull it off. And you'd need hardware that's orders of magnitude faster than Google's to avoid some very suspicious behaviour.

(In reply to RW from comment #11)
> (In reply to Kevin A. McGrail from comment #2)
> > New Policy from yesterday, not yet linked publicly:
> > 
> 
> > Details:
> > 
> > Recently, a successful penetration of SHA-1 was verified, and SHA-1 is no
> > longer considered safe for crypto hashes 
> 
> This is an exaggeration, Google demonstrated a successful collision attack.
> 
> A collision attack against a release would require that both the legitimate
> tarball and the fake be created together, so only one of you lot could pull
> it off. And you'd need hardware that's orders of magnitude faster than
> Google's to avoid some very suspicious behaviour.

Bill, I did not write that policy. I am relaying it.

The SA project is superbly protected anyway because we ALSO cryptographically sign our releases as well.  So there is not huge urgency to switch to sha-256+ but we should move forward with the policy that sha1 is becoming less safe to rely on.

Bug 7609 to publish rules with SHA512 and to check SHA1/256/512 if available in sa-update

3.4:
Committed revision 1839834.
Committed revision 1839835.

Trunk:
At revision 1839836.