watch out for fake appimages on appimage hub

[wendy-lebaron]

be careful what you download. from internet even from sources. "that look like they're fine." joke programs abound.

i just downloaded from here:

mpv player

mpv is a free (as in freedom) media player for the command line. It supports a wide variety of media file formats, audio and video codecs, and subtitle...

www.appimagehub.com

supposedly this is "mpv". after downloading it. and unpacking it. i became dismayed that the local "usr/bin" had "l3afpad" executable instead. further, the "root" level of the unpacked directory. had a 52mib file called "padding".

i didn't try to run the executable. because "readelf" program said it required "glibc" 2.38. i'm currently on debian "bookworm" with mate desktop. so the "glibc" is two notches too high. otherwise i should be glad i couldn't run it.

i don't know who is foolish enough. or miserable and able to get internet access. to do such a thing. i think i should have known better. i really wanted the new release of "mpv" that came out a few months ago. but i would have to compile it. which is a problem. since none of the linux operating systems. that i have around. could successfully compile something. much more complex than what requires "sdl2", "ncursesw" and stuff like that. preferably "c" only programs, no "c++", no "rust". especially as little as possible of python. because of my slow internet connection. i cannot use "pip" in python. keeps giving up after downloading 10mib or so. it's also github's fault.

this is lowering my faith in appimages entirely. then the thing about "snaps" being compromised. by even more people who don't know. how fortunate and privileged they really are. even to have a computer with internet access. try living in some african or asian, or central or south american country. where someone has to worry about eating and dressing. and he/she could ask, "what is computer?"

 

[Condobloke]

52mib file called "padding".

That wasn't very 'original' on their part....

 

[KGIII]

This sounds interesting, and I'd like to know more.

What was in this 'padding'? How do you know that it's 'fake'?

 

[MikeWalsh]

@wendy-lebaron :-

Hm. I've not heard of this kinda behaviour before.....an' I'm a BIG fan of AppImages.

AppImageHub is mostly 'supplied' with packages by a handful of 'regulars' from the AppImage packaging community.....and these guys have never been anything other than honest. Mind you, the platform is open to contributions from anyone, so I guess bad actors are bound to sneak in from time to time.

If you want an MPV AppImage - that will literally run anywhere, irrespective of system (or even type of) glibc, etc - I recently found these:-

Home | Anylinux AppImages

I've tried several, and they'll work even under very old Puppies. They're quite a size, but they DO contain absolutely everything needed (unlike some people, who re-pack standard .deb or .rpm packages, and leave them still 'hunting' around the system for their dependencies.)

That's NOT how they'e supposed to work; the principle is "download once, use anywhere". That's the definition of a 'true' AppImage.

This IS the current build - v0.41.0 - as released on December 21st last year, exactly one month ago. It will even run under something like Alpine Linux, which uses musl, NOT glibc.

I know it works, 'cos I'm in the middle of using it to watch "Terminator : Dark Fate" right now....

(shrug...)


Mike.

 

[gvisoc]

The AppImage @wendy-lebaron linked is fake, it's just a script to show text to the user, that is also included in it as the file appimagehub.txt. I pasted below the contents of the file to save you a click.

The padding file is random garbage, generated with the output of /dev/urandom, for the appimage to have a decent size in comparison to a proper video player, but as I said, this AppImage is some sort of a ranty manifesto --see below. Good catch, @wendy-lebaron

For what is worth, I think AppImages are fine but when downloaded from the original source of the program in question.

!!!DON'T USE APPIMAGEHUB!!!

        .--.         _
       |o_o |       | |
       |:_/ |       | |
      //   \ \      |_|
     (|     | )      _
    /'\_   _/`\     (_)
    \___)=(___/

**Many AppImages on the platform come from unknown or suspicious users.**

On March 18, 2022, DistroTube released a video recommending AppImageHub as a trusted alternative to Flatpak and Flathub. However, AppImageHub is not a vetted or reliable source for AppImages, and users should be extremely cautious when downloading software from it. A clear example of the risks involved is the presence of a pirated "Photoshop CS6 for Linux" AppImage hosted on the site.

When launching this AppImage, the user is greeted with a crude menu resembling the following:

+--------------------------------------------------------+
| Adobe Photoshop CS6 v13.0 EXTENDED «P0RTABL3»  _  □  X |
+--------------------------------------------------------+
| es-ES   es_MX   cs_CZ    da_DK     de_DE      en_US    |
| fi_FI   fr_FR   hu_HU    it_IT     ja_JP      ko_KR    |
| nb_NO   nl_NL   pl_PL    pt_BR     ro_RO      ru_RU    |
| sv_SE   tr_TR   uk_UA    zh_CN     zh_TW      Exit     |
+--------------------------------------------------------+

After selecting a language, nothing functional happens. Instead, the terminal logs show Wine attempting to launch various Windows executables in experimental WoW64 mode:

Not only is this AppImage distributing cracked proprietary software – a serious security and legal concern – it also fails to function at all. In effect, users risk exposing themselves to malware for an application that doesn't even work.

There is even an outdated Electrum Bitcoin Wallet AppImage on AppImageHub, uploaded by a user named "SPESMILO" The AppImage is already about a year and a half old, and there is no mention of it anywhere on Electrum's official GitHub or release channels. While the hash currently matches the official outdated binary, that only reflects the state *right now*. There is no guarantee it will remain identical in the future, and relying on an anonymous third‑party distributor introduces an obvious supply‑chain risk. Nothing prevents "SPESMILO" from publishing a rogue or modified binary later.

Looking further into the video, at around the 5:20 mark, DistroTube showcases his AppImage collection. Most of the AppImages shown date back to December 2020, despite the video being recorded in March 2022. During the demonstration, he downloads LibreWolf from an anonymous AppImageHub user named JCGONRA21, whose profile contains no meaningful information beyond "Juan, USA." The LibreWolf AppImage itself was last updated on 2022‑05‑09, making it outdated and insecure, especially considering the supply‑chain risks inherent in relying on unverified third‑party builds.

Finally, DistroTube's claim that "Flatpaks are centralized" is misleading. While Flathub is the most widely used Flatpak repository, it does not prevent anyone from hosting their own repositories or distributing Flatpaks independently. The ecosystem is not inherently centralized; Flathub is simply the most popular hub within a decentralized system.

Pling method for distributing random executables ain't the way, folks. AppImageHub should be shut down ASAP.

Don't worry, this AppImage contains no malware on its own.
The script you can create this AppImage with:
#!/bin/bash
# Script made on 2025-12-26 20:48 UTC, consult hashes of this date for software downloaded in order to reproduce
set -e

APP=l3afpad
VERSION=1.0
APPDIR="$APP.AppDir"

rm -rf "$APPDIR"
mkdir -p "$APPDIR/usr/bin"

sudo dnf install dnf-plugins-core -y
dnf download l3afpad

dd if=/dev/urandom of="$APPDIR/padding" bs=1M count=52

rpm2cpio l3afpad-*.rpm | cpio -idmv ./usr/bin/l3afpad
mv usr/bin/l3afpad "$APPDIR/usr/bin/l3afpad"
rm -rf usr l3afpad-*.rpm

echo iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAC0lEQVR4nGNhAAIAABkABaSlNawAAAAASUVORK5CYII= \
  | base64 -d > "$APPDIR/l3afpad.png"

cat > "$APPDIR/$APP.desktop" <<EOF
[Desktop Entry]
Name=l3afpad
Exec=l3afpad-wrapper %F
Icon=l3afpad
Terminal=false
Type=Application
Categories=Utility;
\EOF <- remove the slash

cat > "$APPDIR/appimagehub.txt" <<'EOF'
[message]
\EOF <- remove the slash

cat > "$APPDIR/AppRun" <<'EOF'
#!/bin/bash
HERE="$(dirname "$(readlink -f "$0")")"
exec "$HERE/usr/bin/l3afpad" "$HERE/appimagehub.txt"
\EOF <- remove the slash
chmod +x "$APPDIR/AppRun"

~/Programs/appimagetool-x86_64.AppImage "$APPDIR"

echo "Done! AppImage created."

 

[MikeWalsh]

I got into the habit, quite some time ago, of always unpacking AppImages with the

--appimage-extract

.....'switch' BEFORE running them (to examine the contents). This was probably engendered by the publishing of scripts - from one of our senior devs - that allowed Puppy community members to "roll their own" AppImages.

It also transpired that the archiving process for AppImages is remarkably similar to the way in which Puppians have created SFS packages since Puppy's early days...


Mike.

 

[The Duck]

I don't care for AppImage or Flatpak and if forced at shotgun point to use one or the other I'd go with AppImage over Flatpak.

I'd rather use tar files just open them extract them and run them no install needed.

 

[wendy-lebaron]

firstly, i'm not going near a fairly large file. which could be the payload of a virus. it would be pathetic in my case. to run a program. that requires an "overlay" as if it were the 1980's. where there "never" was "enough" ram.

secondly, a program was included in the suspicious appimage. which did not match. what the application was supposed to be.

finally that this fake appimage was included in appimage hub at all. made me definitely have enough of that place. it's bad enough. there are two "contributors" dumping appimages into that site. "i'm only a creator of appimages. i'm not the author of the program." i thought that was sick. from one guy who i felt was working mostly out of desperation. to make that site count for many people. i admit, i was impressed for a while. except the pages taking ages to load on my computer.

i have to add there is an rpg being offered. which is a download of over 1gib. the "author" had posted the page for it. but had to be reminded later. by another user of the site to offer the download. that should have raised a red flag very high for me. otherwise it's a lesson learned.

i'm sorry about my rant at the end of my first post. but i don't like being deceived. i don't know what someone gets out of doing bad things like that. "i have thousands of downloads on my page!" yeah that worked in the decade-2000. i noticed a music plug-in developer who bragged about it. on another forum i belonged to. that later ended up permanently banned. for using an unregistered copy of some software.

 

[The Duck]

I'm not trying to be an AH but a lot of the AppImages on this website are dogs that don't run.

Home | Anylinux AppImages

They will extract but they won't run they appear to be incomplete files is what the error kicks out.

I had to download 3 different ones before I found one that opened and run.

Git Hub is becoming a real disappointment here lately.(sigh)

This is why I stay with Tar files they always work or have for me.

 

[lomszz]

Looks like person has uploaded multiple files there past 4 weeks, between 26 and 27 days, multiple.

 

[MikeWalsh]

@The Duck :-

I've so far only found two that wouldn't run under Puppy.....ANY Puppy, old or new; OBS, and KDEnlive. Mind you, these two I'm not too fussed about, given that they've always been problematic for us in Puppyland.

Most have been successful. For those folks who are bothered about the delay on launch, do bear in mind that these things first have to unpack themselves into /tmp BEFORE they'll launch.....and from the looks of things, these also run through their own built-in version of the glibc before firing-up. Which all adds to the delay.

After Windows, of course, most people tend to get spoilt by just how quickly things DO launch in Linux. Some of these AppImages feel a little like you're regressing back to the days of Redmond's OS....


Mike.

 

[The Duck]

Here's what I'm talking about.
I chose to drop into the music folder for this purpose only.

 

[MikeWalsh]

@The Duck :-

Heh. Not surprising.....were you aware that you've downloaded the ARM version of the package? That's what

aarch

....stands for. That AppImage would run fine under Rasbian on a RaspberryPi.....but it'll never run on an x86 CPU betwixt now & Doomsday. Totally different architecture, y'see.

Of course, it doesn't help that, alphabetically speaking, "aarch" comes before "amd64". This puts it at the top of the download listing, and many people are SO used to the standard, x86_ 64/amd64 download link always being the very first item on any such list that they automatically click on it......often without looking at it too closely.

Even I had to look twice before I realised I was about to download the wrong file!


Mike.

 

[The Duck]

@The Duck :-

Heh. Not surprising.....were you aware that you've downloaded the ARM version of the package? That's what

aarch

....stands for. That AppImage would run fine under Rasbian on a RaspberryPi.....but it'll never run on an x86 CPU betwixt now & Doomsday. Totally different architecture, y'see.

Of course, it doesn't help that, alphabetically speaking, "aarch" comes before "amd64". This puts it at the top of the download listing, and many people are SO used to the standard, x86_ 64/amd64 download link always being the very first item on any such list that they automatically click on it......often without looking at it too closely.

Even I had to look twice before I realised I was about to download the wrong file!


Mike.

No I was not aware that I downloaded the AppImage for ARM.

It doesn't say ARM.

Another reason I don't like AppImage because of improper identification as to what the are.

They should be properly marked as to what they are.

If its for ARM devices it should be marked "ARM".

I'll stay with good old fashion reliable Tar files developed by real developers instead of some wanna be developer.

Thanks for catching that Mike.

 

[MikeWalsh]

@The Duck :-

Ah, it caught ME out on occasion, back when ARM-built packages began to become more common. That's what prompted me to research just what "aarch" referred to.....and I've known to double-check my downloads ever since BEFORE hitting the button.

I can't help but agree with you, though. "aarch" is not exactly 'intuitive'. Actually marking the package "arm64" - similar to "amd64" - would prevent a lot of confusion. It's hardly rocket-science, is it?


Mike.

 

[wendy-lebaron]

i'm surprised linux isn't clever enough about this.

this is like trying to run a 32-bit executable. on 64-bit on a terminal. then it comes back with "no such file or directory." while the executable file name is typed correctly. it's "right there." "wine" executable is the biggest offender. especially when "multilib" was needed. but the system keeps insisting for the 32-bit side to be installed.

the "aarch64" thing. is like developers choosing between "x86_64" and "amd64". to label cpu architecture. not to favor intel or amd. but i accept "x86_64" on one side. and whatever apple computer wants on the other side.

in the future, something else starting with "a". will add to the confusion.

sort of back on topic. i downloaded the "mpv" appimage. works in debian "bullseye". at the end of the program run. it puts a dialog nag. to go update it. in another time. i would have been angry at this. in the very least because it causes another folder. created in "~/.config" to dump only a two-byte file. otherwise, "what else does it do besides update?" "does it do telemetry?" but that would be just me.

 

[KGIII]

Actually marking the package "arm64" - similar to "amd64" - would prevent a lot of confusion. It's hardly rocket-science, is it?

I think one of the reasons they've chosen not to do that is because of how similar those two look. With a quick glance, those two are easily read as one or the other. However, I do see arm64 used from time to time.

I prefer it when it has been properly capitalized, but we don't do that in extensions. Otherwise, it's AArch64. But, yeah, I believe I read that the two you used look too similar. I'd suggest getting used to aarch64, as you're going to see a whole lot more of it.

 

[MikeWalsh]

@KGIII :-

Mm...yah, okay; I can see your point. In one way, I'd be in favour of standardising around "x86_64" and "arm64".....but "amd64" has been so universally used (as a tribute to the very first commercially-viable AND highly successful comsumer-grade 64-bit CPU.....and in my view, it was well-deserved), that I doubt very much that the latter is going anywhere anytime soon.

------oooo000oooo------​

@wendy-lebaron :-

In essence, I agree with you about the WINE 'multilib' stuff. The traditional WINE install has always been an utter PITA, despite that I've been doing it so long that I could run through the procedure with my eyes closed. On top of that, there's the additional hassle of removing the thing cleanly as & when folks decide they don't want it on their system any longer. Sooo.....

.....here's another use-case for AppImages.

There's quite a number of individuals on Github now offering complete builds of WINE, packed in AppImage format. The more enterprising of these have included all necessary 32-bit dependencies along with a totally automatic implementation of the M$ 'SYSWOW64' stuff that allows running the two arches alongside each other, allocating the requisite dependencies as & when necessary.

I get mine from here:-

GitHub - mmtrt/WINE_AppImage

Contribute to mmtrt/WINE_AppImage development by creating an account on GitHub.

github.com

.....then use these to build a completely self-contained 'portable' version of WINE. Scripts 'link' or 'unlink' WINE - along with its 'prefix' - into your system....via 3 sym-links & a copied .desktop entry & icon. Given that these latter items are very simply deleted when not required, it's but a moment's work to completely remove any trace of WINE from your distro. And you have the advantage of being able to 'share' one WINE install between multiple distros, either from a secondary data partition OR separate drive......even a USB flash-drive or external SSD if required.

It works beautifully for us in Puppyland!

~~~~~~~~~~~~~~~~~~~~~​

Given my long-term usage of MooiTech's 'PhotoScape' - a Windows-only photo / graphics editor, and one I've used for more than 15 years - and the fact that I've more storage space than I know what to do with, I built myself a self-contained portable version of the app.

It comprises the WINE 5.11 AppImage plus the 'portable' build of PhotoScape from PortableApps.com. Scripts tie it all together in such a way that launching it initially sym-links WINE into the system (along with a default, CLEAN 'prefix'), and then launches the portable build of PhotoScape (which contains its own independent 'mini-registry'; these things are designed to run completely OUTSIDE of the standard Windows system environment). When finished, closing the app shuts down the portable build of PhotoScape, followed by disengaging WINE itself.....leaving no sign that it was ever there.

~~~~~~~~~~~~~~~~~~~​

It wasn't necessary at all, but I was at a loose end one day.....and thought to myself, "What the hell; why NOT?" I had everything needed, and all it required was my time.....and a bit of patience. An hour later, it was a "done job"..!


Mike.

 

[KGIII]

"x86_64"

That's what I tend to use.

as a tribute to the very first commercially-viable AND highly successful comsumer-grade 64-bit CPU

Indeed! If we strip out the 'consumer grade' clause... (And because I love computer history...)

There was the "IA_64", which was also known as the Itanium. It had some viability in high-end computers (in data centers and in high-performance computers). The weird thing is that the Itanium actually lived until just recently. It survived all the way until 2020. That's mostly an HP thing, though.

As an aside, it was originally an HP thing, before Intel joined in. It survived longer than many people realize. The x86_64 we're all currently used to wasn't released until a couple of years later.

The Itanium was really only used in the data center and for HPC applications. There were some products aimed at regular consumers, but those went nowhere. I was a bit surprised to see it last as long as it did. They mostly ran UNIX stuff, like HP-UX and there was a Solaris build for it. There was Linux on the Itanium. That was marked as 'orphaned' in 2021.

I would definitely not call the Itanium a 'highly successful consumer-grade' anything.