Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix use of a mismatching unicode path extra field in zip unarchiving #167

Merged
merged 2 commits into from Apr 12, 2021
Merged

Fix use of a mismatching unicode path extra field in zip unarchiving #167

merged 2 commits into from Apr 12, 2021

Commits on Apr 11, 2021

  1. Tests for proper use of unicode path extra fields in zip unarchiving. 

    One of them currently failing due to a bug, to be fixed in the next commit.

Two test files included, one with the EFS bit (language encoding flag) set,
the other without. Only efsclear.zip is used in tests because the zip spec
does not specify which prevails when both the bit is set and an extra field
is present - plexus-archiver and all other unarchivers I've tried ignore
the extra field in that case.
    @cwalther
    cwalther committed Apr 11, 2021
    Copy the full SHA
    cf44395 View commit details
    Browse the repository at this point in the history

  2. Fix use of a mismatching unicode path extra field in zip unarchiving. 

    The zip spec (§4.6.9) says that a unicode path extra field is only to be
used when its CRC matches the current file name. Using it unconditionally,
as introduced in a080e0a, is wrong. Commons.compress already does it right
internally, no need to do anything here.

The bug affected extracting until 2aec2ba as a side effect replaced use of
fileInfo.getName() by ze.getName(); recently only direct use of FileInfo,
e.g. in file selectors, was affected.
    @cwalther
    cwalther committed Apr 11, 2021
    Copy the full SHA
    1f51bb2 View commit details
    Browse the repository at this point in the history