Repository navigation
fix(spreadsheet): close XLSX DTD pre-scan bypass via declared encodings - #39
Merged
Merged
Conversation
The DTD pre-scan decoded the prolog as UTF-8/UTF-16 only, while expat honours any declared encoding (cp037, utf-32, latin-1...), so a DOCTYPE in such a member reached the parser. Reject prefixes that are not valid UTF-8/UTF-16, reject XML declarations with other encodings, and make expat itself raise FormatError on DOCTYPE/ENTITY declarations. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
O que mudou
Correção de segurança em
namescommons.spreadsheet(leitor de XLSX): a pré-checagem de DTD decodificava o prólogo só como UTF-8/UTF-16, mas o expat respeita a codificação declarada na declaração XML e, via codecs do Python, aceita outras (cp037/EBCDIC,utf-32,latin-1e demais de byte único). Um<!DOCTYPE/<!ENTITYescrito assim passava pela pré-checagem e chegava ao expat (diferencial de parser).Manutenção, sem spec nova. Atualizados ADR 0005 (consequências) e spec 003b R1.4.
encodingdo XML só pode ser ausente, UTF-8 ou UTF-16 (sem diferenciar maiúsculas; hífen opcional); outra coisa éFormatError.FormatError: UTF-32, EBCDIC, bytes nulos fora de UTF-16, UTF-8 inválido.StartDoctypeDeclHandlereEntityDeclHandlerlevantamFormatErrorcom arquivo e membro.Como foi verificado
uv run pytest -q); os dois passos offline da CI rodam e geram os CSVs esperados.Decisão tomada sozinho
O
ET.XMLParserem C (padrão no CPython 3.12) não expõe.parser(o expat), então não dá para instalar os handlers nele. O leitor passou a usarxml.parsers.expatdireto comET.TreeBuilder, gerando eventos start/end em blocos de 64 KiB (substituiET.parseeET.iterparse; mesmo tipo de elemento, mesma leitura em fluxo). Custo se estiver errada: ~60 linhas próprias no lugar de duas chamadas da biblioteca padrão; reverter é local ao módulo. Também: declaraçãoutf8(sem hífen) passa na pré-checagem, mas o expat não lê conteúdo multibyte com esse nome e o resultado éFormatErrorde XML ilegível, sem risco.O mesmo código foi portado para BenchCommons/tools-dataset; a correção lá é feita à parte.
🤖 Generated with Claude Code