python / python/cpython

xmlrpc.client.dumps() skips argument validation when Python is run with -O

Aberta
#151,532 2 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

stdlib type-feature
Linguagem predominante
Python
Estrelas
77.2k
Forks
36k
Métricas de merge de PRs
Métricas de PR pendentes

Descrição

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:

  • params must be a tuple or Fault instance.
  • methodresponse=True expects 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:

  • TypeError when params is neither a tuple nor a Fault instance.
  • ValueError when methodresponse=True is 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

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Direção de pesquisa

Leia Lib/xmlrpc/client.py e reproduza o comportamento com o script fornecido tanto em uma execução normal quanto com -O. Inspecione a validação em dumps() e, em seguida, adicione cobertura de regressão para parâmetros inválidos e respostas com múltiplos valores, para que o comportamento permaneça consistente sob otimização.

Escrita pelo modelo de indexação a partir do texto da issue.

Avaliação

Stack de tecnologia
python
Domínio
api
Tipo de issue
Bug
Dificuldade
3/5
Tempo estimado
1-2 dias
Status de atividade
Estagnada
Clareza
Claramente especificada
Facilidade para iniciantes
35/100

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.