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
Received on 2017-06-29 04:40:30 CEST