Provide non-deprecated md5 and sha1 hasher

For understandable reasons, com.google.common.hash.Hashing.md5 and sha1 were deprecated because they are cryptographically broken and it’s vital that programmers not rely on them for secure uses.

In a project of mine, there are legacy uses of md5 that use it as a convenient non-cryptographic hash function, and these uses cannot be readily eliminated.

My project uses Scala, which doesn’t give fine-grained control over compiler warnings. As a result, I either have to silence all compiler warnings, or see lots of deprecation warnings about md5 usage. Both alternatives are undesirable.

I propose that the existing deprecation of md5 and sha1 remain; but that a non-deprecated, equivalent version of them be provided for uses such as mine. They should be named something like unsafeMD5 or brokenSHA1 to convey the risk of using them, but should not cause compiler warnings when used.

[findepi]

If it’s causing people additional trouble, though, we’d like to hear about it.

@cpovirk I would like to reopen this thread.

As @kevinb9n wrote:

Personally, I’m not sure it was ever entirely correct to mark these methods deprecated.

For non-cryptographic reasons, the deprecation notice for Hashing#sha1 advices to use Hashing#goodFastHash which is a good advise, unless the result is going to be persisted somewhere for comparison at later The other suggested option, sha256 produces an unnecessarily long hash (again: non-crypto usage) and i have a use-case where storage space is limited.

For now I can @SuppressWarnings("deprecation"), but – especially with Guava’s general view on managing deprecated features – I don’t feel comfortable with it. Please remove the deprecation.

[kevinb9n]

Personally, I’m not sure it was ever entirely correct to mark these methods deprecated. The hash function you need to use is often dictated by another system or data that was already persisted and can’t be changed. If the format chosen was md5, then Hashing.md5() is the one and only best choice to use.

We want to discourage people from choosing it when they have the actual freedom to select their hash function - but there’s no way to express that.

Maybe providing each under two different names, with only one of them marked deprecated, is indeed the right way out of this. I’m not sure yet. I would consider naming the non-deprecated ones with the prefix “legacy”, like legacyMd5() – the md5 you use when it’s for legacy reasons.