You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-issues@apache.org by "Mike (JIRA)" <ji...@apache.org> on 2016/09/16 23:54:20 UTC

[jira] [Updated] (INFRA-12626) Drop MD5 and SHA1 hashes for downloads, add SHA2

     [ https://issues.apache.org/jira/browse/INFRA-12626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike updated INFRA-12626:
-------------------------
    Description: 
On the download pages we provide MD5 and SHA1 hashes of the downloads. For an example, see:

https://archive.apache.org/dist/lucene/solr/4.10.4

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 suggest we do the same. MD5 was great, but hasn't been good enough for much for a while. SHA1 is better, but is on its way out. SHA2 is now where it's at.

(This issue will probably need help landing in the right components and project -- sorry about that. I did my best.)



  was:
On the download pages we provide MD5 and SHA1 hashes of the downloads. For an example, see:

https://archive.apache.org/dist/lucene/solr/4.10.4/solr-4.10.4.tgz

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 suggest we do the same. MD5 was great, but hasn't been good enough for much for a while. SHA1 is better, but is on its way out. SHA2 is now where it's at.

(This issue will probably need help landing in the right components and project -- sorry about that. I did my best.)




> Drop MD5 and SHA1 hashes for downloads, add SHA2
> ------------------------------------------------
>
>                 Key: INFRA-12626
>                 URL: https://issues.apache.org/jira/browse/INFRA-12626
>             Project: Infrastructure
>          Issue Type: Bug
>          Components: Buildbot, Dists
>            Reporter: Mike
>
> On the download pages we provide MD5 and SHA1 hashes of the downloads. For an example, see:
> https://archive.apache.org/dist/lucene/solr/4.10.4
> 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 suggest we do the same. MD5 was great, but hasn't been good enough for much for a while. SHA1 is better, but is on its way out. SHA2 is now where it's at.
> (This issue will probably need help landing in the right components and project -- sorry about that. I did my best.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)