fix(security): resolve CVE-2026-26007 by migrating deprecated OpenSSL.crypto.verify and unblocking cryptography >= 46.0.5#1021
Conversation
|
@ascii-dev I got your contribution here: thank you |
|
@peppelinux Awesome to see this actively unblocking the v3.2.0 release for iam-proxy-italia! Glad it was helpful. @c00kiemon5ter - let me know if there are any changes you'd like me to add to get this aligned for a merge. |
robin92
left a comment
robin92
left a comment
There was a problem hiding this comment.
I think this is a good change though I'd take care of
issue: cert_crypto.signature_hash_algorithm can return None which would cause a TypeError from _ec.ECDSA call.
and add some tests before merging this.
| "Topic :: Software Development :: Libraries :: Python Modules", | ||
| ] | ||
| requires-python = ">= 3.9" | ||
| requires-python = ">= 3.9.2" |
There was a problem hiding this comment.
suggestion: If there weren't any fixes that you need, then I'd avoid bumping this.
There was a problem hiding this comment.
@robin92 cryptography (46.0.5) requires >=3.8 but explicitly excludes 3.9.0 and 3.9.1.
…ing crypto.verify
ascii-dev
force-pushed
the
bump_openssl_cryptography_versions
branch
from
26f4ca7 to
9377d34
Compare
| "cryptography >=46.0.5", | ||
| "defusedxml", | ||
| "pyopenssl <24.3.0", | ||
| "pyopenssl >=25.3.0", |
There was a problem hiding this comment.
should bump this to >=26.0.0 as well (#1023)
| return False, ("CN may not be equal for CA certificate and the " "signed certificate.") | ||
| ca_cn = ca_cert_crypto.subject.get_attributes_for_oid(_x509.NameOID.COMMON_NAME) | ||
| cert_cn = cert_crypto.subject.get_attributes_for_oid(_x509.NameOID.COMMON_NAME) | ||
| if ca_cn and cert_cn and ca_cn[0].value == cert_cn[0].value: |
There was a problem hiding this comment.
If common name is missing from both certs the old code would return False: pyopenssl returns None if attribute is missing: https://github.com/pyca/pyopenssl/blob/f72218efff8a1e3e7ae4683793ad36d2f9610976/src/OpenSSL/crypto.py#L681
New code will not return in such case.
I don't know if that is a problem or not, just pointing out that there is a subtle difference in logic.
|
We are currently developing a SAML-based SSO implementation using pysaml2. However, we are blocked due to CVE-2026-26007 in the cryptography dependency, which is causing our security/compliance checks to fail. Thanks for all efforts in raising this PR, this change would unblock our adoption and ongoing development. Would appreciate it if this could be reviewed and merged at the earliest. The community is ready to help move this forward. This would also help a broader community currently impacted by this CVE. |
Seconding this! |
|
Thanks for the contribution, @ascii-dev . I've reviewed the changes and that looks like diligent work exactly matching the description in this PR. I've tested it in our deployment of SATOSA and it works all fine. |
|
@peppelinux given you are a member of the IdentityPython org, are you not able to approve/merge things yourself? Or does only @c00kiemon5ter have those powers? |
|
Friendly follow-up on this PR. This fix has been awaited by several users and unblocks adoption for teams affected by the cryptography CVE. The implementation has already received positive review and has been validated in downstream deployments. @c00kiemon5ter, would you be able to take a final look and merge this when you have a chance? It would be greatly appreciated. Thanks! |
|
Perhaps we should lure @c00kiemon5ter in with a nice full jar of chocolate chip cookies 🤔 |
…phy, twisted, pydantic-ai) (#5663) * chore(deps): switch pysaml2 to baserow fork to fix cryptography and pyopenssl CVEs The baserow/pysaml2 fork is v7.5.4 with IdentityPython/pysaml2#1021 cherry-picked, lifting the pyopenssl<24.3.0 cap that blocked the cryptography upgrade. Pinned to the immutable merge commit (tagged v7.5.4+deps-upgrade) via tool.uv.sources. Upgrades cryptography 43.0.3 -> 49.0.0 and pyopenssl 24.2.1 -> 26.3.0, resolving 3 high and 3 low Dependabot alerts including CVE-2026-26007. git is added to the Dockerfile builder-prod-base and dev stages because uv requires the git CLI to fetch git-sourced dependencies. * chore(deps): upgrade twisted, django, daphne, pydantic-ai and pydantic-settings to fix remaining CVEs - twisted 25.5.0 -> 26.4.0: DNS compression pointer DoS (high) - pydantic-ai-slim 1.77.0 -> 1.102.0: two SSRF blocklist bypasses (medium); requires boto3 >= 1.42.63 - pydantic-settings 2.12.0 -> 2.14.2: secrets_dir symlink traversal (medium) - django 5.2.14 -> 5.2.15 and daphne 4.2.1 -> 4.2.2 security patches pydantic-ai 1.102 turned StreamedResponse._parts_manager into a cached_property and added _finished/_cancelled class-default fields. These shadow __getattr__ on the assistant's _ErrorRecoveringStream proxy, so get() would build the response from an empty proxy-local parts manager. The shadowed attributes are now property-delegated to the inner stream, with a regression test asserting get() sees the streamed parts. * chore: add changelog entry for security dependency upgrades
|
Could you please share the expected release date for the new version and when this issue is planned to be fixed? |
|
Following up on this PR when you have a chance. This fix would be very helpful for several users and would unblock teams impacted by the cryptography CVE. The implementation has already received positive review and has been validated in downstream deployments. |
|
We're currently working on a SAML-based SSO implementation with PySAML2, but the CVE-2026-26007 issue in the cryptography dependency has become a blocker because it fails our security/compliance checks. Thanks for taking the time to prepare this PR. Merging it would enable us to continue our implementation and would also help many others in the community who are waiting on a fix for this vulnerability. We'd really appreciate it if you could review and merge it when you have a chance. |
|
Hi Team, |
|
Hi Team, just a friendly follow-up on this PR. Merging this fix would unblock our product integration, as the current cryptography CVE is preventing us from using this library. We'd greatly appreciate a review when you have a chance. |
|
Hi Team, |
|
Hi @ascii-dev, thanks again for putting together this PR and for continuing to keep it up to date. It looks like the implementation has received positive technical feedback, has been approved, and has also been validated by multiple downstream users and forks. This fix would unblock a number of teams that are currently unable to upgrade because of the cryptography CVE. From the discussion, it seems that @c00kiemon5ter may be the only maintainer with merge permissions. If that’s the case, is there anything the community can do to help move this forward? @voneiden , @jwjenkin , @robin92 — do any of you have merge permissions, or is there another maintainer we should reach out to? If not, is there any additional follow-up work that would help get this PR over the finish line? I also noticed that @baijum , @lorenzogil , and @johanlundberg are listed as maintainers on PyPI. If any of you have merge or release permissions, or could help coordinate a review or release, your assistance would be greatly appreciated. Happy to help in any way that would make merging this easier. Thanks again to everyone who has reviewed and tested the changes. |
|
@nelsonharry nope, not a maintainer. |
|
@nelsonharry Not a maintainer either. |
|
Sure don't. I was tempted to fork but don't have time to maintain it 😅 |
|
Since this CVE fix has been open for months, and it appears the last PR merged upstream was about 9 months ago, it looks like the maintainers might just be stretched too thin right now. Given how many people are blocked by this, I am willing to create and actively maintain a community fork so everyone can get these security updates. I am happy to maintain it going forward, or just serve as a bridge until the original maintainers have the bandwidth to return. Before I do, would a maintained fork actually be helpful to the folks in this thread? Let me know. If there are no upstream objections and it helps move us forward, I can have something set up and published in the next week. |
|
@ascii-dev we've switched over to https://github.com/peppelinux/pysaml2/tree/pplnx-v7.5.4-1. @peppelinux might want to coordinate with @ascii-dev so you're not both maintaining separate forks for the same reason. |
|
@nelsonharry I am also not a maintainer. |
|
Maybe someone contacts IdentityPython first? Maybe they know what happened to @c00kiemon5ter info@idpy.org |
|
@lpaglione any chance you could help? |
|
@spaceone my director and I both tried to contact identity python directly at the end of April. Crickets. |
20 participants
Description
The feature or problem addressed by this PR
This PR resolves the dependency deadlock preventing the mitigation of CVE-2026-26007 (elliptic curve subgroup validation vulnerability).
Currently, upgrading the cryptography package to a secure version is blocked by the upper bound constraint on pyopenssl < 24.3.0. That constraint exists because OpenSSL.crypto.verify was deprecated and subsequently removed in pyopenssl 24.3.0. We need a way to verify signatures without relying on the removed API so we can bump both packages and secure downstream users.
Closes #1017
What your changes do and why you chose this solution
To unblock the security patch, this PR refactors the signature verification layer in src/saml2/cert.py.
Technical Changes:
Why this solution:
The project's remaining reliance on pyopenssl for certificate creation and loading remains completely untouched and functional. Existing tests pass locally with xmlsec1 installed.
Checklist