Problems with appimageupdatetool with Fedora Silverblue 35 x64 - GitHub API request failed!

[zandorsp]

I'm having a bug:

[zandor@leopard Applications]$ ./appimageupdatetool-x86_64.AppImage --self-update Checking for updates... Fetching release information for tag "continuous" from GitHub API. GitHub API request failed! Could not find any artifacts in release data. Please contact the author of the AppImage and tell them the files are missing on the releases page. ZSync URL not available. See previous messages for details. Update check failed, exiting!

with -d parameter:

[zandor@leopard Applications]$ ./appimageupdatetool-x86_64.AppImage -d --self-update Fetching release information for tag "continuous" from GitHub API. GitHub API request failed! Could not find any artifacts in release data. Please contact the author of the AppImage and tell them the files are missing on the releases page.

Parsing file: /var/home/zandor/Applications/appimageupdatetool-x86_64.AppImage AppImage type: 2 Raw update information: gh-releases-zsync|AppImage|AppImageUpdate|continuous|appimageupdatetool-*x86_64.AppImage.zsync Update information type: ZSync via GitHub Releases Failed to assemble ZSync URL. AppImageUpdate can not be used with this AppImage.[zandor@leopard Applications]$

Version info: [zandor@leopard Applications]$ ./appimageupdatetool-x86_64.AppImage --version appimageupdatetool version 1-alpha (commit 97645f5), build 40 built on 2021-11-10 17:47:46 UTC

[zandor@leopard Applications]$ rpm-ostree status State: idle Deployments: ● fedora:fedora/35/x86_64/silverblue Version: 35.20211111.0 (2021-11-11T00:45:51Z) Commit: 494f5d1832b2bf93265e909019fa0a4db51de1450f89c50cbfbffe816bdac41d GPGSignature: Valid signature by 787EA6AE1147EEE56C40B30CDB4639719867C58F

[probonopd]

Please retry again tomorrow and see whether the problem persists. Sometimes GitHub has outages and/or IP ranges may run into usage limits.

[TheAssassin]

You can also retry with export CURLOPT_VERBOSE=1, which causes appimageupdatetool to print all information around the HTTP(S) requests it makes.

[zandorsp]

Still not good:

[zandor@leopard Applications]$ export CURLOPT_VERBOSE=1 [zandor@leopard Applications]$ ./appimageupdatetool-x86_64.AppImage --self-update Checking for updates... Fetching release information for tag "continuous" from GitHub API. GitHub API request failed! Could not find any artifacts in release data. Please contact the author of the AppImage and tell them the files are missing on the releases page. ZSync URL not available. See previous messages for details. Update check failed, exiting! [zandor@leopard Applications]$ ./appimageupdatetool-x86_64.AppImage -d --self-update Fetching release information for tag "continuous" from GitHub API. GitHub API request failed! Could not find any artifacts in release data. Please contact the author of the AppImage and tell them the files are missing on the releases page.

Parsing file: /var/home/zandor/Applications/appimageupdatetool-x86_64.AppImage AppImage type: 2 Raw update information: gh-releases-zsync|AppImage|AppImageUpdate|continuous|appimageupdatetool-*x86_64.AppImage.zsync Update information type: ZSync via GitHub Releases Failed to assemble ZSync URL. AppImageUpdate can not be used with this AppImage.[zandor@leopard Applications]$

[gagahpangeran]

If you are using appimageupdatetool from this repo, probably this is the same issue that I investigated on https://github.com/AppImage/AppImageUpdate/issues/184 because fedora ssl certificate is on different location.

You can try symlink the certificate with this command and see if this workaround works or not.

sudo ln -s /etc/pki/tls/certs/ca-bundle.crt /etc/ssl/certs/ca-certificates.crt

[Morganlej]

Thank you. The exact same linking works on Mageia 8 too.

@developers: it would be nice it it could tell when it dont find the cert file Hmmm even better, why not include it. The idea with Appimage is it should be mostly self contained, especailly on things that differ between distros.

[gagahpangeran]

@probonopd @TheAssassin sorry for mention, I think the workaround for this issue and #184 should be documented somewhere for people that using the binary from this repo and their distro cert file is not located in /etc/ssl/certs/ca-certificates.crt. Of course the better solution is to fix the issue.

[zandorsp]

Ok with: sudo ln -s /etc/pki/tls/certs/ca-bundle.crt /etc/ssl/certs/ca-certificates.crt

[brianredbeard]

Hmmm even better, why not include it. The idea with Appimage is it should be mostly self contained, especailly on things that differ between distros.

@Morganlej this gets at the heart of being clear about who is the target user for the tool. As someone who has worked extensively in building Linux distributions, the choice of which SSL certificates should be allowed is generally not a concern of the application (especially with free/libre/open source software) and instead one of the user.

In this sense, if the developers of AppImageUpdate/appimageupdatetool began shipping their choice of SSL certificates the burden of security has been actively taken from the user and now is on the shoulders of the developers. This also means that the security of the build systems used by the developers becomes an even greater concern.

[Morganlej]

Good point. Well, there seem to be two commonly used places where distros store certificates, so software should 1) try both 2) if not found at either, ask user to link them to there.

[probonopd]

<rant mode> Distributions putting certificates in random, non-standard locations for no good reasons is... well... one of the many Desktop Linux Platform issues. We have 2022 now and seemingly not even the mainstream Linux distributions can agree where to put certificates. This kind of stuff is imho what is holding back "the year of Linux on the desktop" a lot, and is the reason why I have moved on to using FreeBSD instead, and never looked back. There is only one FreeBSD, and only one location where it puts stuff. Makes life so much easier. The biggest downside of "Linux" is that there is more than one distribution, and they all agree on nothing, for no really good reason.</rant mode>

Well, there seem to be two commonly used places where distros store certificates, so software should try both

"Both" is optimistic. Last time I checked (5 years ago), distributions happened to place them in

"/etc/ssl/certs/ca-certificates.crt",                // Debian/Ubuntu/Gentoo etc.
"/etc/pki/tls/certs/ca-bundle.crt",                  // Fedora/RHEL
"/etc/ssl/ca-bundle.pem",                            // OpenSUSE
"/etc/pki/tls/cacert.pem",                           // OpenELEC
"/etc/ssl/certs",                                    // SLES10/SLES11, https://golang.org/issue/12139
"/usr/share/ca-certs/.prebuilt-store/",              // Clear Linux OS; https://github.com/knapsu/plex-media-player-appimage/issues/17#issuecomment-437710032
"/system/etc/security/cacerts",                      // Android
"/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7
"/etc/ssl/cert.pem",                                 // Alpine Linux

A workaround would be, as you describe, to patch whatever consumes certificates (e.g., libgnutls) to look in all known places. Example of such a patch: https://github.com/darealshinji/vlc-AppImage/issues/1#issuecomment-321041496

A solution would be to put soft pressure on distributions to agree on something basic like this. It's about time. So personally I tend to test stuff on Debian/Ubuntu and if it works there but not on another distribution, treat it as a fault of that other distribution. (Just my 2 cents though.)

More on this topic: https://gitlab.com/probono/platformissues/#certificates (also check the other Desktop Linux Platform Issues on that page).

[TheAssassin]

Building cURL ourselves wouldn't be a huge deal for our own builds. But I'd like to know whether we can instruct it during runtime to look into those locations. That'd be much better also for tools using AppImageUpdate as a library.

[probonopd]

Is curl using libgnutls or something like it? Then most likely that is what needs to be patched... (ideally upstream)

[TheAssassin]

cURL can be built against a variety of backends, including GnuTLS, OpenSSL, mbedTLS, ... It's a lot easier to teach cURL the alternative locations, in case it has an API for it it'll then take care of making the corresponding backend use those alternative locations as well.

[probonopd]

Easier as a short-term fix maybe, but proper would be to teach all the locations to GnuTLS, OpenSSL, mbedTLS,..., no?

Btw, @zyga mentioned on Twitter that he thinks

this list is got further extended by immutable desktops that abuse /var for everything

Is Fedora Silverblue one of them?

<rant mode on> If the Linux Foundation is unable (or unwilling) to moderate distribution vendors to agree on one location, can't they even keep track of where distributions are putting stuff, so that one can get a reliable list of possible locations without having to research it oneself by looking at a gazillion of different distributions all the time? </rant mode off>

[TheAssassin]

No, it's relatively pointless because those are packaged by the distribution usually, and such a search might be a security issue even if done in sensitive contexts (there's one location in most scenarios only, no point in checking others). AppImages are a special use case in that regard.

[nocertloc]

I had spent quite some weeks with finding a solution to the, zsync2: error setting certificates. I have now accidentally stumbled across gagahpangeran's solution with the symbolic link. Thank you. Part of the problem was I didn't know what to search for. Even if I had looked through the issues list on AppImage, seeing the title for #184 about opensuse tumbleweed probably wouldn't make me look at it since I wasn't using tumbleweed. I had just started using an appimage, but was discouraged with having to download the whole application each time for updates. So my issues were, new to appimage, useless error message, not knowing what help to search for.

I understand some of the comments about why each distribution has different locations, why it shouldn't do an exhaustive search of all possible locations, and why the solution is complex to fix. What I would like to suggest, which maybe wouldn't help everyone, but would have helped me, would be for applications such as appimage using the certificates to give a message to the user. For instance, telling me that there's an error in setting certificate verify locations was not useful to me. I went and looked, and sure enough, there was no ca-certificates.crt at /etc/ssl/certs. So now what? Could not the appimageupdate give that error along with a message saying something to the point of: Hint: Different distributions use different locations for storing certificates. You could do an Internet search for distribution ssl certificate locations. Then create a symbolic link for your distribution.

Or even list the known locations in the message. It may not be a perfect solution, but would have saved me a lot of time and made things nicer.