Hi, I have raised 2 PRs for the deprecation of the auth mechanism, These should be removed but these are public APIs we should first deprecate it in 3.13 and then remove it in 3.15.
If you folks don’t agree with the deprecation, I will close the PR.
issue: Remove historic CRAM-MD5 mechanism · Issue #107675 · python/cpython · GitHub
Is CRAM-MD5 still in use by email providers?
I don’t think so, but I have only checked with Gmail. There can be some.
That is not a sufficient sample size to know if you will end up causing a problem for users of this feature.
yes, that’s why we are deprecating.
That is backwards! If you remove it and there are users of it then you break compatibility with an email service that may be stuck using the old crypto.
Note also that this discussion is meant to gather support for the deprecation; I would expect to see arguments as to why the feature should be removed, and a reasonably comprehensive overview of usage. When evaluating a change, remember that the status quo (often) wins by default.
A
I have no time to search for a better source, but this document says that the CRAM-MD5 mechanism “is official deprecated”
That does not change my concern that it may be in use by people that have to use it.
In which case this is a breaking change.
There’s precedent in the stdlib for deprecating insecure code, e.g. crypt.
It seems to me that support for something like this should be deprecated, perhaps especially if people are using it. The stdlib shouldn’t encourage or enable bad practices.
Perhaps this is a question for the Security Developer-in-Residence @sethmlarson ?
There’s plenty of precedent for deprecating and removing insecure code in Python, see SSLv3/TLSv1/1.1 in the “ssl” module. If this code isn’t recommended (judging from the linked document) and isn’t in widespread usage I think deprecating it makes sense to me.