Skip to content

ioncube_loader: stop with a clear error when there's no musl loader for the architecture - #1380

Open
theluckystrike wants to merge 2 commits into
mlocati:masterfrom
theluckystrike:fix/1264-ioncube-musl-arch
Open

theluckystrike wants to merge 2 commits into
mlocati:masterfrom
theluckystrike:fix/1264-ioncube-musl-arch

Conversation

@theluckystrike

@theluckystrike theluckystrike commented Oct 10, 2026 •

Copy link
Copy Markdown

Fixes #1264

On Alpine, installIonCubeLoader builds a -musl URL for every architecture, but ionCube only publishes a musl loader for x86-64. On arm64 the script asks for ioncube_loaders_lin-musl_aarch64.tar.gz. The download server redirects that to an HTML page with a 200 status, so the failure only shows up later as a confusing extraction error.

The same happens for lin-musl_armv7l and lin-musl_x86 on 32-bit Alpine, while lin-musl_x86-64 is a real archive.

Before downloading, the script now reads the final content type of the loader URL with one HEAD request. If it's text/html, it stops with "ionCube does not provide a loader for this platform" plus the URL, and exit code 1. Nothing is hardcoded per architecture, so if ionCube publishes a musl loader for aarch64 later it installs with no change. If the HEAD request itself fails, the script goes on to the normal download.

There's no Docker on my machine, so I ran the function itself in a small sh script with uname and getPackageSource stubbed against the live ionCube server. Alpine aarch64, armv7l and x86 now stop with the message, and Alpine x86-64, Debian aarch64 and the pinned 14.0.0 loader for Alpine 3.12 request the same URLs as before. shellcheck and shfmt with the flags from scripts/invoke-shellcheck and scripts/invoke-shfmt report nothing.

Michael

…tecture

ionCube only publishes a musl loader for x86-64. On Alpine arm64 (and
32-bit) the URL served an HTML page, which then failed at extraction.

Fixes mlocati#1264
@mlocati

mlocati commented Oct 10, 2026

Copy link
Copy Markdown
Owner

What if one day they'll publish a version for those architectures?

ionCube answers a loader it doesn't publish with a redirect to an HTML
page and a 200 status. Check the final content type before downloading
and stop only when it's text/html, so a musl build ionCube adds later for
aarch64, armv7l or x86 works without a change here.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@theluckystrike

Copy link
Copy Markdown
Author

Good point, a fixed list would go stale the day they add one. I pushed 85ac16d, which drops the architecture list.

The script now asks ionCube for the final content type of the loader URL before downloading. When a loader doesn't exist, the URL redirects to an HTML page that still answers 200, so only a text/html response stops the install. A musl build for aarch64 or armv7l would come back as application/x-gzip and install like x86-64 does today, with no change here.

I checked it against the live server. Alpine aarch64, armv7l and x86 stop with the URL in the message, while Alpine x86-64, Debian aarch64 and the pinned 14.0.0 loader for Alpine 3.12 download as before. It costs one HEAD request per ionCube install, and if that request fails for any reason the script carries on to the normal download.

Michael

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Invalid ioncube link for arm + musl

2 participants