You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
question(pcapng): should the Journal Export binary-field clamp go strict like #1325? #1406
Decision needed: should the systemd Journal Export binary-field clamp go strict as well?
#1398 applies the #1325 ruling (strict everywhere, keep the octets as captured) to every option area, but deliberately leaves out the Journal Export record's binary-field clamp (pcapkit/protocols/schema/misc/pcapng.py:2032-2045). A binary field that declares 100 octets in an entry holding 3 is clamped. The rebuild then differs: 36 octets in, 40 out, the declared length rewritten from 100 to 8, and a 0a appended. A well-formed entry rebuilds exactly.
(2) Leave the clamp. Journal entries are text-oriented, so tolerate and normalise them.
I recommend (1): the clamp breaks the every-round-trip ruling, and keeping the bytes raw still lets extraction continue. Found by the #1398 cross-review. Any change waits for #1398, which owns this file.
Ruling recorded: option (1), strict. The Journal Export binary-field clamp goes the way of #1325. A field whose declared length overruns its entry raises, and the whole entry is kept raw and rebuilt verbatim, so extraction still continues and the round trip is byte-exact.
Blocked until#1398 merges, because it owns schema/misc/pcapng.py. A worker will start then.
Unblocked:#1398 (and #1400) have merged. One worker is taking all the PCAP-NG follow-ups together, #1382–#1384, #1401, #1405 and #1406, because they edit the same pcapng.py files.
Activity
JarryShaw commentedon Oct 8, 2026
take (1)
JarryShaw commentedon Oct 8, 2026
Ruling recorded: option (1), strict. The Journal Export binary-field clamp goes the way of #1325. A field whose declared length overruns its entry raises, and the whole entry is kept raw and rebuilt verbatim, so extraction still continues and the round trip is byte-exact.
Blocked until #1398 merges, because it owns
schema/misc/pcapng.py. A worker will start then.JarryShaw commentedon Oct 8, 2026
Unblocked: #1398 (and #1400) have merged. One worker is taking all the PCAP-NG follow-ups together, #1382–#1384, #1401, #1405 and #1406, because they edit the same
pcapng.pyfiles.fix(pcapng)!: PCAP-NG round-trip follow-ups (#1382, #1383, #1384, #1401…
fix(pcapng)!: keep malformed journal entries and short packet blocks …
fix(pcapng)!: keep malformed journal entries and short packet blocks …
docs(changelog): sixth whole-repo pass over changelog (#1103)
docs(changelog): sixth whole-repo pass over changelog (#1103) (#2209)