Ideas to make zap a package manager that did the one job about zap HOT 4 OPEN

I agree with you on much of your ideas.

Putting them into checkboxes,

From average user perspective or from ain't nobody got time for that perspective, user wants to:

• install the most recent version of a package (stable, nightly, lts, ...)
• install specific version of a package (v5.0.1, v17.4.2, ...)
• install multiple versions of a package
• install the same version of a package multiple times (multiple installations)
• update package to a specific version
• update all packages to most recent versions
• skip automatic updates of some packages
• remove a package
• manage default package easily (PATH)

What should hold true:

• dependencies are solved for good (shouldn't be a problem for AppImages, since we don't have dependency chains)
• update of a package does not affect dependencies of other packages
• as many as possible operations are instant/fast
• if ambiguous state or unclear action, ask
• allow to force action or force yes to asking

The real issue is package availability and authenticity.

Agreed.

1. Do many companies package their software in appimages?

We can say, 'some' companies still prefer to package their software as appimages. We will need to look for a quantitative value.

2. Is there a way to verify authenticity of appimage?

We can check the authenticity of the appimage, if the appimage is signed using a gpg key

./path/to/appimage.AppImage --appimage-signature

will output the embedded GPG signature, but I have not seen many appimages that are signed. The other method would
probably be to check their md5 and sha256 sums against the AppImages. But, where do we fetch the original sha256sum or md5 hashes to compare against?

3. Is there a way to verify authenticity of the original software which was wrapped to appimage by random community member or distributor?

No.

If companies publish hash sum of every appimage file (or software wrapped in the appimage) and URL of the hash sum (ex. sha512) located at their site with SSL then this is solved without any distribution certificates. Trusted/source-verified package manager (like zap) just checks the hash sum at the URL and compares the hash with locally computed hash of the appimage (or software wrapped in the appimage).

Yes, thats right. But, we don't have anyone willing to maintain such a list, but it would be great if we could have something like that. But I think, the community gotta take an initiative on keeping the source of AppImage and their sha's up-to-date. I am looking at flathub. It would be great if AppImage could inherit something like this - give the recipe, and let the CI build the AppImage. I can guess this would make us closer to a reproducible AppImage!

So, the question is - how to convince companies to publish hash sums for their appimages (or software wrapped in the appimage)? This should be easier than to convince them to provide enough bandwidth to download appimage packages. Appimage packages could be distributed by whatever unsecured systems (ex. non-SSL sites, whatever malwared package repositories) and it would be OK because the hash verification would just work at the user machine.

That's tricky, and I have no answer to that. It is a question I am personally looking for too. In late 2020s, when I was involved with the AppImage community. But, I think Flatpak is something which knows how to handle this properly. When looking at all the points we are talking about, I sometimes wonder if by trying to put all of these features, we are actually trying to build a second Flatpak? It maybe just me, but the idea on Flatpaks, Snaps and AppImages have become closer, except for the fact that the Flatpaks are not executable on its own. Flatpak build system believes in reproducible builds. This might be related issue, AppImage/AppImageKit#297

Here is a proposal of file standard which allows batch downloads of hashes. The idea of appimages is one app = one file. That means one app = one file = one hash. The format is very simple so it is easy to compose and parse by programmers and easy to read by other humans.

Sounds like a plan. We will need to get that idea over here first: https://github.com/AppImage/AppImageSpec. Apps like zap, appimagetool (tool used to build appimages), all follow (or try to follow) this spec. So, if you can get the idea accepted over there, then this issue will become a piece of cake.

from zap.

From average user perspective or from ain't nobody got time for that perspective, user wants to:

* [x]  install the most recent version of a package (stable, nightly, lts, ...)

* [x]   install specific version of a package (v5.0.1, v17.4.2, ...)

* [ ]  install multiple versions of a package

* [ ]  install the same version of a package multiple times (multiple installations)

* [x]  update package to a specific version

* [x]  update all packages to most recent versions

* [ ]  skip automatic updates of some packages

* [x]  remove a package

* [x]  manage default package easily (PATH)

install multiple versions of a package

I think support of multiple versions in OS is useful because sometimes user wants to try new version but also use older version and does not want to reinstall things repeatedly. Another case is - in some version in GIMP or Krita there was a bug in some action that crashed the program without saving file. How could be that solved easily by average user? Simply by choosing which version of program to run for a specific graphic project.

Multiple versions of a package are implemented by design by AppImage format already. However, proper management of AppImage files to prevent the files to be scattered all over the filesystem is missing from the specification. So this is decided by package managers and therefore all handling is let for package managers.

In MacOS, the default location for .app files is Applications. To have more versions available and integrated (app list, search, ...) is easy - user just renames one file and moves it to the default Applications folder.

In Windows OS, users can almost always install multiple versions of software to different folders to have multiple installations, so it is more difficult to have more versions than in MacOS but it is easy. If integration fails, users just clicks and creates a shortcut.

With AppImage, there is expectation that multiple versions works similarly to iOS - that is true, they works similarly at format level. But they do not integrate and do not provide accessible default location to allow manual management. Package managers that will implement integrations and default locations and not implement multiple versions will break expectation of average user to use multiple versions of software easily.

install the same version of a package multiple times (multiple installations)

I agree that this is not so useful in practice now, but I think about it like this: AppImage format supports multiple installations of the same version of package by design. Just filesystem restricts that the same versions must be named differently in one folder or be in separate folders. The installation process by package managers (search+download+verify+integrate) should mirror all existing properties of AppImage file - including the possibility to just have two same program versions in different locations. In the future it could be a common practice to choose multiple partitions to install and manage software. If a package manager supports multiple versions then multiple installations could be for free with proper implementation.

I like that NIX stores software like this:
/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/

In NIX that hash will not change after uninstall and reinstall, however maybe each installation of AppImages should have own ID or random hash in filesystem path. Then multiple files relevant to the installation can be stored there. For example, logs of that installation, info about SSL certificate that was used during download, hash of the AppImage in read-only file owned by root... In short, installation should exist as entity.

skip automatic updates of some packages

I think this is important because when I install specific version of a software or when I install newest version of a software, sometimes I want to just use that version and do not update automatically. Reasons can vary - for example I am testing just that version or I know that just that version is the last appropriate version for my usecase. Of course, info can/should be output to user about software with disabled updates.

What should hold true:

* [x]  dependencies are solved for good (shouldn't be a problem for AppImages, since we don't have dependency chains)

* [x]  update of a package does not affect dependencies of other packages

* [ ]  as many as possible operations are instant/fast

* [ ]  if ambiguous state or unclear action, ask

* [ ]  allow to force action or force yes to asking

as many as possible operations are instant/fast

I had experience with nix-env -q (like apt search) and it is very slow because it looks like it queries remote database each time. I like the way of apt because it caches content with apt update. It is very small probability than remote content of apt which is also relevant to me gets updated while I am working with apt.

That is my view of ideal package manager.

from zap.

If companies publish hash sum of every appimage file (or software wrapped in the appimage) and URL of the hash sum (ex. sha512) located at their site with SSL then this is solved without any distribution certificates. Trusted/source-verified package manager (like zap) just checks the hash sum at the URL and compares the hash with locally computed hash of the appimage (or software wrapped in the appimage).

Yes, thats right. But, we don't have anyone willing to maintain such a list, but it would be great if we could have something like that. But I think, the community gotta take an initiative on keeping the source of AppImage and their sha's up-to-date. I am looking at flathub. It would be great if AppImage could inherit something like this - give the recipe, and let the CI build the AppImage. I can guess this would make us closer to a reproducible AppImage!

I think that community maintained hashes are much better state than the current state where just software packages are community maintained. Hashes alone (without URLs to hashes) would be very practical to do audits with if git repo is cloned / distributed by community.

However ideal solution would be that hashes are placed at website owned by producer of the software and package manager just downloads the hash when installing software and community distributors just include hash URLs.

I created this issue - I know that is not the repository of specification, but it is big distributor of AppImages AppImage/appimage.github.io#2830

from zap.

Yes, flathub recipes look good because they are configs... But they allow array of post install scripts from I saw and also even Krita is community-maintained on flathub when at the same time Krita authors publish their own genuine AppImage release here https://krita.org/en/download/krita-desktop/

GIT repo just provides some community eyes but it adds one more trusted and attackable infrastructure into the distribution chain.

AppImages are meant to not contain any recipes:

If a third party (the distribution’s “maintainer”) packages the application for inclusion in the distribution, the third party may make unintended changes to the application not authorized by the original author. This has led to some application authors to ask Linux distributions to no longer distribute their software because they did not like the changes.
https://docs.appimage.org/introduction/advantages.html

They should be packaged by software author. The remaining and unsolved problem is how to verify that some random AppImage on torrent or distribution website was really build by its software author.

This is not exclusive to AppImages. If software author offers .deb file or tar.gz2 or source files then the building process to AppImage could be done locally by package manager and the hash URL can point to that .deb / .tar.gz2 / source file zip...

Reproducible builds are good, but very complex for all parties involved. Also they solve a different problem as hashes. Hashes solve that I run the exact same program that software author produced and reproducible builds solve that someone else build open-source software the same way as me.

from zap.