Open jiasli opened 3 months ago
Thank you for your feedback. Tagging and routing to the team member best able to assist.
To help me understand better, what is the benefit for this?
It seems to me the impact is we stop allowing users to use cryptography 2.5.
To help me understand better, what is the benefit for this?
There is no immediate benefit, but it avoids being broken by cryptography
when backend
is totally removed.
This issue is merely a tracker. There is no action item currently.
To help me understand better, what is the benefit for this?
There is no immediate benefit, but it avoids being broken by
cryptography
whenbackend
is totally removed.This issue is merely a tracker. There is no action item currently.
FWIW, I also feel @xiangyan99 's reluctance to "the impact is we stop allowing users to use cryptography 2.5".
Besides, crytography does not use semantic versioning, so, there is no obvious way for a mid-tier/downstream library to guard against a potential breaking change.
I end up with a complicated mechanism of wrapping most of MSAL's cryptography usage into a helper function, and then have a unit test case to call that helper. If that test case fails someday, we will know we hit the breaking change.
Describe the bug Per
Expected behavior Azure Identity currently requires
https://github.com/Azure/azure-sdk-for-python/blob/d840732813529eaf8551422a1497bedeb21a1fe1/sdk/identity/azure-identity/setup.py#L63
and passes
backend
arguments:https://github.com/Azure/azure-sdk-for-python/blob/07d10639d7e47f4852eaeb74aef5d569db499d6e/sdk/identity/azure-identity/azure/identity/_credentials/certificate.py#L95-L96
but the best practice is to bump
cryptography
to newer version and stop using deprecatedbackend
argument.