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
