Bug 2482445
| Summary: | python3-msal: dependency problem in EPEL 10.3 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Carl George 🤠<carlwgeorge> |
| Component: | python-msal | Assignee: | Ben Beasley <code> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | epel10 | CC: | code, jeremy, python-packagers-sig |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | python-msal-1.36.0-2.el10_3 | Doc Type: | --- |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2026-06-10 00:25:30 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Carl George đź¤
2026-05-28 00:08:24 UTC
Hmm, this is a little trickier to investigate because there is an older python3-cryptography in the repos as well, and dnf is willing to downgrade it in both mock and scratch builds.
The upper bound is precautionary: in setup.cfg, we can read:
# load_key_and_certificates() is available since 2.5
# https://cryptography.io/en/latest/hazmat/primitives/asymmetric/serialization/#cryptography.hazmat.primitives.serialization.pkcs12.load_key_and_certificates
#
# And we will use the cryptography (X+3).0.0 as the upper bound,
# based on their latest deprecation policy
# https://cryptography.io/en/latest/api-stability/#deprecation
cryptography>=2.5,<51
It’s probably safe to consider removing the upper bound entirely, especially in Fedora, and rely on testing instead. At least we should be able to accommodate cryptography 48 without source-code changes, as upstream did in https://github.com/AzureAD/microsoft-authentication-library-for-python/commit/a59bd09279d3d2c03ed45776c41ace1993f12bb9.
On the other hand, I don’t remember why EPEL10 got “stuck” at 1.33.0. Nothing in https://github.com/AzureAD/microsoft-authentication-library-for-python/releases/tag/1.34.0 or in subsequent release notes looks like a breaking change, and the update doesn’t appear to be blocked by dependencies. Maybe it was blocked on the cryptography lower bound at one point.
I think we can safely solve this by upgrading to at least 1.34.0, which builds as-is, and even to 1.36.0 if we branch python-azure-keyvault-secrets to EPEL10 as a new test dependency and do a quick bootstrapping as described in https://src.fedoraproject.org/rpms/python-msal/c/8e73953c5dd1fbf529f340be93f3dff55ac76787?branch=rawhide. This seems fine, including reverse dependencies, in local mock testing and in https://copr.fedorainfracloud.org/coprs/music/msal-epel10/packages/, so I think this is what I would prefer to do. @jeremy, do you have any objections to this plan? I’m happy to do the branching, building, and update as long as you agree.
I _think_ EPEL10 got stuck simply because I got distracted and forgot; I think updating to 1.36.0 is a good idea as from what I recall there were some security issues fixed (although the changelog didn't always make that obvious, and there were no CVEs assigned). I'd greatly appreciate the help, so by all means go for it. Thanks! FEDORA-EPEL-2026-624a6b698c (python-azure-keyvault-secrets-4.7.0-13.el10_3 and python-msal-1.36.0-2.el10_3) has been submitted as an update to Fedora EPEL 10.3. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-624a6b698c FEDORA-EPEL-2026-624a6b698c has been pushed to the Fedora EPEL 10.3 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-624a6b698c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-EPEL-2026-624a6b698c (python-azure-keyvault-secrets-4.7.0-13.el10_3 and python-msal-1.36.0-2.el10_3) has been pushed to the Fedora EPEL 10.3 stable repository. If problem still persists, please make note of it in this bug report. |