GeezerVison is showing github.com — Expose Expat XML attack protection APIs · Issue #90949 · python/cpython
Expose Expat XML attack protection APIs #90949Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2022-02-18.21:27:31.809>
labels = ['type-feature', '3.11']
title = 'expose expat XML billion laughs attack mitigation APIs'
updated_at = <Date 2022-02-25.02:16:52.654>
user = 'https://github.com/gpshead' bugs.python.org fields:
activity = <Date 2022-02-25.02:16:52.654>
actor = 'sping'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2022-02-18.21:27:31.809>
creator = 'gregory.p.smith'
dependencies = []
files = []
hgrepos = []
issue_num = 46793
keywords = []
message_count = 2.0
messages = ['413513', '413955']
nosy_count = 3.0
nosy_names = ['gregory.p.smith', 'sping', 'corona10']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue46793'
versions = ['Python 3.11'] Linked PRs
Activitygpshead commented on Feb 18, 2022 Quoting from #31397 (comment)
"""
XML_SetBillionLaughsAttackProtectionActivationThreshold
XML_SetBillionLaughsAttackProtectionMaximumAmplification
I still hope that someone can make those two^^ accessible (with additional glue code) to the user on pyexpat level in CPython.
""" - Sebastian Pipping @hartwork hartwork commented on Feb 25, 2022 hartwork commented on Sep 16, 2025 FYI starting with Expat 2.7.2, there are two new API functions more related to both security and amplification:
picnixz commented on Sep 17, 2025 @hartwork I have a question on the API usage. It appears that we can only call those functions on parsers without parents. Do you suggest that we:
- provide a module-wide function which, for any parser object created by the user, the function will be called automatically for orphan parsers, or
- keep it a per-parser configuration?
Having it enabled everywhere seems fine to me, considering that otherwise users would need to know whether a parser has a parent or not, however, there is no way to detect this on our side to warn them properly (the structure is opaque).
I think the only way to get a parser with a parent is through XML_ExternalEntityParserCreate nbut I don't really know if I'm entirely right here. Reacted by Sebastian Pipping hartwork commented on Sep 17, 2025 Hello @picnixz, thanks for your interest! 👍
@hartwork I have a question on the API usage. It appears that we can only call those functions on parsers without parents.
Yes. It's a deliberate choice to disallow that, the alternative would have been to instead find the root parser and apply the change to the root parser. The latter could be considered misleading or convenient, depending on view.
Do you suggest that we:
-
provide a module-wide function which, for any parser object created by the user, the function will be called automatically for orphan parsers, or
-
keep it a per-parser configuration?
Definitely not module wide — two unrelated parsers can have different limit and threshold values at runtime —, the rest I may not fully understand. Can you help me understand the rest better, e.g. the orphan part of it?
Having it enabled everywhere seems fine to me, considering that otherwise users would need to know whether a parser has a parent or not, however, there is no way to detect this on our side to warn them properly (the structure is opaque).
I think you're right that a parser cannot be asked "do you have a parent?" currently. "Not easily" for sure, "not at all" probably.
I think the only way to get a parser with a parent is through XML_ExternalEntityParserCreate nbut I don't really know if I'm entirely right here.
That is correct, it's the only way.
I'm happy to discuss this more. picnixz commented on Sep 17, 2025 By orphan I meant without a parent parser. What I wanted to know was whether we should, upon parser creation, call these new functions internally with thresholds and factors being set globally but you already answered by "no" so it's good on my side.
Considering the failure can only happen when either the parser has a parent or the factor is invalid as a number, I'm going to simply remake those checks on Python's side so that I can raise appropriate exceptions (ideally I would have loved having a return code being returned by expat so that I know what exactly happened but it's also fine). Reacted by Sebastian Pipping added 2 commits that reference this issue on Jun 24, 2026gh-90949: Fix copy-paste typo in pyexpat capsule API initialization (#… [3.15] gh-90949: Fix copy-paste typo in pyexpat capsule API initializ…
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|