Flatpak for command line tools

[cra0zy]

From what I've read of the documentation there are 3 things that seem to be missing for command line tools:

• Custom commands for running the app, having to do flatpak --run org.bla.bla every time seems tedious
• Providing autocomple for the command
• Providing man pages for the command

[aiamuzz]

Yup i second that ... better command access needed to the flatpak ecosystem.

[TingPing]

The best it could do is export org.bla.bla which is still tedious.

[mwleeds]

Probably your best option is an alias, e.g. alias builder='flatpak run org.gnome.Builder' in your ~/.bashrc

[patriziobruno]

Ubuntu's snap gives a good example on how to support this: it creates in /usr/bin a symlink to a script launching the app. Flatpak could create the symlink either in /usr/bin or in ~/bin based on the --user/--system arg. Symlinks would allow to handle different versions seamlessly

[alexlarsson]

Creating a symlink/wrapper is easy, not allowing a fart app to install a "firefox" symlink is less so.

[patriziobruno]

Any alias hiding the complexity of using flatpak run complete.long.package.name, being it either a shell alias or a symlink would take its toll on security, but that's true for .desktop files as well. Unless you check under the hood before clicking on an icon in gnome-shell you will never know what you're going to run.

[alexlarsson]

The design of flatpak is such that desktop files and icons cannot conflict by name. It is true however that they can have the same description and icon, but then you will get two firefox icons and be confused, rather than silently replacing the real one.

[patriziobruno]

That depends on the DE you're using and the way you launch apps. My MO on Gnome is to press Super, start typing the name of the app I want to run and click on the first icon on the top left.

In this case typing libreoffice to start the libreoffice's file-selector will provide a not-complete-because-too-long list of the icons with a description beginning with "libreoffice", so I can see only one "Libreoffice" icon, but in fact I have two installations, one from the Ubuntu repo, the other from flathub. How would I know that I'm not clicking on the wrong one, unless I dig a little deeper, something an average desktop user usually doesn't do.
On the other hand the average terminal user is most likely to use which on the command they're about to run to find the path, use ls -l or file to verify if that path points to an ELF executable or a script or is a symlink, check if the script does anything malicious.

You can't control what users install on their machine outside flatpak, what you can do is to check at installation time that:

• two applications don't try to use the same symlink/alias, without a proper suffix.
• an application don't try to use an alias that has nothing in common with its complete name: /usr/bin/gedit pointing at org.virus.maliciousapp, rather than org.gnome.gedit. Or force the app to use a reversed package name for the alias, such as /usr/bin/gedit.gnome.org, as it would be more shell-completion friendly than flatpak run org.gnome.gedit

After this, if a user run a malicious script that messes up with the symlinks and/or the .desktop files pointing to flatpak apps, it's completely out of control for flatpak, at least for this issue, it could still be matter for a different user-story though: "add a flatpak check-consistency command to verify that flatpak apps have not been tampered with".

My 2 cents 😄

[cra0zy]

The design of flatpak is such that desktop files and icons cannot conflict by name. It is true however that they can have the same description and icon, but then you will get two firefox icons and be confused, rather than silently replacing the real one.

How about having a designated flatpak bin folder for aliases and giving the user an option to either add it to their PATH variable or not? (same can be done for autocomplete files and man pages)

[TingPing]

@cra0zy Opting into insecurity is questionable, the end result is just new user forums will have copy paste guides on enabling it, user friendly distros will start enabling it out of the box, etc and nothing was actually improved.

[cra0zy]

@TingPing What specific insecurities are you trying to avoid?

If its flatpak apps installing fake commands for stuff like sudo lest say, you can avoid that by notifying the user what new commands are coming with the package.

[TingPing]

you can avoid that by notifying the user what new commands are coming with the package.

Because users are known for being very attentive and things like warning messages are known for being successful.

The only way it can be done "securely" is if we require app-id's for commands with the assumption that important cli tools never do that.

[alexlarsson]

Yes, i could see exporting wrappers like com.skype.Client. That is unlikely to conflict with anything serious, and using such wrappers work much better in the shell, even if they are somewhat painful.

Also, given such wrappers, it is much easier for a user to (manually) create an alias for a more readable name.

[alexlarsson]

I just merged #1254 which lets you opt-in (by adding to your PATH) exported wrappers of the main binary in flatpak apps named by the appid.

I realize this is less than some people want, but it is also, simple, safe and easily tweakable by aliases.

I don't want to auto-add the wrapper dirs to the real PATH, because such a modification is bound to break a lot of users setups.

[vadyalex]

Providing autocomple for the command

@cra0zy I am assuming you mean shell command completion.. if you are using zsh you can try flatpak plugin for oh_my_zsh

[cra0zy]

@vadyalex we are not talking about the flatpak command itself.