Skip to content

question(pcapng): should the Journal Export binary-field clamp go strict like #1325? #1406

Closed

Description

@JarryShaw

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.

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.

Activity

  1. added
    questionIssues asking how something works rather than reporting a defect
    needs: decisionWaiting on the maintainer to decide — not blocked by other work
    on Oct 8, 2026
  2. moved this to Needs decision in PyPCAPKiton Oct 8, 2026
  3. JarryShaw commented on Oct 8, 2026

    @JarryShaw
    OwnerAuthor

    take (1)

  4. JarryShaw commented on Oct 8, 2026

    @JarryShaw
    OwnerAuthor

    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.

  5. added
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    and removed
    needs: decisionWaiting on the maintainer to decide — not blocked by other work
    on Oct 8, 2026
  6. JarryShaw commented on Oct 8, 2026

    @JarryShaw
    OwnerAuthor

    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.

  7. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 8, 2026
  8. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 8, 2026
  9. added this to the PyPCAPKit v1.5 milestone on Oct 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionIssues asking how something works rather than reporting a defect

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions