Segfault when trying to download runtime on FreeBSD and CentOS 7.9

[probonopd]

RevoOne-RL85% uname -a
FreeBSD RevoOne-RL85 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC amd6

RevoOne-RL85%  ARCH=x86_64 '/home/liveuser/Desktop/appimagetool-x86_64.AppImage' '/home/liveuser/Desktop/Inkscape.AppDir' 
appimagetool, continuous build (git version bfe6e0c), build 92 built on 2023-07-16 13:25:42 UTC
WARNING: zsyncmake command is missing, please install it if you want to use binary delta updates
WARNING: appstreamcli command is missing, please install it if you want to use AppStream metadata
/home/liveuser/Desktop/Inkscape.AppDir/org.inkscape.Inkscape.desktop: hint: value item "VectorGraphics" in key "Categories" in group "Desktop Entry" can be extended with another category among the following categories: Graphics;2DGraphics
Using architecture x86_64
/home/liveuser/Desktop/Inkscape.AppDir should be packaged as Inkscape-x86_64.AppImage
AppStream upstream metadata found in usr/share/metainfo/org.inkscape.Inkscape.appdata.xml
Generating squashfs...
Downloading runtime file from https://github.com/AppImage/type2-runtime/releases/download/continuous/runtime-x86_64
zsh: segmentation fault  ARCH=x86_64 '/home/liveuser/Desktop/appimagetool-x86_64.AppImage' 

Can be reproduced using a Live ISO from https://github.com/helloSystem/ISO/releases/tag/experimental-13.2

[probonopd]

The segfault does not happen when passing in a runtime with --runtime-file.

[probonopd]

@TheAssassin maybe we should just call curl and/or wget from the system and call it a day?

[rodlie]

Also segfault on Linux.

---

btw, I expect appimagetool to include the runtime (as in previous builds). I don't want my (long) build process to all of the sudden download a binary and possibly break due to network/download issues, or the runtime is broken for some reason.

It's also a major security concern. The build process downloads an unknown binary and inject that into something you distribute to users.

I have no problems using --runtime-file=, but I think the old way was preferred (and more secure).

[probonopd]

@TheAssassin please let's take this into consideration. I have to agree with @rodlie.

[TheAssassin]

It's also a major security concern.

I disagree.

The build process downloads an unknown binary and inject that into something you distribute to users.

Well, 99% of all users download the binary from GitHub directly without any means of verification. There is no difference to just downloading the runtime from GitHub as well.

(and more secure).

Not really, at least for the vast majority of users.

@TheAssassin please let's take this into consideration. I have to agree with @rodlie.

You're ignoring alternative solutions at this point in favor of a rightfully obsoleted setup that caused trouble all the way. I wouldn't mind adding some cryptographic verification (indeed, I'm very much for this option in general, even for the CLI variant).

All of this is off topic, though. You should open a new issue.

[rodlie]

The reason was that I updated the appimagetool and all of the sudden it starts downloading stuff, this is not expected behavior based on previous versions and should be documented somewhere that the application downloads additional resources during use (if this is documented it should be more visible).

Anyway, do whatever you want. I will replace appimagetool with a simple shell script.

On-topic: it segfaults on CentOS 7.9.

[TheAssassin]

P.S.:

btw, I expect appimagetool to include the runtime (as in previous builds)

The reasons I'm objected to this are manifold, but I am unwilling to reiterate all the arguments, honestly. There was a really long discussion back when we moved appimagetool into this repository about it. After a long back and forth, the better arguments won, leading to this situation. That is not an excuse for not actually using cryptography to verify the downloaded runtime See #44.

[TheAssassin]

and more secure

I had a quick glance at the build.sh (which I wanted to do with CMake, as it'd make a lot more sense, but it was agreed on that @probonopd will have to take care of this mess) and it downloads plenty files without any verification. One should add some file hashes there.

[TheAssassin]

@rodlie please open a new issue.

[TheAssassin]

Fixed by #45.

[probonopd]

@rodlie please retest. I tested it successfully on CentOS 7.9 (and on FreeBSD 14.0-RELEASE/helloSystem). We will document the need to either provide an already-downloaded runtime, or have appimagetool download the latest one automatically.