AppStream validator gives wrong results and can't be disabled about go-appimage

[ximion]

This is before we even get to the issue of offline building, or whether go-appimage should silently be making network requests in a way that cannot be disabled.

Passing --no-net to appstreamcli unconditionally probably makes sense, or only allow network access when the network is confirmed working and URL validation is desired.

[ivan-hc]

I've built more than 60 AppImages in my repositories and now I switched all my workflows to this new fantastic version of appimagetool, so thanks @probonopd !

I had the AppStream error only in five (5) of them, but I've solved by removing the content of /usr/share/metainfo

[probonopd]

Currently we are simply calling it the "static runtime". But maybe there will be one day a type 3 (or version 3 of the spec) that will require the runtime to be static (= not require libfuse).

[ximion]

Since which version is --no-net supported?

Pretty much forever, since validate existed. There's no version without it.

[pbs3141]

It seems the system version of appstreamcli is v1.0.1 while the bundled version is v0.12.9, which is indeed too old to support these features (by 5 years).

[probonopd]

That the AppStream spec keeps changing has indeed been a constant source of annoyance. Now that it has reached 1.0 state we should probably mandate version 1.0.x of appstreamcli tool, and bundle that one inside the AppImage.

[probonopd]

Well, entirely removing the AppStream metainfo is what I'd like to avoid, but I have to admit that it's been hard to support due to its ever-changing nature. I hope that we can eventually switch to 1.0 and then leave it alone. According to its developer @ximion

what happened with 1.0 was the removal of deprecated features. Removal of deprecated stuff will (very likely) never happen again.

So ideally there would be a test tool that could verify that an AppStream file is 1.0 compatible, while just ignoring any tags that might be introduced after 1.0. So that we could settle with 1.0 and get no warnings or errors once future AppStream versions allow additional tags.

Thinking about it, maybe it'd be easiest to write such a validator myself in Go.

[ximion]

AppStream is backwards-compatible, but has never been (and will not be) forward-compatible. Here, the version of appstreamcli is simply too old to validate metadata that was written for a newer spec version.

[ivan-hc]

@probonopd this is a module i use in my package managers "AM" and AppMan, I've named this option "nolibfuse":

https://github.com/ivan-hc/AM/blob/main/modules/nolibfuse.am

it is using your new version of appimagetool, more details in the two recent releases:

• https://github.com/ivan-hc/AM/releases/tag/6.1
• https://github.com/ivan-hc/AM/releases/tag/6.1.1

and this is a video that shows how it works

AM-6.1-convert-from-type2-to-type3-AppImages.mp4

in brief, it converts the installed Type2 AppImages to Type3.

The thing that amazed me is that Appimages updatable using zsync can be updated without loosing their new Type3 status, also the big ones can be smaller (about 20-30 MB less).

But as I've said, there are some cases where to do this conversion is necessary to remove the content of /usr/share/metainfo (where is available), but in my 60+ Appimages only 5 had to use this workaround, and all of them where built from an old Debian repository on a third parti repo for .deb packages (for example Debian Multimedia). This kind of apps are patched from the mantainer of these .deb packages, so they are not the "original ones" from the upstream... on the contrary, my "Archimages" are all originally built from the upstream and packaged for Arch Linux, so no dirty workaround like this is needed to create the AppImages.

Don't worry, my goal here is to promote the use of the new Type3 standard, to prevent these patches I did.

[probonopd]

@ivan-hc, Type 3, where did you get that from? There is no Type 3 yet.

[probonopd]

AppStream is backwards-compatible, but has never been (and will not be) forward-compatible. Here, the version of appstreamcli is simply too old to validate metadata that was written for a newer spec version.

@ximion, thanks for your explanation.

In the AppImage project, we aim to provide a stable format that can be trusted to also work in the future. Let's say, 10 years down the road I would like to run an AppImage from today, just like I can run an AppImage from 2014 today.

What I mean is: I am looking for a tool that checks that the (essential) tags of (let's say) AppStream MetaInfo 1.0 are there and are valid.

• If the (essential) tags of AppStream MetaInfo 1.0 are there and are valid, then these AppStream MetaInfo files should continue to work indefinitely in the future, as long as the AppStream spec stays backwards-compatible
• If there are extra tags in the AppStream MetaInfo file, then they should simply be ignored during validation since they might become valid in the future (but unused by tools that follow 1.0) (in other words, all currently undefined tags are "reserved for future use" and hence ignored)

Quickly wrote a small validator at https://github.com/probonopd/appstreamlint/; I think I wouldn't need much more than that?

[ivan-hc]

@ivan-hc, Type 3, where did you get that from? There is no Type 3 yet.

I talked to a mutual friend of ours, while I was building an unofficial AppImage for his application (Bottles), and he asked me if my AppImages were Type2 or Type3... then he explained to me about the situation regarding the security holes in libfuse2 ...and this was a couple of months ago. But I only discovered this tool of yours now, and from here I deduced that it was really the Type3 AppImages, given their efficiency.

So you're telling me I'm wrong? Like the GNOME users who, by dint of calling GNOME4 "GNOME 40" gave it this name? lol 😆

However, regarding my workaround, I am very aware that it is a "dirty trick". In fact my goal is to maintain Appstream datas in the AppImage, convincing developers to move their works to what "only I am calling" (at this point) Type3... or Type2.99, whatever you prefer. lol 🤣

[ivan-hc]

@probonopd As far as I'm concerned, this work of yours is excellent as it is. And this is in spite of those who still throw mud at AppImages with the history of obsolete FUSE libraries. If I were you, I would see it as a huge payback. Excellent!

[ivan-hc]

I remember that the previous appimagetool had a -n option to bypass AppStream Validate check. Is there no way to implement it into this version?

[ximion]

From my experience, allowing a "just ignore warnings/validation" flag is a recipe for disaster, unless it can be limited to builds or actions that are guaranteed to never leave the development environment and slip into production.

[ivan-hc]

From my experience, allowing a "just ignore warnings/validation" flag is a recipe for disaster, unless it can be limited to builds or actions that are guaranteed to never leave the development environment and slip into production.

it is this

unless it can be limited to builds or actions that are guaranteed to never leave the development environment and slip into production

for personal use

[pbs3141]

Even if the AppStream validator were updated, I would vote to add the -n option. Here's why:

  W: org.inkscape.Inkscape:243: url-not-reachable
       https://inkscape.org/learn - Unexpected status code: 502
  W: org.inkscape.Inkscape:244: url-not-reachable
       https://inkscape.org/support-us/donate - Unexpected status code: 502

The validator checks whether the urls are valid by making network requests.

So when inkscape.org goes down, which happens time to time when it gets DDOSed (for some reason), or is otherwise under maintenance, CI will break. This is a prime candidate for using the -n option.

This is before we even get to the issue of offline building, or whether go-appimage should silently be making network requests in a way that cannot be disabled.

[probonopd]

Since which version is --no-net supported?