Full disk encryption is not a solution here. Any application that’s already running which can provide read only file system access to an attacker is not going to be affected by your full disk encryption.
that's my point
upon reading a bit how different wallets work, it seems macos is able to identify the program requesting the keychain access when it's signed with a certificate - idk if that's the case for signal desktop on mac, and I don't know what happens if the program is not signed.
As for gnome-keyring, they ackowledge that doing it on Linux distros this is a much larger endeavor due to the attack surface:
An active attack is where the attacker can change something in your security context. In the context of gnome-keyring an active attacker would have access to your user session in some way. An active attacker might install an application on your computer, display a window, listen into the X events going to another window, read through your memory, snoop on you from a root account etc.
While it'd be nice for gnome-keyring to someday be hardened against active attacks originating from the user's session, the reality is that the free software "desktop" today just isn't architected with those things in mind. We need completion and integration things like the following. Kudos to the great folks working on parts of this stuff:
- Trusted X (for prompting) - Pervasive use of security contexts for different apps (SELinux, AppArmor) - Application signing (for ACLs)
We're not against the goal of protecting against active attacks, but without hardening of the desktop in general, such efforts amount to security theater.
Also
An example of security theater is giving the illusion that somehow one application running in a security context (such as your user session) can keep information from another application running in the same security context.
In other words, the problem is beyond the scope of gnome-keyring. Maybe now with diffusion of Wayland and more sandboxing options reducing this context becomes viable.
But that's the thing: I haven't found anything that indicates it can differentiate a legitimate access from a dubious one; at least not without asking the user to authorize it by providing a password and causing the extra inconvenience.
If the wallet asked the program itself for a secret - to verify the program was legit and not a malicious script - the program would still have the same problem of storing and retrieving that secret securely; which defeats the use of a secret manager.
I'm also running it smoothly on Wayland+nvidia. Pacman install btw.
Most key bindings work ime. All commands I've tried in the past few days work fine too, though I've missed things especially for Python development. For Rust it is very much usable today I'd say.
yeah, I still wrote my dissertation last year on latex because that was the template they had and I didn't feel like reading all formatting rules and writing a Typst version for that. That said, creating a Typst template is a far more straightforward than any other format.
only if double precision can be called high fyves
no, it's primarily about speed and resources because the comparison is often not against a hypothetical C/C++ alternative, but against an existing one that is slower and more resource intensive.
tl;dr: General purpose extensions are not even implemented yet
zed is very much an early stages editor; it'll look very different a year from now
imagine the nightmare of writing a 65 bit instruction set
eager_eagle
joined 1 year ago
lol they barely changed anything visually