Compatibility issues with zlib-ng-compat on various platforms

[Jonathing]

The Minecraft Forge installer uses zlib compression to handle libraries and caching of data. A recent fork of zlib, named zlib-ng, changes some implementation details that were relied on by the installer that can cause hash mismatches or undefined behavior on the systems running it.

I am making this issue to effectively supersede #77 and centralize discussion regarding Installer zlib-ng issues. I'm still not entirely sure how to reproduce this issue, but it has inconsistently happened to me before on Fedora 42 and a handful of others have reported this issue to us.

@LexManos has gone over a few options that we can work with in this comment. It effectively boils down to either changing how we compress data or bypassing parts of the installer generation (i.e. no compression at all or skipping hash checks), each with their own drawbacks. If you want more information on the topic, check out #77's comment thread.

Please link back to this issue when discussing Installer issues involving zlib-ng.

[Trial97]

Here is a Docker image that should reproduce this(to be lost in the Discord):

# Use CachyOS base image
FROM cachyos/cachyos:latest

# Set environment variables for Java
ENV JAVA_HOME=/usr/lib/jvm/java-17-openjdk \
    PATH=$JAVA_HOME/bin:$PATH

# Update package list and install Java 17 (OpenJDK)
RUN pacman -Syu --noconfirm
RUN pacman -S --noconfirm jdk17-openjdk
RUN pacman -Scc --noconfirm

# Example: Add your Java app here
COPY ./forge-1.21.5-55.0.12-installer.jar /app/myapp.jar
RUN java -jar /app/myapp.jar --installServer

[Jonathing]

Yup. Which is why I am yelling at people who leave things in the Discord now. I didn't even know about this one. Thanks for the dockerfile.

[Jonathing]

From Lex (Discord message from May 18, 2025)

---

WSL on ubuntu, with docker installed, this image:

# Use CachyOS base image
FROM cachyos/cachyos:latest

# Set environment variables for Java
ENV JAVA_HOME=/usr/lib/jvm/java-17-openjdk \
    PATH=$JAVA_HOME/bin:$PATH

# Update package list and install Java 17 (OpenJDK)
RUN pacman -Syu --noconfirm
RUN pacman -S --noconfirm jdk21-openjdk
RUN pacman -Scc --noconfirm

services:
  test:
    build: .
    stdin_open: true # docker run -i
    tty: true        # docker run -t
    entrypoint: /bin/sh
    volumes:
      - .:/test

[LexManos]

So, because of how many things this effects, and not wanting to break compatibility with other installers. I was planning on doing this during each of the back porting processes. Basically, the only sane option is to disable compression. Disabling hash checking screws up any concept of validating that things went well. However, to disable compression we have to update every Installer and every tool used by the installers to support STORE instead of DEFLATE. This becomes an issue when it gets back to tools that we do not own. Such as SpecialSource.

With the only use case where this has been an issue is the guy's 'install forge every launch' wrapper. Which he can easily do:

install.processors.forEach(proc -> proc.getOutputs().clear())

And the astounding amount of effort it took to find a reproduction case. Which leads me to think it effects very little/no actual users.

I didn't put it as a high priority.

IF someone can find a way to detect that the user is running using a java version that uses the native compressor, and also an OS that is running a version of ng-zlib (which is where I got stuck last time I tried). Then a "Hey we detected that you're in an environment that hashes break, disabling them for you" function on the installer as a stop-gap would be fine.

[Fealtous]

Just putting here for the purposes of tracking solutions while this is still open:

[Jonathing]

This raises a few more questions than answers. Thanks for keeping tabs on this. I think a good course of action would be to get some docker tests for installer that runs each major distro and each major Java version.