I think is up to the security team to decide if we want to carry the effort of fixing the regressions or if we decide to drop this CVE from NixOS all together.

cc @grahamc @fpletz @domenkozar

I'm +1 on the revert, and following Debian's lead on when they have an updated patch.

staging-next with this is being evaluated on Hydra ATM; it's otherwise idle anyway.

Thanks to @delroth, here's the eval link https://hydra.nixos.org/eval/1532256?full=1#tabs-now-fail

Now, a bunch of those new failures are from depending on things now failing. Let's filter these out (using the browser's dev console).

$('img.build-status[alt^="Dependency"]').parent().parent().remove()
$("#tabs-now-fail .table tr").length

297, this includes the table header, 296 newly failing builds. Of those, only a handful are not related to the zip bomb detection, the overwhelming majority is. In addition, I think it's likely that other failures from the list would have failed the check if it wasn't that they depended on a now failing build.

+1 for reverting.

From a security standpoint it makes no sense to keep this patch in. The only thing it will do is push people to keep their OS out of date because they literally can't install anything that depends on Lua (or pick your favorite cluster of breakage) otherwise.

Just scanned through comments and since it seems this hasn't been mentioned:

The CVE patch we're using explicitly mentions it requires another patch in order to work correctly.

Without this patch I'm observing incorrect flagging of zip's as "zip bombs", with the mentioned prereq it works properly. So I vote we go in that direction?

dtzWill@93a8985 is how I did it, FWIW.

From a security standpoint it makes no sense to keep this patch in. The only thing it will do is push people to keep their OS out of date because they literally can't install anything that depends on Lua (or pick your favorite cluster of breakage) otherwise.

Depends, if these are really broken/vulnerable zip files, it makes sense to put in the work and fix it for good. Other distributions will pick it up sooner or later too.

dtzWill@93a8985 is how I did it, FWIW.

Oh, interesting, maybe this makes sense instead of the whole revert? I did not try this one yet, but looks like debian has it in and see some legit failures too. For example, the jar issues are legit (as per they are using broken archives), as pointed out https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931895#73

Hydra managed to do most of the rebuilds already and basically completed x86_64-linux ones, so for now I would still merge this to master (as it's a faster solution).

• Gradle *.jar files: upstream claims they'll fix them; ATM I'm unable to estimate the impact on NixPkgs
• a Firefox-specific problem can be worked around by yet another zip patch

I still think we don't need to hurry that much with fixing this CVE in master, so we can e.g. spin a separate Hydra jobset to look at our regressions or something, though it seems likely that with dtzWill@93a8985 there will be very few of them (and we can add the Firefox-specific commit, too).