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.
IanTwenty
- 0 posts
- 5 comments
- 4 days
When Antennapod requests the episode the server can inject the ads and geolocate you based on your IP. Thus they can tailor them at the point of delivery to your region (and anything else they know/guess about your IP). Antennapod does not inject ads itself, it is at the mercy of what the podcast server returns.
- IanTwenty@piefed.socialto
Linux@lemmy.ml•Does the SecureBoot key expiration matter if SecureBoot is disabled?English
6 daysIt 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/
- 28 days
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.




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/