Describe the bug
A systemd journal entry whose last field has no trailing newline absorbs the PCAP-NG block padding into that field's value, silently. Measured on ef859f776:
raw = b'MESSAGE=hello' + b'\x00\x00\x00' # 13-octet entry + the 3 NULs block() appends
SystemdJournalExportBlock.post_process(...)
-> [OrderedMultiDict([('MESSAGE', 'hello\x00\x00\x00')])]The three NUL octets are the block's own 4-octet alignment padding, and they come back as data. No exception, no SchemaWarning, nothing a caller could branch on.
Why the existing guard misses it
pcapkit/protocols/schema/misc/pcapng.py:1857 ends the entry when a line strips to nothing but NULs:
if not line.strip(b'\x00'):
breakThat fires only when the NULs form their own line — i.e. when the entry ended with \n and the padding follows it. With no trailing newline the NULs are part of the final field's line, so the guard never sees them and bytes.strip() does not treat NUL as whitespace.
Expected behavior
Either strip the trailing NULs from the last field's value, or refuse the entry with a ProtocolError from pcapkit.utilities.exceptions. Returning alignment padding as field data is the one option that should not survive.
The format does require the trailing newline, so this is malformed input — but "malformed input silently yields corrupted data" is worse than either alternative, and a caller reading MESSAGE has no way to know the NULs are not the sender's.
Additional context
Found by the cross-review on #793 while checking whether the padding defect that PR describes is genuinely gone. It is — for the newline-terminated case, fixed by #699 (8af2cfda7), which added the NUL-only-line guard. This is the adjacent case that guard does not cover.
Distinct from #704 (every field after the first binary field discarded) and from #723 (the b'\n\n' split shredding binary values), both closed. Related: #793, #791.
Describe the bug
A systemd journal entry whose last field has no trailing newline absorbs the PCAP-NG block padding into that field's value, silently. Measured on
ef859f776:The three NUL octets are the block's own 4-octet alignment padding, and they come back as data. No exception, no
SchemaWarning, nothing a caller could branch on.Why the existing guard misses it
pcapkit/protocols/schema/misc/pcapng.py:1857ends the entry when a line strips to nothing but NULs:That fires only when the NULs form their own line — i.e. when the entry ended with
\nand the padding follows it. With no trailing newline the NULs are part of the final field's line, so the guard never sees them andbytes.strip()does not treat NUL as whitespace.Expected behavior
Either strip the trailing NULs from the last field's value, or refuse the entry with a
ProtocolErrorfrompcapkit.utilities.exceptions. Returning alignment padding as field data is the one option that should not survive.The format does require the trailing newline, so this is malformed input — but "malformed input silently yields corrupted data" is worse than either alternative, and a caller reading
MESSAGEhas no way to know the NULs are not the sender's.Additional context
Found by the cross-review on #793 while checking whether the padding defect that PR describes is genuinely gone. It is — for the newline-terminated case, fixed by #699 (
8af2cfda7), which added the NUL-only-line guard. This is the adjacent case that guard does not cover.Distinct from #704 (every field after the first binary field discarded) and from #723 (the
b'\n\n'split shredding binary values), both closed. Related: #793, #791.