pastel VS flatpak

pastel: A command-line tool to generate, analyze, convert and manipulate colors.

I'm a fan of standalone binaries statically linked to musl for small command line applications. One such CLI app that releases this way is Pastel, a comprehensive color utility.

fd is my very first Rust project. In fact, if you go back in (Git) history, the project was originally written in C++. I have created various other Rust command-line tools since then, but I love coming back to fd, as I personally use it the most.

How does this compare to pastel?

> CLI tools do not implement auto-complete themselves. What you are seeing are auto-complete scripts for your shell that make network connections.

nit: This is incorrect. Robust auto-complete scripts call the actual program to provide completions.

That is what Flatpak does. It is Flatpak itself that makes the network connections.

https://github.com/flatpak/flatpak/blob/main/completion/flat...

Not that it would make any differencen if it was implemented in Bash seeing as the Bash script is also provided by Flatpak.

Not really. Even with modern technologies, the Linux desktop technology stack is very, very far behind when it comes to security.

The Linux kernel itself is a very weak foundation security-wise, the only way Android and ChromeOS get away with it is by using a very small feature set and restricting everything else as much as possible with seccomp, SELinux and heavy sandboxing.

The Linux desktop userland doesn't have meaningful hardening features compared to other platforms (even Windows is ahead, sadly). For example, practically all distros use glibc's memory allocator which has both poor performance and security [1] and their toolchain is based on gcc, with no support for modern compiler security features such as CFI (with the sole exception of Chimera Linux). Not to mention the permission model is completely outdated, like in that xkcd cartoon. Flatpak only mitigates this partially, because the Flatpak sandbox is very weak. The people working on Flatpak are doing their best, but from reading some GitHub issues, it's clear they are badly overworked and not experts on security at all. The person responsible for Flatpak's seccomp sandbox has admitted it isn't even his main responsibility and he doesn't have much knowledge about seccomp and is learning along the way [2]. The Flatpak seccomp filter is based on denylist instead of allowlist, and many dangerous syscalls can't be blocked because many applications rely on it (e.g. Firefox needs ptrace for the crash reporter). You also have to be very careful and use Flatseal (which is not officially supported) to deny permissions such as /home filesystem access, because it lets Flatpak apps override their own permissions by design [3]. And dangerous kernel components like io_uring are exposed [4], while Google disables them on their systems for their exploitation potential.

Here is a more detailed article examining the lack of security of Linux phones in case you're interested: https://madaidans-insecurities.github.io/linux-phones.html

If you want a FOSS-based secure phone, GrapheneOS is the best option.

[1] Check this comment by GrapheneOS founder for some technical details and how it compares to hardened allocators such as Android's Scudo or Graphene's hardened_malloc: https://github.com/NixOS/nixpkgs/issues/90147#issuecomment-6...

[2] https://github.com/flatpak/flatpak/issues/4466#issuecomment-...

[3] https://github.com/flatpak/flatpak/issues/3637

[4] https://github.com/flatpak/flatpak/issues/5447

Sensitive features like screenshots, input methods, screen locking and whatnot are behind extensions (or portals). I'm not familiar with the state of GNOME/KDE/Flatpak, but at least on the wlroots side of things it is true that currently these extensions are enabled and accessible by any process that can talk to the Wayland socket (breaking those security benefits, as you say). This is changing with protocols such as security-context that allow a sandbox engine like Flatpak (or your custom scripts) to restrict what features apps can use. (so your browser can't register an input method, or some random app can't lock the screen)

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...

https://github.com/swaywm/sway/pull/7648

https://github.com/flatpak/flatpak/pull/4920

It shouldn't be too complicated to create a package from the provided tarball.

[1]: https://flatpak.org/

Besides, there may be other ways to install them, although there doesn't seem no such Flatpak packages in Flathub. For example, some senerio to use some release channel or Docker / Podman. Additionally, when you use a different Linux distro where systemd is adopted and therefore can do Snaps (Snapd), you have another possibility.

Besides, there is another way to install Android Studio on Devuan: Flatpak. They have the package. Moreover, when you use a different Linux distro and can use Snaps, there is also the package.

- start using flatpaks from flathub, appimages and/or snaps, for GUI apps. You can start doing this from your own distro, you don't have to move yet.