Security is hard and not the fun part of programming (for most people anyway).

KDE and Gnome have problems too.

Rationale for Accepting kio-admin into openSUSE

We have dealt with these types of APIs in KDE since 2017 without achieving any notable improvements. As we are responsible for product security we tried to protect our users from potentially harmful components. At this point, though, we don’t believe that this situation will change anytime soon. Meanwhile users still want to use features like the one found in Dolphin, and don’t understand why openSUSE does not include them.

https://security.opensuse.org/2025/02/21/kio-admin-admittance.html

Wasn’t vertical integration, was done by packager.

We don’t believe that the openSUSE Deepin packager acted with bad intent when he implemented the “license agreement” dialog to bypass our whitelisting restrictions. The dialog itself makes the security concerns we have transparent, so this does not happen in a sneaky way, at least not towards users. It was not discussed with us, however, and it violates openSUSE packaging policies.

Short version

We don’t believe that the openSUSE Deepin packager acted with bad intent when he implemented the “license agreement” dialog to bypass our whitelisting restrictions. The dialog itself makes the security concerns we have transparent, so this does not happen in a sneaky way, at least not towards users. It was not discussed with us, however, and it violates openSUSE packaging policies.

...

The experience with Deepin software and its upstream during the code reviews that we performed has not been the best. More than once, security issues we reported have been replaced by new security issues. Other times, upstream did not invest the effort to fully analyze the issues we reported and fixed them insufficiently. Generally the communication with upstream proved difficult, maybe also due to the language barrier. While upstream stated at times that they don’t have enough resources to deal with security reports, which is worrying enough, the design and implementation of Deepin D-Bus components often changed radically in unrelated ways. This makes the security assessment of Deepin components a moving target. Building trust towards Deepin components has thus been extremely difficult over the years.

The history of Deepin code reviews clearly shows that upstream is lacking security culture, and the same classes of security issues keep appearing....

I get this occasionally. If the directory the drive gets mounted to already exists, it can’t mount it.

Usually this happens if the drive bugs out and improperly dismounts.

Rebooting should get rid of the directory.

Not by default, but you can optionally enable it.

The really big one for me is installing things. Installing packages requires 0 interaction, can be easily automated, wide availability of packages, etc. On Windows, Winget sucks. It's just running the regular installers. MacOS is better since it has Homebrew, but it has some problems. Homebrew struggles to update "casks" (aka GUI apps) so you still have to rely on app's in-app updaters. MacOS's gatekeeper also is annoying about third part software. And for anything not in Homebrew, you have to install it from the web.

Programming is also easiest in Linux. MacOS is a pain sometimes. The preinstalled toolchains are outdated. Installing new ones from homebrew also requires reading through a large block of text in order to find out what manual steps you need to do.

Updated the title

Took me a minute to realize they meant two weeks until TWIG #200.

Ah I had the same issue. JavaFX still uses X11. By default VSCode only lets X11 be used if Wayland is not available (this is the X11 fallback permission). Disabling X11 fallback will let VSCode use Wayland and let JavaFX use X11. I might make an issue for this on the flatpak’s GitHub asking for this change.

Honestly, the truth is that setting up containers for development will always be a hassle. My low tech way is just to make a distrobox container with its own home folder, install an IDE in it, and install packages. The more proper way to do it would create your own containerfile to build your container for developing.

VSCode also has its DevContainers extension but that doesn’t work in VSCodium and does some weird things.

Flatpak's usefulness for programming depends on the IDE and language. IDEs like VSCode largely suck because they are not designed to work in flatpak. But some languages still do work well in them, such as Rust, since Flathub provides the Rust SDK and dependency management is done with cargo. But it sucks for C++, where you typically install dependencies using your system package manager.

IDEs like Gnome Builder are pretty good. It's designed to work within the flatpak sandbox. Even when running as a flatpak, you can choose to build things using containers or your host system. And of course also build using the Freedesktop runtimes.

I recently setup JavaFX with the flatpak version of VSCodium and have it working pretty well. You first need to install the Java SDK from Flathub, set an env variable to tell VSCode to load the SDK. The more annoying part was JavaFX since it's not part of the JDK anymore. I just downloaded the JavaFX tar, extracted to a directory called JavaFX, and set $JAVAFX_HOME to point to it. Since VSCode has host filesystem access, it can access it. Few more steps than traditional Linux, sure, but still easier than MacOS and Windows.

Not sure about your database situation though.

Major people of the project had moved on. It’s being maintained, getting security fixes, but pull requests are slow to be merged.

That is planned. But pulse is not secure, so exposing it is not great.

Don't believe so, best that's currently available is skimming through the video to look at the slides.

Here's my short summary of the presentation, I tried to denote what's being worked on (open PR), what's kinda being done (WIP), and things stuff they'd like to be done in the future (wishlist). May be somewhat wrong.

• Flatpak is stagnant
• Red Hat is working on a better way to preinstall flatpak apps (open PR)
• Flatpak should is slowly moving towards OCI and away from ostree (more tooling available, don't need to maintain their own tools)
• Better permission handling that is more backwards compatible (open PR)
• Should directly use Pipewire instead of Pulseaudio (WIP)
• Allow user namespaces in flatpak sandbox (WIP)
• Move dbus proxying into dbus brokers (wishlist)
• Improve network sandboxing (wishlist)
• Improve drivers handling, currently drivers need to be built for each runtime, could cause issues if using EOL app on new hardware (wishlist)
• Work on portals directly improves flatpak

Unfortunately, it's not in a great situation. Flatpak is stagnant. There's a lot of cool things in the works, like a stronger sandbox, preinstalling flatpaks more effectively, etc, but merging things is hard.

Blood is edited in.

Please tell me Wayland is enabled, even if it’s not the default.

By default, flatpaks have no permissions. All permissions must be manually specified in the manifest file. But if you look at the top apps on Flathub, they tend to have broad filesystem permissions, including home and host. This are pretty bad permissions because it's insanely easy to escape the sandbox with them since there are no protections against writing to files like .bashrc. Snap at least prevents apps from accessing hidden files for this reason.

Flatpak isn’t as strong as a sandbox as Android. But if you tweak permissions, it can be deemed good enough.

If you really wanted security, you’d want to learn SELinux, but that’s a whole rabbit hole of complexity.

I'm not going to trade Firefox for a browser that is years away from being even remotely daily drivable. Even once/if it's able to render pages mostly correctly, it will still take a while after that to make it fast.

Even with Mozilla's funding, they're behind on implementing featues. Ladybird has much less funding and their current policy is to just rely on donations.

The linked blog post about moving from WebKit 1 to 2 was an interesting read: https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/

Chuckled when it mentioned that GIMP 2 was affected but they will be soon migrating to GTK 3… written in 2016.