-
-
Notifications
You must be signed in to change notification settings - Fork 309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lxml 4.7.x results in "A valid SubjectConfirmation was not found on this Response" with ADFS #292
Comments
Encountered the same issue and it only happens when the SAMLResponse is encrypted.
Reproduced the issue with the code in demo-django and dockerfile added (reference this repo)
|
This issue is also exposed in the python-social-auth testsuite, see python-social-auth/social-core#653 |
I've tried workaround mentioned by @memocong in #292 (comment), and it does somewhat improve the situation, but still is not 100% reliable (without the workaround I get nearly 100% fail rate, with the workaround it is down to something like 20%). Just for the reference, the workaround patch I've tried:
To me it seems like there is some memory corruption going on inside lxml inside Also, sometimes this fails with tons of namespace errors:
|
… inside a encrypted element is validated. See SAML-Toolkits/python3-saml#292 Also reverted dm.xmlsec.binding to 1.3.7
… inside a encrypted element is validated. See #292
Has it been determined if this is an If the former, does anyone have a link to an issue on |
Encountered the same "SubjectConfirmation" issue in our SSO solution, which utilizes |
|
No, it is broken in 4.7.1 and 4.8.0 as well (4.6.5 works fine). The 4.7.0 had an issue that it did not include all files in the release, that's why it's yanked. |
Oh, I see thanks for the clarification! I'll be be updating my comment to avoid confusing people then.. |
Then let me ask again: do we know if they know they have a bug? Did someone open an issue somewhere? |
@mredaelli list of open lxml bugs are here - https://bugs.launchpad.net/lxml |
I've just verified it happens in 4.9.0 as well. But it seems to happen only with the binary wheels, if I build lxml from the source, it works correctly. Can somebody else confirm such behavior? (I'm testing using python-social-auth testsuite, and it does not trigger the bug in 100%, so there is always some estimation). You can install from the source using Looking at lxml bugs, this one might be the one we're hitting: https://bugs.launchpad.net/lxml/+bug/1960668 |
This might be a workaround for SAML-Toolkits/python3-saml#292
I'm wondering if there is any resolution in sight for this issue? lxml has released version 4.9.1 which resolves a vulnerability issue, but this issue blocks the upgrade of projects using python3-saml 🙁 |
+1 |
Recent python3-saml versions block lxml upgrade, which in turn contains security fixes for GHSA-wrxv-2j5q-m38w. The version restriction seems to be caused by binary wheel not compatible with some distros (see SAML-Toolkits/python3-saml#292). As we build lxml from the source, we're not affected by this. Once python3-saml raises the restriction (for example by SAML-Toolkits/python3-saml#309), we can switch back to the latest version.
I am having the same issue here, however, without changing any source code, this solved my issue: $ pip uninstall lxml
$ pip install --no-binary lxml lxml==4.7.0 |
yes, that works, but you would be better to install lxml==4.9.1 https://bugs.launchpad.net/lxml/+bug/1960668 is the canonical upstream lxml bug report. It still isn't clear if this is solvable with code changes in one or more of lxml, xmlsec and libxml2, or if the above is the correct long-term solution to ensure xmlsec and lxml are using the same version of libxml2. |
This is in preparation to upgrading python3-saml and then lxml to their latest versions. lxml breaks on some edge cases becaues it was statically built against a different libxml2 than *other* xml-based tooling using at runtime ( because that's dynamically linked), causing some tree lookups to fail. * python3-saml issue: SAML-Toolkits/python3-saml#292 * upstream bug: https://bugs.launchpad.net/lxml/+bug/1960668
This is in preparation to upgrading python3-saml and then lxml to their latest versions. lxml breaks on some edge cases becaues it was statically built against a different libxml2 than *other* xml-based tooling using at runtime ( because that's dynamically linked), causing some tree lookups to fail. * python3-saml issue: SAML-Toolkits/python3-saml#292 * upstream bug: https://bugs.launchpad.net/lxml/+bug/1960668
… built against old libxml2 This fixes PowerDNS-Admin#1442 and closes PowerDNS-Admin#1433. The issue with python3-saml not working is because the binary lxml wheel is built against a different version of libxml2. ``--no-binary lxml`` can be used to fix this and python3-saml will work. for references check these: - SAML-Toolkits/python3-saml#292 - https://bugs.launchpad.net/lxml/+bug/1960668 - open-formulieren/open-forms#2247
… built against old libxml2 This fixes PowerDNS-Admin#1442 and closes PowerDNS-Admin#1433. The issue with python3-saml not working is because the binary lxml wheel is built against a different version of libxml2. ``--no-binary lxml`` can be used to fix this and python3-saml will work. for references check these: - SAML-Toolkits/python3-saml#292 - https://bugs.launchpad.net/lxml/+bug/1960668 - open-formulieren/open-forms#2247 ``` Tested on: - ubuntu:23.04 - WORKING - ubuntu:22.10 - WORKING - ubuntu:22.04 - WORKING - ubuntu:20.04 - WORKING - ubuntu:18.04 - NOT WORKING - pip usage error with -r requirements.txt - debian:10 - WORKING - debian:11 - WORKING - alpine:edge - WORKING - alpine:3.17 - WORKING - alpine:3.16 - WORKING - alpine:3.15 - WORKING - alpine:3.14 - WORKING - rockylinux:9 - WORKING - rockylinux:8 - NOT WORKING - pip usage error with -r requirements.txt - almalinux:9 - WORKING - almalinux:8 - NOT WORKING - pip usage error with -r requirements.txt - fedora:36 - WORKING - fedora:37 - WORKING - fedora:38 - WORKING - fedora:39 - WORKING ```
Fixes Python 3.11 incompatibility using ancient lxml binary PyPI built against old libxml2. This fixes PowerDNS-Admin#1442 and closes PowerDNS-Admin#1433. The issue with python3-saml not working is because the binary lxml wheel is built against a different version of libxml2. ``--no-binary lxml`` can be used to fix this and python3-saml will work. for references check these: - SAML-Toolkits/python3-saml#292 - https://bugs.launchpad.net/lxml/+bug/1960668 - open-formulieren/open-forms#2247 ``` Tested on: - ubuntu:23.04 - WORKING - ubuntu:22.10 - WORKING - ubuntu:22.04 - WORKING - ubuntu:20.04 - WORKING - ubuntu:18.04 - NOT WORKING - pip usage error with -r requirements.txt - debian:10 - WORKING - debian:11 - WORKING - alpine:edge - WORKING - alpine:3.17 - WORKING - alpine:3.16 - WORKING - alpine:3.15 - WORKING - alpine:3.14 - WORKING - rockylinux:9 - WORKING - rockylinux:8 - NOT WORKING - pip usage error with -r requirements.txt - almalinux:9 - WORKING - almalinux:8 - NOT WORKING - pip usage error with -r requirements.txt - fedora:36 - WORKING - fedora:37 - WORKING - fedora:38 - WORKING - fedora:39 - WORKING ```
Release 4.4 of python social auth upgrades the lxml packages and seemd to be not compatible with our code. The issue we have is similar to this issue: SAML-Toolkits/python3-saml#292 In a first time we decided to downgrade python social auth to a known working version.
Release 4.4 of python social auth upgrades the lxml packages and seemd to be not compatible with our code. The issue we have is similar to this issue: SAML-Toolkits/python3-saml#292 In a first time we decided to downgrade python social auth to a known working version.
Release 4.4 of python social auth upgrades the lxml packages and seemd to be not compatible with our code. The issue we have is similar to this issue: SAML-Toolkits/python3-saml#292 In a first time we decided to downgrade python social auth to a known working version.
For those of you installing --no-binary lxml
# other deps
python3-saml
# more deps |
We recently upgraded our lxml from 4.6.4 to 4.7.1 and suddenly there were some SSO issues:
OneLogin works fine, but when a client logs in from an ADFS instance, they get the message that "A valid SubjectConfirmation was not found on this Response".
Moving back to 4.6.4 resolves this issue.
The configuration:
The text was updated successfully, but these errors were encountered: