Mention that antivirus/firewall programs regularly block "protected" packs

[Phoenix616]

Related problem or need

Antivirus and firewall programs will regularly block downloads of packs that used the options for "protecting" to disregard the zip spec as this is a commen tactic by viruses to obfuscate their payload.

This is especially an issue with server resource packs as there will not be an obvious error to the server admin deploying PackSquash on their packs and even users often don't understand the client log and why a download failed. (Especially in the case when it's not their firewall blocking it but e.g. the dorm one)

Proposed solution

Properly mention the risk of downloads getting blocked and the options being unsuitable for server resource packs in the docs of the options and at any place that "protecting" packs is mentioned in the readme.

Also potentially even add a warning in the log when those options are used.

Alternative solutions

Remove the options that break downloading alltogether to prevent people from accidentally using them without knowing the risks.

Additional context

I regularly have people coming into my Discord (as I offer different plugins to manage server resource packs) with download issues of server resource packs which pretty much always boil down to pack protection mechanisms being used and as soon as the antivirus/firewall is disabled (if they can do that) or tge pack protection is removed it starts to work again. Peopce tend to always be surprised that it would cause such issues which seems to me that it wasn't communicated well enough hence why I finally went and opned this issue.

[AlexTMjugador]

Hello, thanks for reporting the issue! 👋

It's indeed true that the pack protection features offered by PackSquash can sometimes lead to unintended negative consequences, such as issues with pack downloads.

This has been known for a long time, and I've always been open to discussing these potential downsides with anyone who asked on platforms like Discord or even the Spigot forums. In fact, this is mentioned vaguely and indirectly in one of the troubleshooting entries, and the documented options file example with extraction protection enabled explicitly warns that "it might be a bad idea to do these optimizations blindly". Nevertheless, after reviewing the repository documentation again, I agree with your opinion that it doesn't do enough to clearly inform users about the exact possible negative implications of this feature.

To address this, I've added the following excerpt to the documentation for the zip_spec_conformance_level option, along with a new row in the conformance level comparison table about "potential distribution and storage issues". I hope this addition is clear and detailed enough to inform all interested users, including yourself, about concrete relevant drawbacks that ZIP file protection might pose.

New zip_spec_conformance_level option excerpt

While using progressively higher levels of ZIP specification non-conformance can be effective for optimizing a pack's size and protection, the possibly desirable fact that such generated files are not as easily readable by other programs can backfire in several ways. Some ways that happened to users are outlined below:

• Some hosting services attempt to read uploaded ZIP files for validation, and if they cannot do so because the ZIP file is unreadable, the pack may be rejected. For instance, mc-packs.net is a known-affected hosting service, whereas Dropbox, AWS S3, Azure Blob Storage, Cloudflare R2, and most other generic web and file hosting services are unaffected.
• Security software that scans ZIP files may flag such pack files as suspicious because the protection techniques used by PackSquash can also be exploited by malicious actors to bypass security controls. Depending on the software configuration, the pack file may be deleted or made unreadable, causing issues with pack transfer and/or loading. While this typically isn't a problem for most users, who generally connect to the Internet through residential ISP gateways and at most run Windows Defender, some users may have stricter antivirus software, be connected to networks with enhanced security measures (such as those in academic or corporate environments, where DPI firewalls, proxies, and IDS/IPS systems are common), or use services that perform these checks (e.g., attach the pack to an email whose mail servers scan attachments with an affected antivirus solution). See also issue #317 for more on this.
• Different Minecraft clients handle ZIP specification non-conformances differently, meaning a pack that works fine on one client may be rejected by another that is modded, configured differently, or of a different game version. While PackSquash usually hides such differences effectively, and no known Minecraft mods alter the game decompression routines, there's no guarantee that this will remain the case in the future.
• If the original pack files are lost and no backups are available, recovering the optimized files may be more challenging due to the difficulty in extracting them reliably.

In light of these potential drawbacks, we recommend thoroughly testing and analyzing how lower ZIP specification conformance levels might affect you and your users before deploying packs to production or a wider audience. It's also important to ensure you have the capacity to troubleshoot and address the consequences of the decision you make. For what it's worth, the authors of PackSquash have not found evidence of these negative effects causing widespread problems on several established servers.

Now, addressing some of your points more specifically:

[...] Remove the options that break downloading alltogether to prevent people from accidentally using them without knowing the risks.

Unfortunately, I don't find this to be a tenable proposition. The specific unconventional properties of a ZIP file that cause these issues are often unknown in advance and can change over time. While PackSquash could certainly generate ZIP files that fully comply with the specification, it already does so by default (i.e., when the zip_spec_conformance_level is not set to do otherwise). Removing this option would mean completely nuking one of PackSquash's most significant and iconic optimization features, which to me looks like an overly drastic and opinionated response to the relatively small magnitude of the drawbacks. (As mentioned in the excerpt, for most players it works fine. In the cases it does not work, workarounds and different choices can be reasonably made.)

Properly mention the risk of downloads getting blocked and the options being unsuitable for server resource packs in the docs of the options and at any place that "protecting" packs is mentioned in the readme.

Since the README already states that ZIP protection is disabled by default because it requires "informed decisions to be made by the user", and the specific method for enabling it is documented only in the "Options File" wiki article where I added the aforementioned excerpt, I believe the disclaimer is easy enough to notice when reading the documentation. I don't think repeating it more would help users more than it would cause visual clutter and increase the documentation maintenance burden of keeping each instance of the recommendation consistent with each other.

Also potentially even add a warning in the log when those options are used.

Given all the documentation hoops users are supposed to go through before setting zip_spec_conformance_level to the affected values, I don't think nagging them about their own decision any further is warranted. In my opinion, warning logs are supposed to indicate actionable, user-relevant potential software degradation or problems, and it's not a configuration problem for PackSquash or the pack itself that the user explicitly decided to set that option despite the warnings in the documentation.

I regularly have people coming into my Discord (as I offer different plugins to manage server resource packs) with download issues of server resource packs which pretty much always boil down to pack protection mechanisms being used and as soon as the antivirus/firewall is disabled (if they can do that) or tge pack protection is removed it starts to work again.

Would you mind elaborating on the frequency and root cause analysis of these issues? While it's true that pack protection can be a very legitimate cause of the problems you describe, I've found that people are often quick to attribute issues to "pack protection mechanisms" when they might actually be due to other factors, such as server or pack deployment misconfigurations, or unrelated PackSquash bugs like shader optimization issues. Additionally, I'm under the impression that pack download issues genuinely caused by ZIP file protections are relatively rare (to quantify my impression, let's say I think it happens with 1 in 300 players). However, your insights could help refine this perception and the documentation further 👍

Feel free to let me know your thoughts about these documentation changes, or even get in touch over Discord if you want to discuss the topic further!

[AlexTMjugador]

Since I haven't received any feedback on the changes I made to the documentation over the past two weeks, I'll assume the issue has been resolved to everyone's satisfaction. If there's anything else that needs to be addressed, please let me know.