As of now the hash algorithm for HMAC defaults to MD5. However MD5 is considered broken. HMAC-MD5 is still ok but shall not be used in new code. Applications should slowly migrate away from HMAC-MD5 and use a more modern algorithm like HMAC-SHA256.

Therefore I propose that default digestmod should be deprecated in Python 3.4 and removed in 3.5. Starting with Python 3.5 developer are forced to choose a hash algorithm like SHA256. Our documentation shall suggest it, too.

In addition I would like to enhance the meaning of the `digestmod` argument a bit. Right now it either must be a module or a callable. It should also support a name, e.g. hmac.new("secret", digestmod="sha256")

+1.

I don't know how you intend to make `digestmod` mandatory given the current function signature.

> Applications should slowly migrate away from HMAC-MD5 and use a more
> modern algorithm like HMAC-SHA256.

Applications don't always choose their cipher. MD5 is needed for compatibility with existing protocols such as CRAM-MD5.

> I don't know how you intend to make `digestmod` mandatory given the current function signature.

That's easy:

if digestmod is None:
    raise TypeError("HMAC needs argument 'digestmod'")

PS: I don't want to deprecate HMAC-MD5. I just want to deprecate that HMAC defaults to HMAC-MD5.

Here is a patch that deprecates MD5 has implicit default hashing algorithm. It also implements digestmod string support.

PEP 247 doesn't define the digestmod argument of keyed hashing algorithms. I'm going to define it in PEP 452.

assertWarns() is much easier than the block I have copied and pasted. Thanks. :)

comments added to the review.

I don't think a DeprecationWarning should be raised as that'll infuriate users of python programs more than developers who can fix code.

GPS, what do you suggest instead? Do you want me to remove the deprecation warning?

yes just remove the DeprecationWarning.  Document it as deprecated with a release now+0.2 as the earliest it will be removed.  (if you want a warning at all, use PendingDeprecationWarning as that one is filtered out by default so it won't bother users of tools written in Python but only developers actively looking for issues)

I've changed the deprecation warning to PendingDeprecationWarning. Please review my wording and grammar.

I would prefer to directly raise an exception in Python 3.4. Developers will not notice a warning, warning are hidden by default. How many developers run their tests using -Werror?

Having to add a parameter to hmac() in applications to port them to Python 3.4 should not be so hard. And using MD5 is really a major security issue, don't you think so?

> Having to add a parameter to hmac() in applications to port them to
> Python 3.4 should not be so hard. And using MD5 is really a major
> security issue, don't you think so?

Some uses of md5 don't have anything to do with security. I'm -1
on removing the default value here.

HMAC-MD5 is still fine for legacy support. I wouldn't use it in new program, though

I'll commit the patch later.

Well, if deprecating is not an option, it's probably better to add a red warning explaining why the default choice may not fit all use cases.

New changeset 86107e7e6ee5 by Christian Heimes in branch 'default':
Issue #17276: MD5 as default digestmod for HMAC is deprecated. The HMAC
http://hg.python.org/cpython/rev/86107e7e6ee5

I don't understand why PendingDeprecationWarning was used here.  DeprecationWarnings are silent by default.  I'm also not clear on why this is being delayed until 3.6, instead of being changed in 3.5 after a deprecation, given that the default is considered to be a bit of a security issue.

New changeset c10ec51a2ce4 by R David Murray in branch 'default':
whatsnew: hmac *digestmod* accepts strings, and default is deprecated. (#17276)
http://hg.python.org/cpython/rev/c10ec51a2ce4