jrgd

If Google kills AOSP, a lot more than just GrapheneOS will stop being able to exist lest some entity maintains a fork that diverges from Google’s path. Vendors that aren’t shipping in line with Play Services and the rest of the ecosystem as well as LineageOS and other custom ROM development teams will suffer as well.

This kind of decision would essentially kill adoption of Android in a good number of countries within a few years as well as be the end of Android adoption for anyone that cares about security and/or privacy. Yes, It would either kill or put a large burden upon GrapheneOS as a project, but that is also true for so many other projects in the ecosystem. If the developers shutter their AOSP usage due to upstream abandonment, the users will likely follow in the same pattern.

It’s probably not a case for everyone due to the obvious limitations, but I primarily use KeepassXC from my main workstation. I have backup scripts that periodically run for my user on said workstation that capture my Keepass database among other user files and backup to external storage, cloud storage as dictated.

For my laptops, mobile devices; I periodically push the database from either the main workstation or pull from a backup to these devices. I do not write new entries from these devices in order to avoid having to handle writeback to the main instance of my Keepass db. This can be done, but inherently starts to hinge on needing network access all the time to ensure an up-to-date copy of the DB is present as well as being explicitly a single-user db to prevent a syncing protocol from accidentally writing over new entries from any given device. Obviously, if network sync and the potential for multi-user is important to you, continue using Bitwarden. It is a perfectly fine solution.

I’ll list a few of my regularly-used tools, both CLI and GUI.

CLI:

• ncdu: An interactive TUI variant of du, for tracing disk usage across targeted directories.
• podman: An alternative runtime to Docker that is arguably just better at this point. Can handle rootless containers with ease, works with SELinux, can handle Docker compose files with add-on tool podman-compose, can automatically update containers intelligently, can integrate well with SystemD, and more.
• mtr: Another network tool. Effectively traces network routes to a given IP. Great for diagnosing faults in latency or major packet loss.
• ffmpeg: A very complicated, but powerful tool for converting, manipulating video and audio files in all sorts of ways. FFMpeg can essentially be the answer to any ‘do X to Y file’ question.

GUI:

• Kdenlive: A powerful video editor developed by KDE. For free and open source, it is impressive how little you can’t do when editing videos with this tool. A bit buggy at times, but has gotten significantly more reliable over years.
• Handbrake: A FFMpeg frontend that allows for mass transcodes of video files based on created profiles. Great for archiving, finalizing videos down for web upload, or just converting content to a more efficient format. Specializes in lossy/destructive operations.
• LosslessCut: A FFMpeg frontend that allows for trimming videos, stripping and/or exporting tracks from videos, editing mkv metadata, editing video chapters, and any other lossless/non-destructive operations that can be done on video files.
• Subtitle Composer: An outright semi-professional-grade subtitle editor developed by KDE. Supports and can convert between pretty much any subtitle format you might encounter. Great for creating, editing, timing, and translating subtitles for videos.
• KeepassXC: My password manager of choice. Has browser autofill integration, though requires some holepunch work to function with Flatpak browsers. Explicitly is based on local files. Does not rely on cloud providers.
• Limo, R2Modman: Native mod-managers that allow for modding various Steam games (native and Proton) on Linux.
• Blender: A powerful 3D editor. Capable of hard and soft 3D modeling, character rigging, animation, material creation and UV mapping, compositing and rendering. Pretty much an all-in-one tool for 3D art and design.
• FreeCAD: A somewhat daunting, but functional 3D CAD software. Has received a lot of recent (~3 years) patches to improve on a lot of long-standing pain points in the software.

In reference to the article we’re discussing, I am not entirely talking about vulnerabilities in the implementations, but specifically about the lack of standard security features allegedly not present by design in D-Bus. Namely things like namespace reservation, access controls, and fully-defined transport encryption implementations.

In an environment where desktop security is starting to be taken seriously (see Wayland, freedesktop protocols), D-Bus is lacking by comparison. Pulling from the article, any userland application that implements its own access to the user D-Bus can just dump the contents of your keychain (browser-stored passwords, Signal encryption keys, user contacts, manually stored secrets, etc.). I’d argue that for any untrustworthy application (deliberately run or not), shouldn’t be able to do something like that or otherwise tamper with any application it may feel like.

Flatpak does seem to have ways to limit what applications can access through D-Bus, though I am not entirely sure of the extent of what limits are enforceable. I’ll have to read more into Flatpak’s D-Bus filtering to know exactly what it can and cannot do.

Additionally, D-Bus policies are indeed a form of access control. Unfortunately there are limitations. The first is that they are statically defined config files. If an application desires D-Bus access restriction, the only way for that to happen is if a D-Bus policy file is installed via package manager with the software. Applications are not allowed control over access to their endpoints through D-Bus. Applications can absolutely build an authentication or access control layer on top of their D-Bus endpoints, though without a defined standard this quickly gets into the ‘vendor-specific behavior is encouraged’. (To note, KDE Wallet does this exact thing with an optional access control panel with snitching ability when applications access the user keyring.)

As for the default user session policy (where applications like the user keyring are accessed), things aren’t looking that great. At least on OpenSUSE Leap 16, the session policy is left completely open with zero restrictions by default. This does mean that instead of being standard, every application that wants to use D-Bus is largely left to fend for themselves, which I have no doubt meaning that the level of security afforded can vary wildly between application sets (GNOME, KDE, Hyprland, COSMIC, Cinnamon, etc.). I’d argue this shouldn’t be the case and applications developers shouldn’t have to work around D-Bus in the goal of securely interfacing with it.

To be fair, D-Bus is a protocol. Proper documentation and standards is half of implementation. Without any well-defined standards, a protocol is essentially useless and/or lawless. While not every case of non-compliance is the fault of D-Bus, the general lax nature of how endpoints are intended to be defined as well as the incompleteness for the actual standards applications should adhere to is a significant factor for why many applications are the way they are. In addition to the severe security flaws in D-Bus, this could be written with extensions to the protocol, becoming a new standard. Though if the problems are as deeply rooted as they are, it’s not entirely out of the question to create another standard that isn’t D-Bus.

Revolt rebranded as Stoat and does have voice chat with discord-style hotseat channels available in beta. I still wouldn’t recommend it yet due to client bugs, but it’s getting there.

Probably either wait for some other provider to build helm charts, roll your own k8s YAML for Redis based on the helm chart and with standard Redis OCI images, or migrate to a different, but compatible service like DragonflyDB if you don’t need modern Redis features (not suggesting Valkey because they are also entrenched in Bitnami and offer it as the official chart source).

The main idea on a device running something like Graphene OS is that you are already in a state of using minimal, if not at all using Google Cloud services, including data backups. It’s intended in tandem with modifications like GMS, GPS (if optionally installed into a given user, work profile) running as an unprivileged, permission-based application. If someone is taking their data privacy and security seriously enough to consider using a duress PIN and flashed their phone with something along the lines of Graphene OS, would they be likely to have heavy reliance to Google’s Cloud offerings?