[PATCH] use SHA-2 hashes for releases

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH] use SHA-2 hashes for releases

Andreas Stieger-2
Hello,

Found this laying around... maybe someone who previously made releases
could check it out.

Obviously we could just as well use SHA-256. What do you think?

[[[

Use SHA-2 hashes for releases

* tools/dist/checksums.py: also check SHA-512 digest
* tools/dist/dist.sh: also generate SHA-512 digest
* tools/dist/download-release.sh: remove unused script
* tools/dist/release.py: switch to announcing SHA-512 digest
* tools/dist/templates/download.ezt,
  tools/dist/templates/rc-release-ann.ezt,
  tools/dist/templates/stable-release-ann.ezt: reference SHA-512 digests
  and HTTPS urls.

]]]


Andreas

--
Andreas Stieger <[hidden email]>
Project Manager Security
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)


sha2.patch (13K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] use SHA-2 hashes for releases

Daniel Shahaf-2
Good morning Andreas,

Andreas Stieger wrote on Sat, 10 Jun 2017 12:24 +0200:
> Hello,
>
> Found this laying around... maybe someone who previously made releases
> could check it out.
>

Any news about this patch?  I have some pending tweaks to release.py and
don't want to conflict.

> Obviously we could just as well use SHA-256. What do you think?
>

As I said about an earlier iteration: I think the main question is whether we
want to provide both sha1 and sha2 hashes for a transition period.  I.e., do
we try for compatibility or force people to switch over to sha2.

I don't have a preference between sha256 and sha512.

Cheers,

Daniel

> [[[
>
> Use SHA-2 hashes for releases
>
> * tools/dist/checksums.py: also check SHA-512 digest
> * tools/dist/dist.sh: also generate SHA-512 digest
> * tools/dist/download-release.sh: remove unused script
> * tools/dist/release.py: switch to announcing SHA-512 digest
> * tools/dist/templates/download.ezt,
>   tools/dist/templates/rc-release-ann.ezt,
>   tools/dist/templates/stable-release-ann.ezt: reference SHA-512 digests
>   and HTTPS urls.
>
> ]]]
>
>
> Andreas
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] use SHA-2 hashes for releases

Andreas Stieger-2
Hello,

On 06/28/2017 07:42 AM, Daniel Shahaf wrote:
> Andreas Stieger wrote on Sat, 10 Jun 2017 12:24 +0200:
>> Found this laying around... maybe someone who previously made releases
>> could check it out.
>
> Any news about this patch?  I have some pending tweaks to release.py and
> don't want to conflict.

No news.

> As I said about an earlier iteration: I think the main question is whether we
> want to provide both sha1 and sha2 hashes for a transition period.  I.e., do
> we try for compatibility or force people to switch over to sha2.

Those that may fail to change their "verification" from sha-1 to sha-2
may not have been very useful in any kind of verification in the first
place. So unless there is a technical reason (which I do not see) I
would just change it.

Andreas

--
Andreas Stieger <[hidden email]>
Project Manager Security
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] use SHA-2 hashes for releases

Daniel Shahaf-2
Andreas Stieger wrote on Wed, 28 Jun 2017 09:05 +0200:

> On 06/28/2017 07:42 AM, Daniel Shahaf wrote:
> > Andreas Stieger wrote on Sat, 10 Jun 2017 12:24 +0200:
> >> Found this laying around... maybe someone who previously made releases
> >> could check it out.
> >
> > Any news about this patch?  I have some pending tweaks to release.py and
> > don't want to conflict.
>
> No news.
>

Okay.  I'm +1 to the concept of moving to a stronger hash.  The patch looks
good, although I only reviewed the hunks (I haven't reviewed the context).

I'll go ahead with my tweaks: what I have so far isn't likely to conflict
with your in-flight patch.

> > As I said about an earlier iteration: I think the main question is whether we
> > want to provide both sha1 and sha2 hashes for a transition period.  I.e., do
> > we try for compatibility or force people to switch over to sha2.
>
> Those that may fail to change their "verification" from sha-1 to sha-2
> may not have been very useful in any kind of verification in the first
> place. So unless there is a technical reason (which I do not see) I
> would just change it.

Well, sha1 verification is still useful for verifiers who trust the
release manager to be honest, since only a collision attack has been
demonstrated, not a chosen plaintext attack.  But I was mainly thinking
of not requiring downstreams to update their release download scripts
between 1.9.5 and 1.9.6.

Cheers,

Daniel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [PATCH] use SHA-2 hashes for releases

Markus Schaber
Hi,

From: Daniel Shahaf [mailto:[hidden email]]

> Andreas Stieger wrote on Wed, 28 Jun 2017 09:05 +0200:
> > On 06/28/2017 07:42 AM, Daniel Shahaf wrote:
> > > Andreas Stieger wrote on Sat, 10 Jun 2017 12:24 +0200:
> > >> Found this laying around... maybe someone who previously made
> > >> releases could check it out.
> > >
> > > Any news about this patch?  I have some pending tweaks to release.py
> > > and don't want to conflict.
> >
> > No news.
>
> Okay.  I'm +1 to the concept of moving to a stronger hash.  The patch looks
> good, although I only reviewed the hunks (I haven't reviewed the context).
>
> I'll go ahead with my tweaks: what I have so far isn't likely to conflict
> with your in-flight patch.
>
> > > As I said about an earlier iteration: I think the main question is
> > > whether we want to provide both sha1 and sha2 hashes for a
> > > transition period.  I.e., do we try for compatibility or force people to
> > > switch over to sha2.
> >
> > Those that may fail to change their "verification" from sha-1 to sha-2
> > may not have been very useful in any kind of verification in the first
> > place. So unless there is a technical reason (which I do not see) I
> > would just change it.
>
> Well, sha1 verification is still useful for verifiers who trust the release
> manager to be honest, since only a collision attack has been demonstrated,
> not a chosen plaintext attack.  But I was mainly thinking of not requiring
> downstreams to update their release download scripts between 1.9.5 and 1.9.6.


I'd vote to provide both SHA1 and SHA2 for existing stable branches (1.8.x,
1.9.x), and move to SHA2 only for 1.10 and ongoing releases.

Just for the sake of backwards compatibility with existing downstream
infrastructure. I agree that SHA1 is not completely useless for verification,
it seems still useful against MITM attacks, or malicious download servers.


Best regards

Markus Schaber

CODESYS® a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: [hidden email] | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.
Loading...