Skip to content

archive: Reject members with both a PAX path and a GNU long name - #488

Open
darshan-mog wants to merge 1 commit into
composefs:mainfrom
darshan-mog:pax-gnu-longname-ambiguity
Open

darshan-mog wants to merge 1 commit into
composefs:mainfrom
darshan-mog:pax-gnu-longname-ambiguity

Conversation

@darshan-mog

Copy link
Copy Markdown

A member can be described by both a PAX path record and a GNU LongName entry (likewise linkpath and LongLink). tar-rs always preferred the GNU value, while libarchive and Python's tarfile apply whichever extension comes last. With the PAX header first (x path=paxname, L gnuname, file), bsdtar and Python extract paxname and tar-rs extracts gnuname, so a scanner and an extractor can disagree on where a file lands. This is the same parser-differential family as GHSA-3cv2-h65g-fgmm.

Neither GNU tar nor our Builder emits both for one member, so error out as astral-tokio-tar already does rather than pick one. The new test covers both orders for path/LongName and linkpath/LongLink and checks that astral-tokio-tar rejects the same archives; it fails without the change.

A member can be described by both a PAX `path` record and a GNU
LongName entry (likewise `linkpath` and LongLink). tar-rs always
preferred the GNU value, while libarchive and Python's tarfile apply
whichever extension comes last. With the PAX header first, bsdtar and
Python extract the PAX name and tar-rs extracts the GNU one, so a
scanner and an extractor can disagree on where a file lands. This is
the same parser-differential family as GHSA-3cv2-h65g-fgmm.

Neither GNU tar nor our Builder emits both for one member, so error
out as astral-tokio-tar already does rather than pick one.

Assisted-by: AI

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant