Summary
tar-framing rejects a leading plus sign on positive PAX numeric values.
The reproduction archive contains uid=+1. It is accepted by
Rust tar, Tokio TAR, CPython tarfile, Go archive/tar, and JavaScript
tar-stream; all five expose the same empty regular member named file.
Tested with tar-codec revision
1ac1199559a1b96f0f953ac99520ccc296503808.
Observed behavior
The PAX extension is rejected with:
at byte 0: invalid pax uid value: "+1"
The same rejection occurs for leading-plus gid, size, and timestamp values.
Expected behavior
Consider accepting an optional leading + on otherwise valid positive decimal
PAX numbers.
If unsigned values intentionally require digits only, it would be useful to
document this compatibility restriction.
Impact
This is an interoperability issue, not an extraction vulnerability. The parser
rejects the archive before returning the member.
Summary
tar-framingrejects a leading plus sign on positive PAX numeric values.The reproduction archive contains
uid=+1. It is accepted byRust
tar, Tokio TAR, CPythontarfile, Goarchive/tar, and JavaScripttar-stream; all five expose the same empty regular member namedfile.Tested with tar-codec revision
1ac1199559a1b96f0f953ac99520ccc296503808.Observed behavior
The PAX extension is rejected with:
The same rejection occurs for leading-plus
gid,size, and timestamp values.Expected behavior
Consider accepting an optional leading
+on otherwise valid positive decimalPAX numbers.
If unsigned values intentionally require digits only, it would be useful to
document this compatibility restriction.
Impact
This is an interoperability issue, not an extraction vulnerability. The parser
rejects the archive before returning the member.