Yes, hashes etc are not replicated to mirrors; I think this is partly to encourage people to download them from the ASF hardware. However a rogue mirror could still provide its own hashes.
But hashes from ASF hardware still only provide a basic download check; they don't provide authentication, because anyone can create a hash for any file. Of course, if you sign a hash with a GPG key, that would allow the user to authenticate the hash if they trust the key. AIUI that's basically what sigs are. On 26 January 2017 at 21:26, Owen O'Malley <omal...@apache.org> wrote: > Infra does filter filenames that match (*.sha256) from the mirror > replication, so it is possible > to use such names and have matching behavior: > > Compare mirror: http://apache.cs.utah.edu/orc/orc-1.2.3/ > Apache version: http://www-eu.apache.org/dist/orc/orc-1.2.3/ > > and you can see the sha256 files are dropped just like the *.asc files. > > .. Owen > > On Thu, Jan 26, 2017 at 12:01 PM, Christopher <ctubb...@apache.org> wrote: > >> To be clear, those "trusted signatures" should be using strong hash >> algorithms themselves. (As well as sufficiently long keys.) >> I raised the issue of weak hashes in GPG signatures for Maven projects at >> ASF with https://issues.apache.org/jira/browse/MPOM-118 , but non-Maven >> projects which manually sign releases should probably take care to ensure >> their signatures are adequate. I consider this a release-voting quality >> assurance step, and encourage projects to examine the signatures attached >> to their release candidates as part of their release process. >> >> On Thu, Jan 26, 2017 at 2:27 PM Ted Dunning <ted.dunn...@gmail.com> wrote: >> >> > SHA1 and MD5 have been individually compromised, but a combined hash has >> > not been. >> > >> > Regardless, Sebb's comment that hashes are worthless for authentication >> and >> > tamper-detection is spot-on. You have to look to trusted signatures for >> > that. >> > >> > >> > >> > On Thu, Jan 26, 2017 at 10:20 AM, Mike Lissner < >> > mliss...@michaeljaylissner.com> wrote: >> > >> > > I filed a bug about this already, but I've been directed to email here >> > > instead. The bug I filed is: >> > > https://issues.apache.org/jira/browse/INFRA-12626 >> > > >> > > Basically, on download pages we provide obsolete hashes for our >> downloads >> > > (MD5 and SHA1). These are meant, as I understand it, to serve two >> > purposes. >> > > First, they allow you to make sure that your download succeeded. >> Second, >> > > they allow you to ensure that your download wasn't tampered with. >> > > >> > > For the first purpose: Great. They work. For the second purpose, >> however, >> > > we need to move away from MD5 and SHA1 hashes, both of which can now be >> > > attacked with relatively modest hardware. >> > > >> > > Browsers are moving away from SHA1 at a very fast pace. See: >> > > >> > > https://security.googleblog.com/2014/09/gradually- >> sunsetting-sha-1.html >> > > >> > > And: >> > > >> > > https://blog.mozilla.org/security/2014/09/23/phasing- >> > > out-certificates-with-sha-1-based-signature-algorithms/ >> > > >> > > I don't know who's responsible for this, but my bug was closed because >> > it's >> > > not the infrastructure team, and so I'm trying here. >> > > >> > > I suggest we move to SHA2 hashes for all verification purposes. >> > > >> > > Thanks, >> > > >> > > Mike >> > > >> > >> -- >> Christopher >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
