Leading-space checksum encoding is rejected

[zaniebot]

Summary

tar-framing rejects a checksum field whose octal digits are preceded by a
space.

The reproduction archive is the libarchive compatibility fixture
test_compat_perl_archive_tar.tar. It is accepted by Rust tar, Tokio TAR,
CPython tarfile, Go archive/tar, and JavaScript tar-stream; all five expose
the same five-byte regular member named file1.

Tested with tar-codec revision
1ac1199559a1b96f0f953ac99520ccc296503808.

Observed behavior

The checksum field is 11123\0. The stored value matches the header, but the
archive is rejected with:

at byte 0: invalid tar checksum: stored None, computed 4691

Expected behavior

Consider permitting leading space padding before checksum digits.

If rejecting this established encoding is intentional, it would be useful to
list it as a compatibility limitation.

Impact

This is an interoperability issue, not an extraction vulnerability. It affects
real compatibility fixtures rather than only a synthetic edge case.

[woodruffw]

I think our current behavior here is correct. pax says:

The chksum field shall be the ISO/IEC 646:1991 standard IRV representation of the octal value of the simple sum of all octets in the header logical record. Each octet in the header shall be treated as an unsigned value. These values shall be added to an unsigned integer, initialized to zero, the precision of which is not less than 17 bits. When calculating the checksum, the chksum field is treated as if it were all characters.

In other words the checksum itself is required to be octal values, with no leading non-octals.

(We could perhaps support this as a compatibility policy, but I don't think we should do it until a real non-test archive is actually broken by it.)