Personally I find just using nftables.conf straightforward enough that I don't really understand the need for anything additional. With iptables, it was painful, but iptables has been deprecated for a while now.
Same here, I'm surprised most linux users I know like to install firewalld, UFW, or some other overlaying firewall rather than just editing the nftables config directly. It's not very difficult, although I've never really dug deep into the weeds of iptables. I suspect many people who have used iptables long ago in the past assume nftables is samilar and avoid interacting with it directly out of habit.
Not sure what you find difficult about it, but I just took the "workstation" config from the gentoo wiki and used it on my laptop.
Perhaps if you're doing more complicated things like bridging interfaces or rerouting traffic it would be more difficult to use than the alternatives, but for a simple whitelist it's extremely easy to configure and modify.
It's an open protocol, you don't need to use any of the vendors. My Yubikey is a "passkey", so is my Flipper Zero. Keepass provides passkey support.
For the general public, they already rely on either Google or Apple for pretty much all of their digital life. Nothing wrong with extending this to passkeys, it's convenient and makes sense for them.
> It's an open protocol, you don't need to use any of the vendors. My Yubikey is a "passkey", so is my Flipper Zero. Keepass provides passkey support.
I don't want to use a Yubikey. It's a pain in the butt. I just want to use my Mac, with no more damn dongles.
Keepass is a vendor, and one who doesn't even have a Safari extension.
> Nothing wrong with extending this to passkeys, it's convenient and makes sense for them.
I didn't say there was anything wrong with extending this to passkeys. The problem is the lock-in, e.g., Safari requires iCloud keychain for passkeys, but not for passwords. And there is no plaintext export/import, unlike with passwords.
Nobody can convince me that passkeys are good when I buy a Mac and use the built-in Safari but can't even use passkeys to log in to websites unless I give my passkeys to a cloud sync service or have to install some third-party "solution" (for a problem that should not exist in the first place). That experience is so much worse than passwords.
All of the 3rd party credential managers I’ve used that support passkeys work with safari, and through the APIs that Apple offers the credential managers you can even pick your default CM and never think about iCloud again…
So everyone has wanted "year of the Linux desktop" for a while. This year, since Microsoft has decided to call open season on their own feet and Valve has taken a break from swimming in their money pool to make sure absolutely any piece of software ever written can run on Linux, it looks like this might actually be happening. I am seeing a massive influx of new users, driven by distros like Cachy, Nobara, Bazzite. A lot of them don't have previous Linux experience and are generally not the most technically savvy users.
This absolutely terrifies me. Linux desktop security is, to put it politely, nonexistant. And the culture that goes with Linux desktop users just makes things worse, there's still a lot of BOFH gatekeeping going on, laughing at the new users when they inevitably mess something up and worst of all, completely refusing to admit that the Linux desktop has security issues. Whenever a new user asks what antivirus they should run, they are usually met with derision and ridicule, because the (oldschool) Linux users genuinely think their computers are somehow immune and can never be hacked.
The first cybercriminals to put some development effort into Linux ransomware/stealers are going to wreak havoc and a lot of people are going to be in for a rude awakening. The D-Bus issue with secrets in the article is just one of many many many ways in which Linux desktops are insecure by design.
There are of course distros out there that take security seriously, but we are not really seeing new users migrating to Qubes en masse.
Edit: not calling out the distros above in particular, all 3 are doing very good work and are not really any worse in security than most other distros.
Any windows program you download can steal all your secrets too. The only operating systems that isolate programs by default are on phones (and chromebooks).
Unless you give it admin permissions, it really can't (admittedly, a lot of Windows users do run their computers with their admin account by default). Also, Windows users generally have at least some kind of anti-malware running, which, while not perfect, does work well against most spray-and-pray malware out there.
Edit: did some research, I must correct myself, the stealers have indeed evolved so admin permissions are not required for most credentials on Windows either.
However, should "strictly speaking, not really worse than Windows" be the security target we aim for in Linux?
All your data is owned by your user. If you run a program, it will have access to all your data. Admin or not is irrelevant here.
The keyring is pretty open on Windows, if you know the key you can request anything even if stored by another app. There is a way to lock a secret to a specific app but it's not properly enforced in most versions of Windows.
The only user data that would require admin privilege is that of sandboxed Windows Store applications where even the owner can't access it directly from outside the program and you have to be admin.
The main problems with these kinds of in-repo vault solutions:
- Sharing encryption key for all team members. You need to be able to remove/add people with access. Only way is to rotate the key and only let the current set of people know about the new one.
- Version control is pointless, you just see that the vault changed, no hint as to what was actually updated in the vault.
- Unless you are really careful, just one time forgetting to encrypt the vault when committing changes means you need to rotate all your secrets.
Agreed with 1 and 3, just a tip re 2 though: sops encodes json and yaml semantically, key names of objects are preserved. Iow you can see which key changed.
Whether that is a feature or a metadata leak is up to the beholder :)
you're enrolling a particular users public/key and encrypting a symmetric key using their public key, not generating a single encryption key which you distribute. You can roll the underlying encryption key at any time and git-crypt will work transparently for all users since they get the new symmetric key when they pull (encrypted with their asymmetric key).
> Version control is pointless
git-crypt solves this for local diff operations. for anything web-based like git{hub,lab,tea,coffee} it still sucks.
> - Unless you are really careful, just one time forgetting to encrypt the vault when committing changes means you need to rotate all your secrets.
With git-crypt, if you have gitattributes set correctly (to include a file) and git-crypt is not working correctly or can't encrypt things, it will fail to commit so no risk there.
You can, of course, put secrets in files which you don't chose to encrypt. That is, I suppose, a risk of any solution regardless of in-repo vs out-of-repo encryption.
for 1), seems like you could do a proxy encryption solution.
edit: wrong way to phrase I think. What I mean to say is, have a message key to encrypt the body, but then rotate that when team membership changes, and "let them know" by updating a header that has the new message key encrypted using a key derived using each current member's public key.
Cloudflare is widely used because it's the easiest way to run a website for free or expose local services to internet. I think for most cloudflare users, the ddos protection is not the main reason they're using it.
For 1, you can still have extremely malicious networks. It's true that your web traffic is likely encrypted but... What services are exposed on your machine? Do you have mapped samba shares?
For 5 - session cookies are one of the main things stealers look for. Deleting cookies is absolutely good advice until browsers build in better mitigations against cookie theft.
For 6 - if there was a standard interface how password managers could rotate my creds, I would sure as hell use it. Force rotating passwords is only "bad" if people need to remember them.
Any random credentials stored in a vault absolutely should be rotated periodically, there is no reason not to.
I don't see the point of this letter, none of the "bad" advice they call out is harmful to security in any way, if people feel safer avoiding public wifi, so be it. Is it just a call out to other cisos to update their security hygiene powerpoints?
While you and I would love it if password managers would rotate creds, we're not yet at the point where people will use password managers. They're still using CompanynameFall2025!. Next month, they'll dutifully rotate their password to CompanynameWinter2025! because their work policy is still stuck on shitty standards.
> This kind of advice is well-intentioned but misleading. It consumes the limited time people have to protect themselves and diverts attention from actions that truly reduce the likelihood and impact of real compromises.
When you've got 15 seconds to _maybe_ get someone to change their behavior for the better, you need to discard everything that's not essential and stay very very far away from "yes, but" in your explanations.
reply