Wholly-space ordinary numeric metadata is rejected

[zaniebot]

Summary

tar-framing rejects an ordinary-header numeric metadata field containing only
spaces.

The reproduction archive uses eight spaces for uid. 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 archive is rejected with:

at byte 0: invalid tar uid field: found [32, 32, 32, 32, 32, 32, 32, 32]

Expected behavior

Consider treating a wholly-space ordinary metadata field as absent, analogous
to the existing compatibility treatment for wholly-NUL fields.

If the distinction is intentional, it would be useful to document it.

Impact

This is an interoperability issue, not an extraction vulnerability. The same
five-peer differential is observable for mode, gid, and mtime.

[woodruffw]

This is uhh...invalid but also maybe reasonable to support? I don't know. We currently support a flavor of this where the member field is all NUL since some tar implementations will do that, I'm not aware of any that emit space-only fields though.

If one emerges, I guess we could fold this into the current allow_all_nul_numeric_fields policy in framing.