Skip to content

Full-width checksum field without a terminator #51

Description

@zaniebot

Summary

tar-framing rejects a TAR header when the checksum occupies all eight bytes
of its fixed-width field without a trailing NUL or space.

The reproduction archive 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 checksum field contains the eight octal digits 00011645. Its decoded
value matches the header, but the archive is rejected with:

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

Expected behavior

Consider accepting a checksum when every field byte is an octal digit and the
decoded value matches, even if the field has no explicit terminator.

If the terminator requirement is intentional, it would be useful to list it as
a compatibility limitation.

Impact

This is an interoperability issue, not an extraction vulnerability. A readable
archive can be rejected before its first member is returned.

Metadata

Metadata

Assignees

No one assigned

    Labels

    diff:restrictiveA differential where tar-codec is more restrictive than other parsers

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions