πŸ’Ύ Archived View for gemini.dimakrasner.com β€Ί gplaces-flatpak.gmi captured on 2024-03-21 at 14:58:00. Gemini links have been rewritten to link to archived content

View Raw

More Information

-=-=-=-=-=-=-

Improved gplaces Flatpak

gplaces in Flathub

Gemini doesn't have strong presence on Flathub and I hoped to see more variety there after my submission of gplaces: at the time, Flathub offered only one or two Gemini clients. Although it's not exactly the ideal platform for distribution of minimalistic software, it's still a good way to reach more people (on more distros) and spread the message. I finally found the time to improve the gplaces Flatpak, and I hope this would improve the user experience for Gemini newcomers that discover it through Flathub and gplaces.

First, the Flatpak runtime is (finally) bumepd from 22.08 to 23.08. If I'm not mistaken, 23.08 is more common these days, and you're more likely to have it already if you use Flatpak. gplaces is a very odd creature in Flatpak land: the gplaces executable is about 100K, but it can pull many MBs of runtime if it's the only Flatpak on your system that uses 22.08.

Second, gplaces is now allowed to run handler programs on the host by default.

The gplaces configuration file (gplacesrc) allows one to define what program command-line to use to open or stream various MIME types (like audio or video) and unsupported URL schemes (like https:// links). gplaces doesn't use mimeapps.list (what xdg-open and friends use) because you're most likely to choose graphical applications as your default applications, while gplaces is a console application. In addition, gplaces' needs are different: it needs an application that can read audio from stdin (like mpv) for the "streaming" feature to work, or a non-interactive image viewer that works in the terminal (like chafa).

To give the user extra freedom, the Flatpak build of gplaces tries to run these programs on the host instead of bundling them into the gplaces package. That would make the package bigger, create maintenance burden, and force the user to stick with the defaults (because the user's programs of choice are not bundled). However, although it tries to run programs on the host, it doesn't have the permissions to do so by default: Flathub's linter forbids this.

This means that the gplaces Flatpak only provides limited functionality and may seem broken: it can show gemtext or plain text and download other kinds of files, but that's about it. It can't open other kinds of files, nor stream them.

Gemipedia

Imagine you're on Gemipedia, reading about Gemini:

	# Image Gallery: Gemini (protocol)
	[1] Back to article

	[2] Amfora - Gemini client
	[3] AmiGemini - Gemini client

	--
	[4] Gemipedia Home
	[5] Go to Article
	[6] Using English Wikipedia. Change Language?
	--
	[7] Made with πŸ“š and ❀️ by Acidus
	All Wikipedia content is licensed under CC BY-SA 3.0
	gemi.dev/cgi-bin/wp.cgi/images?Gemini+(protocol)>

Then, you go for link 2 to view an Amfora screenshot but see this error:

	gemi.dev/cgi-bin/wp.cgi/images?Gemini+(protocol)> 2
	...........................
	Portal call failed: org.freedesktop.DBus.Error.ServiceUnknown
	`chafa /home/spot/.var/app/com.github.dimkr.gplaces/data/gplaces.XXDeq5J7` has exited with exit status 1

To make this work, you must give gplaces the special permission to run applications on the host:

	flatpak override com.github.dimkr.gplaces --talk-name=org.freedesktop.Flatpak

Only once you do this, gplaces is able to display images:

	gemi.dev/cgi-bin/wp.cgi/images?Gemini+(protocol)> 2
	...........................
	β–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒβ–ƒ
	β–Žβ•Ή   ▁▆▆  ▁▁▁                       β–Š
	β–Ž     ▁▁▇▁▇▇▇                       β–Š
	β–Ž    β•Žβ–β–‡β–‡β–‡β–‡β–β–β–‚β–β– ▁▁▁╷▂▁╷            β–Š
	β–Ž      ▁▂▂▂ ╷▂┆▂▂ β–‡β–‡β–‡ β–‡β–‡            β–Š
	β–Ž       β•Ή β•΄  β”ˆβ•Ή  β•΄                  β–Š
	β–Ž        β”ˆβ”ˆ    β•Ήβ”ˆβ”Šβ”ˆβ”ˆ     β•΅          β–Š
	β–Ž    β”Œβ–‰  β”Šβ”Š                         β–Š
	β–Ž    β•Άβ”β–‰β”Žβ”€β•΄β”¬β•·β”€β”„β”„β•Ά                   β–Š
	β–Ž     │╢▆─ β”€β”Œβ–†β”€β”€β”€                   β–Š
	β–Ž    β•Ά β•Ίβ”€β•β•΄β–‡β•Άβ”‰β•Ίβ”…β”ˆβ•Έβ•β•Œ                β–Š
	β–Ž    β•Ίβ•β”β•Œβ”β•Έβ•                        β–Š
	β–Ž    β•Ά ▉┅▂▁┍▁━▉┆▁━ ▁╸▁▁▁            β–Š
	β–Ž    ╷▁▂▂ β–‚β–‚β–‚  β–‡β–‡β–‡ β–‡ β–‡β–‡β–‡            β–Š
	β–Ž     β–‚ β–‚β–‚ β–‚β–‚β–‚β–‚β–‰β–‚β”ˆ β–‚β–‚β•»              β–Š
	β–Ž    β•΅β•΅   β”ˆ     β–˜                   β–Š
	β–Ž    β•΅β”ˆβ–… β”ˆβ–… β•΅β–„β–… β•Ή                   β–Š
	β–Ž    β”Šβ”Šβ–β–†β–† β•Ά                        β–Š
	β–Ž    β•Άβ•Œβ”€β”„β•΄β•΄β•Œβ”€β•Œβ”β•Άβ”β”€β”€β”ˆβ”€β•΄              β–Š
	β–Ž    β•Ά β”„β•΄β”…β•΄β•΄β•Ί β•Œβ”ˆβ•Œβ”€β•Œβ”„β•Έ               β–Š
	β–Ž    ╺╍┅┑╼╾╍╺━┅┑                    β–Š
	β–Ž    β•Ά β”ˆβ”…β•β•Ίβ•β•Έβ•Όβ”…β•Έβ•β”β•β•΄β•Έβ•Ίβ”…β•Œβ•Έβ•β•΄         β–Š
	β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡β–‡
	`chafa /home/spot/.var/app/com.github.dimkr.gplaces/data/gplaces.XX5DQ5vX` has exited with exit status 0

HTTPS links suffer the same fate, because gplaces doesn't support HTTPS. The default handler (in the default gplacesrc) for https:// links is the host's xdg-open, but it won't run for the same reason.

Annoying, isn't it?

Exception

Since yesterday, this annoyance is gone be because gplaces was given an exception and now has this permission by default. Other Flathub packages that run applications on the host (for example, applications with an integrated terminal) went through this process, too.

Flathub page

Now that gplaces has this extra permission, its Flathub page says it has "Arbitrary permissions" and "Can acquire arbitrary permissions". This reminds me of the regulatory health warnings on cigarette labels and I don't like this (I don't like "app stores" in first place), but I think this makes the gplaces Flatpak more user-friendly, with saner defaults.

However, I also understand the convenience vs. security tradeoff here. A seeminly benign link that ends with .gmi can lead to a malicious Windows executable, and if gplaces is configured to use xdg-open for this kind of files (by default, it's not), this could run the executable through Wine. I'm also thinking about the various image decoding CVEs (like CVE-2023-4863) of the last few years: opening a crafted image on the host can lead to code execution on the host.

To force the old behavior and forbid gplaces from running applications on the host, one can:

	flatpak override com.github.dimkr.gplaces --no-talk-name=org.freedesktop.Flatpak