Antoine Pietri added the comment:
Thanks, those arguments are convincing. I guess for applications that really
can't move to a more secure hash, it would be better for them to rely on
third-party libraries that implement the "band-aid".
I'm closing this for now.
--
stage: ->
Christian Heimes added the comment:
I talked to some experts (Alex Gaynor, Simo Sorce). They all share my sentiment
and are against SHA1DC. The algorithm is just a poor bandaid for a gapping
security issue. Everybody was strongly against replacing SHA1 with SHA1DC by
default, because it's
Christian Heimes added the comment:
I wouldn't call SHA1 a secure hash function any more. SHA1DC is both an
incompatible implementation and a bandaid for legacy applications that can't
easily update to a proper hashing algorithm. Also it's rather pointless to
update our SHA1 implementation
Raymond Hettinger added the comment:
Assigning to Christian to make the call.
+1 for option #1, replacing sha1 implementation with the harden version,
helping us move close to more-secure-by-default.
--
assignee: -> christian.heimes
nosy: +rhettinger
Antoine Pietri added the comment:
On Wed, Oct 10, 2018 at 11:27 PM STINNER Victor wrote:
> I dislike modifying a hash function to return its output but keep the same
> name. For name, "SHA1" must remain "SHA1". If you want a variant, it should
> have a different name, but I would expect
STINNER Victor added the comment:
I dislike modifying a hash function to return its output but keep the same
name. For name, "SHA1" must remain "SHA1". If you want a variant, it should
have a different name, but I would expect that the existing sha1 function
remains unchanged. How do you
New submission from Antoine Pietri :
SHA-1 has been broken a while ago. While the general recommandation is to
migrate to more recent hashes (like SHA-2 and SHA-3), a lot of industry
applications (notably Merkle DAG implementations like Git or Blockchains)
require backwards compatibility
