Affected users who are running X11 should audit their Zoom version, isolate conferencing workloads onto dedicated hardware or virtual machines, or move to a browser-based version of Zoom where sandboxing prevents unprompted clipboard access.
Anyone running a Linux system with Wayland should be OK.
In their words they are open source, donation funded, zero advertising, zero ai data selling place to create free websites. A “social network of 1,751,700 web sites that are bringing back the lost individual creativity of the web. We offer free static web hosting and tools that allow you to create your own web site.”
Firewalling containers’ outbound access seems to be rare but another powerful layer of protection
Didn’t know about liability, you are refering to this recent change?
https://www.ibanet.org/European-Product-Liability-Directive-liability-for-software
I am most concerned about that. If the legal position on copyright of AI code is decided in the future an audit or tracking of AI contributions in the codebase may be necessary to understand risk and exposure.
Granted you can’t make people disclose AI assistance with 100% accuracy but I would expect a majority to comply.
You’ve made a great start. How much further you go depends on your needs and threat model.
Rsync is ok as a start but there are dedicated backup tools that will give you access to your files at any point in time. This is important if you delete a file and later need it back after an rsync has already run and deleted it remotely too.
Rsync will not encrypt your backups. If a burglar takes your Pi will they have easy access to all your files too?
With rsync+ssh you are also vulnerable to either yourself (more likely) or a rogue process on your own machine deleting the files over ssh (e.g. ransomware attack).
The answer to that is append-only backups. A backup tool like restic has a backend you can host that does exactly this:
The --append-only mode allows creation of new backups but prevents deletion and modification of existing backups. This can be useful when backing up systems that have a potential of being hacked.
https://github.com/restic/rest-server
Take a look at restic to see what else you gain from switching to a dedicated tool versus rsync:
https://github.com/restic/restic#design-principles
There are others too such as borg.
Presuming BASH:
https://www.gnu.org/software/bash/manual/bash.html#Quoting
Single quotes are much safer/predictable because:
Enclosing characters in single quotes (‘
'’) preserves the literal value of each character within the quotes. A single quote may not occur between single quotes, even when preceded by a backslash.
Not to say they are always the right choice though.
Ah right, I forgot about the different editions! Been on GNOME for so long.
X11 was completely removed in Fedora 43 I believe
https://fedoraproject.org/wiki/Changes/WaylandOnlyGNOME#Wayland-only_GNOME
I think the desktops need to better protect users’ secrets by accepting rogue user processes are part of the threat model now. There are lots of mechanism to lock known future user processes into a protected area (containers, chroot, etc), but none to lock existing and future unknown user processes out of a protected area.
Your idea of a yubikey access protected file area makes a lot of sense and I don’t think it exists yet. Then a user could throw their existing ssh keys in there and immediately get physical protection on them.
It would need to be carefully controlled. Something like gocryptfs on FUSE as you suggest but with a stronger threat model layered on top as theirs is short: https://nuetzlich.net/gocryptfs/threat_model/
Thanks to these attacks I think creds got to all move to physical security keys so there’s nothing to (digitally) steal any more.This tool is a good idea for the short term.
It could if you/future owner ever need to re-enable it:
The trouble is not your present boot; it’s your future boot. If your older PC’s firmware never gets the 2023 keys, and the rest of the world starts assuming those keys exist, you can end up stuck in a weird limbo. While your existing Linux install will still boot, a new or updated distro won’t.
Testing now will help diagnose future problems.
https://www.zdnet.com/article/aspirin-for-linuxs-microsofts-secure-boot-headache/
I’m not familiar with Pikapods but Monica v4 has trouble with notifications. First you need to ensure it’s been configured right to even send a test email, this can be triggered with a command if you have access:
php artisan monica:test-email
Various Monica environment variables must be set to configure this, it should be in the docs somewhere if not I can fish my config out for you.
Even once that’s working you’ll need Monica to run its regular jobs for sending notifications, there’s config for that too. Finally the code has bugs and will often miss reminders in my experience. There are some open bugs still on this and I guess the devs have moved onto their rewritten version (chandler):
Ha! I sound keen like an AI cause I was thinking about exactly this problem when I saw your post and have been continuing to research.
The GNOME keyring does not defend against rogue processes for now. However KDE wallet can prompt a user before access (I’ve not tried it):
https://docs.kde.org/stable_kf6/en/kwalletmanager/kwalletmanager/wallet-access-control.html
…this seems a fair bit safer, presuming it works.
Some hints here:
https://wiki.archlinux.org/title/GNOME/Keyring#PAM_step
- Alternatively, if using GDM and LUKS, GDM can unlock your keyring if it matches your LUKS password. For this to work, you need to use the systemd init in your mkinitcpio.conf as well as the appropriate kernel parameters, and you should make sure that your system’s real-time clock is set to UTC rather than local time (see [2]). See [3] for more details.
When using a display manager, the keyring works out of the box for most cases. GDM, LightDM, LXDM, and SDDM already have the necessary PAM configuration. For a display manager that does not automatically unlock the keyring edit the appropriate file instead of
/etc/pam.d/loginas mentioned below.
I think you are absolutely right to examine whether your system defaults to too much convenience versus security for your threat model. For GNOME keyring:
Any application can easily read any secret if the keyring is unlocked. And, if a user is logged in, then the login/default collection is unlocked. Available D-Bus protection mechanisms (involving the busconfig and policy XML elements) are not used by default and would be easy to bypass anyway.
The GNOME project disagrees with this vulnerability report because, according to their stated security model, untrusted applications must not be allowed to communicate with the secret service.
Applications sandboxed via Flatpak only have filtered access to the session bus.
https://wiki.archlinux.org/title/GNOME/Keyring#Security
So while flatpaks that play the game are ok everything else is on trust. For the average user perhaps this is the right balance, though your Signal example suggests it’s too lax for anyone nowadays.
I would like to see system secrets protected however they are accessed, not just for flatpaks.
F-droid themselves gave an update in April:
https://f-droid.org/en/2026/04/03/twif.html
If you’ve been holding off updating Syncthing-Fork we have two pieces of news for you. First, the original dev continues to collaborate still, we know this was a pain point back then. Second, we’ve just added BasicSync, A simple app for running Syncthing, which just controls Syncthing’s running behaviour as hands off as possible, while the original service hums in the background.
So it seems since the handover things have settled but there is also a new fork which takes a more bare-bones approach.
Say that new authelia exploit looks like one fail2ban already recognises or relies on timing/brute-force then you’re covered even before a patch is available.
Here’s a real authelia vuln:
https://app.opencve.io/cve/CVE-2026-47203
I think fail2ban would help protect authelia here?