Linux Packages

[trymeouteh]

Please consider packaging the Linux client into the following formats...

AppImage (Works on any distro, portable, entire app is inside a single file (not a folder), easy to install, latest version available)

AUR (Work on arch distros, easy to deploy, safe and secure download, automatic updates, easy to install, latest version available)

Pacstall (Work on debian/ubuntu distros, safe and secure download, automatic updates, latest version available)

Not trying to start a "linux package debate/war" but I have used all of the linux packages out there and I do think these three are the best for the follow reasons above compared to other alternatives such as official arch/debian/ubuntu repos, PPAs, tarballs, snaps and flatpaks.

[MrCyjaneK]

Can be discussed as a part of #255 I believe.

[kinghat]

id say it would benefit the project to pick a linux package that can be distributed through an app store and be distro agnostic. that currently is either flatpak or snaps. imo id take either over any of the alternatives, but if it was down to one or the other, itd be flatpak.

[k4r4b3y]

+1 for the AppImage request. I use feather with its appimage releases. Quite easy to work with them. Just download and run, no need to installa thing.

[woodser]

Probably support for AppImage or anything else needs to be added to the desktop project's gradle build, which packages the application for distribution, in case someone can help with the implementation.

[chaserene]

the problem with installing new software is that it increases the risk of getting your computer compromised, especially if the package comes outside of your distro. you first and foremost need to optimize for sandboxing, so that users can rest assured that whatever they install can gain the least possible control over their systems.

this is especially true in the current setup, where people need to trust Haveno Core to ship safe software and also the operator team that any changes they make are not malicious.

I currently don't know of a practical packaging system that does it better than Flatpak. you/the operator can constrain permissions of the package by default. users can edit those permissions later as they wish. there is a popular Flatpak repository (Flathub) where the operator can publish their flatpak and verify that it comes from them, but they can also set up their own server and repository that users can add, or just release the flatpak as a file. the sandboxing protects the user in each scenario.

if there is a repo, Flatpak can update from it, but users can also disable updates on a per-package basis if that fits their threat model better.

Flatpak also has the benefit of having the framework either installed by default or available from the default repository on basically every major GNU/Linux distro (see https://www.flatpak.org/setup/). this means that, with sane default permissions, users are exposed to negligible risk in installing a Haveno client.

[k4r4b3y]

@chaserene is it true that flatpak requires sudo for the initial install of the program (let's say, haveno)? (see this video for cursory comparison of flatpak vs appimage: https://www.youtube.com/watch?v=3YHIa3le_1k&t=218) If so, that's a big disadvantage for the users of TailsOS and Qubes-Whonix, as TailsOS is made to not rely on sudo as much as possible, while Qubes-Whonix doesn't play comfortably with moving binaries to the root directory (root dirs in QubesOS are read-only and comes from the TemplateVM).

AppImage, on the other hand, works with no sudo necessary, at any point. User just downloads the Haveno.Appimage file and gives it user exec permission and then runs it with ./Haveno.AppImage command.

[woodser]

AppImage would be a nice addition. Maybe worth opening a separate issue and adding a bounty specifically for that.

[k4r4b3y]

Maybe worth opening a separate issue and adding a bounty specifically for that.

I can open a new issue for requesting an AppImage on haveno project's github page, but I don't know how the bounties work here. Do I pledge some amount of XMR for the successful closure of the github issue that I open?

[woodser]

If you open the issue, we can pledge a bounty of 1 XMR, and add to that if there are external donations pledged for it. Please specify any terms if applicable.

[k4r4b3y]

@woodser I would open the issue, however, I am not clear on some technical stuff regarding the bounty criteria for payment, such as:

1. if the appimage gets produced by someone else, other than you (woodser), how can I be sure of its authenticity? How powerful is the appimage packager in potentially spreading malware/malformed software?
2. will the users still be able to compare hashes of the appimage and ascertain its authenticity?

If I get satisfactory answers to such questions, I am willing to pledge +1 XMR on top of your 1 XMR.

[woodser]

if the appimage gets produced by someone else, other than you (woodser), how can I be sure of its authenticity? How powerful is the appimage packager in potentially spreading malware/malformed software?

That's beyond our scope here. What we're paying for with this bounty is the ability for anyone to create an AppImage from the Haveno repo, so any necessary scripts, documentation, or additional support should be added directly to the official Haveno repo. Then third parties running on mainnet (excludes the official repo), can follow those steps to create and distribute an AppImage for their network instance.

will the users still be able to compare hashes of the appimage and ascertain its authenticity?

They should be able to compare the hash against the AppImage released by the operating network to verify it's the same. If the AppImage is deterministically built, it's possible to verify the expected hash independently as well, but that's not a requirement I don't think.

If I get satisfactory answers to such questions, I am willing to pledge +1 XMR on top of your 1 XMR.

We typically require pledges to be donated to the project in order to include it in the advertised bounty, with the option of reimbursement if needed.

[woodser]

@k4r4b3y: how can I be sure of its authenticity?

I forgot to mention that these installers can be built automatically using GitHub Actions, so users can compare the downloadable installers against the build from GitHub Actions to verify their integrity.

Ideally creation of the AppImage (and Flatpak) are part of ./gradlew packageInstallers script so it's part of this existing build process. Probably this should be a requirement for the bounty.

[woodser]

I've opened a bounty for building AppImage automatically: https://github.com/haveno-dex/haveno/issues/1222

[k4r4b3y]

Thanks. I just sent 1 XMR donation to the HavenoDex donation address here.

[Jabster28]

@k4r4b3y

is it true that flatpak requires sudo for the initial install of the program

Nope, you need sudo to install Flatpak (the program) afaik but you can install individual programs with the --user tag and you get all of the same guarantees. See https://docs.flatpak.org/en/latest/introduction.html#reasons-to-use-flatpak :

Rootless install: elevated privileges are not required when installing a Flatpak application or a runtime.

[Jabster28]

Also @trymeouteh for an AUR package, shouldn't that be done outside of the repository? Or are you suggesting that a sample PKGBUILD is made in the repo?

[Jabster28]

@k4r4b3y

if the appimage gets produced by someone else, other than you (woodser), how can I be sure of its authenticity? How powerful is the appimage packager in potentially spreading malware/malformed software?

AppImages support signing with GPG keys (checking the signatures complex though, you might be better off just distributing it with a .sig), but if you're referring to different networks releasing their own AppImages, the binaries have a different signature from woodser's and thus the network admins would need to use their own keys to sign it. That would still let you confirm that it hasn't been edited by anyone aside from the network admins, however.

[chaserene]

is it true that flatpak requires sudo for the initial install of the program (let's say, haveno)? (see this video for cursory comparison of flatpak vs appimage: https://www.youtube.com/watch?v=3YHIa3le_1k&t=218)

@k4r4b3y I can confirm some of the top comments on Youtube and @Jabster28's comment that DistroTube is wrong on the quoted statement. you don't need any privileges to install a Flatpak package. never in my years of Flatpaking did I have to use sudo, not even to add a new remote (=server/app store).

you do need sudo to install Flatpak-the-framework from your distro's package manager (unless it's already baked into the distro), but that's probably obvious, just as the fact that installing Flatpak-the-framework from your distro's package manager carries a much lower risk than running an AppImage you downloaded with your web browser.

for total fairness, I'll point you to the Feather Wallet dev @tobtoht's detailed analysis of the security offered by the different ways of utilizing Flatpak: https://github.com/feather-wallet/feather/issues/47#issuecomment-1657344631

it's a long but worthy read. my conclusion of it is that a Flatpak package as a .flathub file, served with a PGP signature of an established release signing key, is currently superior to any other way of distributing cryptocurrency software.

also allow me a few other remarks.

How powerful is the appimage packager in potentially spreading malware/malformed software?

AppImages offer no sandboxing. it's security-wise equivalent to curl | sh http://.... the binary can do whatever it wants as long as that doesn't require root permissions. which is a lot.

will the users still be able to compare hashes of the appimage and ascertain its authenticity?

comparing hashes to a website is, for our purposes, an insufficient way of proving authenticity. the website can be hacked/domain-jacked/etc. and you're done. it's downright scary how many serious, even critical, crypto and privacy projects falsely think this gives their users sufficient security, and use it as the only measure.

what you need is PGP-signing, where the release managing developer establishes a public/private PGP keypair, the private part of which is in their sole possession, preferably generated and kept on a hardware device (Fido, Nitrokey, Trezor, etc.). they confirm the key fingerprint on various different channels (social media, blockchain embedded data, live video, presentation slides, T-shirts, business cards, etc.), use the key to sign the packages and distribute the packages together with the signature files. users can download the public key and check the signature files against the package and the public key. if the signature is valid, that means the package came from a person in possession of the private key. this is much more robust than admin access to a website.