xmlrpc.client.dumps() skips argument validation when Python is run with -O
還沒有人認領這個 Issue。
評估
研究方向
閱讀 Lib/xmlrpc/client.py,並使用提供的腳本在正常執行和使用 -O 執行兩種情況下重現該行為。檢查 dumps() 中的驗證,然後為無效參數和多值回應新增回歸涵蓋,以確保在最佳化下行為保持一致。
由索引模型根據 Issue 內容生成。
描述
Bug report
Bug description:
Bug description
xmlrpc.client.dumps() currently relies on assert statements to validate public API arguments.
As a result, invalid inputs are rejected in normal execution, but the validation is silently removed when Python is run with optimization (-O), causing different runtime behavior for the same API.
The documentation states that:
paramsmust be a tuple orFaultinstance.methodresponse=Trueexpects a singleton response tuple.
However, these constraints are enforced only through assert, which is removed when __debug__ is false.
Reproducer
import xmlrpc.client as xmlrpclib
for label, call in [
("list params", lambda: xmlrpclib.dumps(["x"])),
("dict params", lambda: xmlrpclib.dumps({"x": 1})),
("string params", lambda: xmlrpclib.dumps("abc")),
("multi-value response", lambda: xmlrpclib.dumps((1, 2), methodresponse=True)),
]:
try:
result = call()
except BaseException as exc:
print(label + ":", type(exc).__name__, str(exc))
else:
print(label + ": OK")
Normal execution
python repro.py
Output:
list params: AssertionError argument must be tuple or Fault instance
dict params: AssertionError argument must be tuple or Fault instance
string params: AssertionError argument must be tuple or Fault instance
multi-value response: AssertionError response tuple must be a singleton
Optimized execution
python -O repro.py
Output:
list params: OK
dict params: OK
string params: OK
multi-value response: OK
Root cause
Lib/xmlrpc/client.py currently performs argument validation using assertions:
assert isinstance(params, (tuple, Fault)), \
"argument must be tuple or Fault instance"
assert len(params) == 1, \
"response tuple must be a singleton"
When Python is executed with -O, these assertions are removed and execution proceeds into the marshalling logic, which serializes the supplied values instead of rejecting them.
Expected behavior
Public API validation should be enforced consistently regardless of optimization mode.
Invalid values should continue to be rejected when Python is run with -O.
Actual behavior
Running under -O disables validation and allows invalid inputs to be serialized.
Suggested fix
Replace the assertion-based validation with explicit runtime checks.
Possible exception types:
TypeErrorwhenparamsis neither a tuple nor aFaultinstance.ValueErrorwhenmethodresponse=Trueis used with a tuple length other than 1.
Add regression tests to ensure behavior remains consistent under optimization.
Notes
I searched for existing issues and did not find an open report covering this specific -O behavior difference for xmlrpc.client.dumps().
This appears to be a public API consistency bug rather than a security issue.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Windows
Linked PRs
- gh-151533
- 主要語言
- Python
- 星號
- 77.2k
- 分支
- 36k
- 平均合併
- 1 天 9 小時
- 30 天內合併 PR
- 558
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
python/cpython 的其他 Issue
-
docs pending
難度 2/5 1-3 小時 新手友好度 78/100
-
stdlib type-feature
難度 2/5 1-3 小時 新手友好度 78/100
-
stdlib type-feature
難度 2/5 1-3 小時 新手友好度 72/100
-
build type-bug
難度 2/5 1-3 小時 新手友好度 76/100
-
stdlib topic-email type-feature
難度 2/5 1-3 小時 新手友好度 70/100
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 65/100
qgis/QGIS-Documentation#11275 ·
-
bug priority:normal ready-for-dev
難度 2/5 1-3 小時 新手友好度 88/100
OpenHands/extensions#626 · 1 則留言 ·
-
難度 1/5 1 小時以內 新手友好度 90/100
CSCfi/sd-search-api#39 ·
-
難度 1/5 1 小時以內 新手友好度 90/100
-
難度 2/5 1-3 小時 新手友好度 68/100
StevenBlack/hosts#3255 ·