On Fri, May 27, 2016 at 3:08 PM, M.-A. Lemburg <mal@egenix.com> wrote:
On 27.05.2016 23:46, Donald Stufft wrote:
On May 27, 2016, at 5:41 PM, M.-A. Lemburg <mal@egenix.com> wrote:
If we add this now, there should at least be an exit strategy to remove the code again, when OpenSSL ships with the same code, IMO.
I think it is a clear win to have the fallback implementations in cases where people either don’t have OpenSSL or don’t have a new enough OpenSSL for those implementations. Not having the fallback just makes it more difficult for people to rely on those hash functions.
This will only be needed once the stdlib itself starts requiring support for some of these hashes and for that we could add a pure Python implementation, eg.
https://github.com/coruus/py-keccak
In all other cases, you can simply add the support via a package such as Björn's or Christian's.
SHA-3 and BLAKE are extremely widely accepted standards, our users will expect them, and they're significant improvements over all the current hashes in the algorithms_guaranteed list. If we demote them to second-class support (by making them only available in some builds, or using a slow pure Python implementation), then we'll be encouraging users to use inferior hashes. We shouldn't do this without a very good reason, and I don't see anything very convincing here... by all means drop the megabyte of test data, but why does it matter how many lines of code the algorithm is? No python developer will ever have to look at it -- hash code by its nature is *very* low maintenance (it either computes the right function or it doesn't, and the right answer never changes). And in unlikely case where some terrible unexpected bug is discovered then the only maintenance needed will be to delete the current impl and drop-in whatever the new fixed one is. So +1 to adding SHA-3 and BLAKE to algorithms_guaranteed. -n -- Nathaniel J. Smith -- https://vorpus.org