[Security] Bump vendored FlatBuffers past v25.12.19 for verifier/memory-safety fixes (coordinated with zlmdb)
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 30/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Ambito
- backend-api-design, build-system, security
Direzione di ricerca
The vendored FlatBuffers submodule is in deps/flatbuffers. The version sync check is in autobahn.check_zlmdb_flatbuffers_version_in_sync() and test_zlmdb_flatbuffers_in_sync. First, update the submodule to the target commit, regenerate Python code and rebuild the bundled flatc. Then, verify the sync with zlmdb and run the FlatBuffers serialization tests. Done when CI passes and the CHANGELOG is updated.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
autobahn vendors FlatBuffers as a Git submodule, currently
deps/flatbuffers at 7e163021e59cca4f8e1e35a7c828b5c6b7915953 (v25.12.19), and also ships a
built flatc. Since v25.12.19, upstream has landed a cluster of verifier-hardening and
out-of-bounds fixes that are directly relevant because autobahn may parse
attacker-controlled FlatBuffers (verifier / reflection / FlexBuffers paths) and the bundled
flatc may be run against untrusted schemas.
Bump the vendored submodule to the latest upstream revision (pinned commit SHA) available at 26.9.1
release time, regenerate any generated code, and rebuild the bundled flatc.
This MUST be coordinated with zlmdb (see the companion zlmdb issue): both vendor FlatBuffers and
autobahn.check_zlmdb_flatbuffers_version_in_sync() + test_zlmdb_flatbuffers_in_sync assert the two
versions are equal. zlmdb is currently at the same commit (7e163021, v25.12.19). Bumping one
without the other turns that test red. Land both to the same target commit.
Why (relevant upstream fixes since v25.12.19)
A Python package scanner will not flag vendored C++, so this is an engineering-review item. Upstream
has addressed, among others:
- FlexBuffers verifier /
ToString()heap-buffer-overflow — a malformed buffer passes
verification and then triggers an OOB read inToString()(upstream issue #9041, reported CVSS 7.5 High). - Reflection verifier hardening against malformed schemas.
- OOB checks in
memcpy_downward. - FlexBuffers OOB protection in
Map::Keys(). - OOB protection in
GetBufferStartFromRootPointer(). - Text-generation OOB fixes.
- Additional verifier hardening for malformed schemas and field IDs.
That is a significant cluster for a serialization library exposed to untrusted input.
What to do
- Pick the target upstream commit (latest stable/tagged, or master at a pinned SHA) at release time.
- Update
deps/flatbufferssubmodule to that commit identical to zlmdb's. - Regenerate vendored/generated Python code as needed; rebuild the bundled
flatc. - Bump the vendored FlatBuffers
__version__accordingly. - Confirm
autobahn.check_zlmdb_flatbuffers_version_in_sync()passes against the coordinated zlmdb bump. - Run the FlatBuffers serialization tests +
test_zlmdb_flatbuffers_in_sync; CI green on CPython + PyPy. - CHANGELOG
26.9.1"Security" entry.
Acceptance criteria
-
deps/flatbuffersat the chosen post-25.12.19 commit, equal to zlmdb's vendored commit. - Version-in-sync check + tests pass; generated code + bundled
flatcregenerated from the new revision. - The verifier/OOB fixes above are present in the vendored revision.
Notes / links
- Companion issue: crossbario/zlmdb — same bump, kept in lock-step.
- Rationale for the coupling is in the
check_zlmdb_flatbuffers_version_in_sync()docstring
(autobahn = data-in-transit, zlmdb = data-at-rest; both must share a compatible FlatBuffers runtime
for Crossbar.io interop). - Part of the 26.9.1 security track (dependency-floor review + #1949 evidence base).
- Lingua principale
- Python
- Stelle
- 2.5k
- Fork
- 767
- Merge medio
- 23h 55m
- PR unite (30g)
- 25
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di crossbario/autobahn-python
-
CI-CD enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
crossbario/autobahn-python#1945 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug CI-CD
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
crossbario/autobahn-python#1932 ·
I maintainer di solito rispondono entro 1 giorno
-
CI-CD enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
crossbario/autobahn-python#1829 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug CI-CD
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
crossbario/autobahn-python#2013 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
crossbario/autobahn-python#1963 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di crossbario/autobahn-python
Issue simili
-
intake mcp-intake needs-ac needs-human-review priority:medium
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
Ikalus1988/MisakaNet#3848 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
521xueweihan/HelloGitHub#4105 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
igormcsouza/bookloud#54 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
aws-samples/sample-per-model-bedrock#526 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
ok-oldking/ok-wuthering-waves#1802 ·
I maintainer di solito rispondono entro 2 giorni