• 1 Post
  • 22 Comments
Joined 1 year ago
cake
Cake day: July 16th, 2023

help-circle



  • I’m very interested to hear what went wrong.

    We’ll probably never know. Given the impact of this fuck up, the most that crowdstrike will probably publish is a lawyer-corpo-talk how they did an oopsie doopsie, how complicated, unforseen, and absolutely unavoidable this issue has been, and how they are absolutely not responsible for it, but because they are such a great company and such good guys, they will implement measures that this absolutely, never ever again will happen.

    If they admit any smallest wrongdoing whatsoever they will be piledrived by more lawyers than even they’d be able to handle. That’s a lot of CEO yachts in compensations if they will be held responsible.





  • The third option is to use the native secret vault. MacOS has its Keychain, Windows has DPAPI, Linux has has non-standardized options available depending on your distro and setup.

    Full disk encryption does not help you against data exfil, it only helps if an attacker gains physical access to your drive without your decryption key (e.g. stolen device or attempt to access it without your presence).

    Even assuming that your device is compromised by an attacker, using safer storage mechanisms at least gives you time to react to the attack.




  • Kinda expected the SSH key argument. The difference is the average user group.

    The average dude with a SSH key that’s used for more than their RPi knows a bit about security, encryption and opsec. They would have a passphrase and/or hardening mechanisms for their system and network in place. They know their risks and potential attack vectors.

    The average dude who downloads a desktop app for a messenger that advertises to be secure and E2EE encrypted probably won’t assume that any process might just wire tap their whole “encrypted” communications.

    Let’s not forget that the threat model has changed by a lot in the last years, and a lot of effort went into providing additional security measures and best practices. Using a secure credential store, additional encryption and not storing plaintext secrets are a few simple ones of those. And sure, on Linux the SSH key is still a plaintext file. But it’s a deliberate decision of you to keep it as plaintext. You can at least encrypt with a passphrase. You can use the actual working file permission model of Linux and SSH will refuse to use your key with loose permissions. You would do the same on Windows and Mac and use a credential store and an agent to securely store and use your keys.

    Just because your SSH key is a plaintext file and the presumption of a secure home dir, you still wouldn’t do a ~/passwords.txt.


  • How in the fuck are people actually defending signal for this, and with stupid arguments such as windows is compromised out of the box?

    You. Don’t. Store. Secrets. In. Plaintext.

    There is no circumstance where an app should store its secrets in plaintext, and there is no secret which should be stored in plaintext. Especially since this is not some random dudes random project, but a messenger claiming to be secure.

    Edit: “If you got malware then this is a problem anyway and not only for signal” - no, because if secure means to store secrets are used, than they are encrypted or not easily accessible to the malware, and require way more resources to obtain. In this case, someone would only need to start a process on your machine. No further exploits, no malicious signatures, no privilege escalations.

    “you need device access to exploit this” - There is no exploiting, just reading a file.








  • I don’t think that the current tools will be using it internally, since this would require the tools actually supporting the CLI launcher, and in the best case we would have something like the proton config in steam in every tool separately again.

    I think that you will need to have your launcher installed, but you will have this new launcher as your entry point, from which you will start your games using proton from the linked project.

    But - it’s a PoC right now, maybe both ways will be possible.

    From a wishful perspective, it would be super neat if this new launcher would hook into the installed regular tools, and automagically make those use the preconfigured proton runtime it brings. Shouldn’t this be possible using LD_PRELOAD?


  • Right now it’s a PoC (proof of concept, a rough implementation of an idea), to emulate launching games from other stores as if they were launched from steam using proton.

    What this could be used for is to create a new Linux launcher, where you setup proton once, and launch all games using this launcher.

    This simplifies usage for you as the end user, since you would only need to install the launcher, and it sets up ProtonGE, and you’re done. It also enables simple Proton usage for other games (Epic, Lutris, whatever).

    Additionally it helps unifying development. Windows games under Linux have a lot of moving parts: there’s Proton as a compatibility layer. There’s integration between steam, proton and your system (sniper/vessel). There’s protonfixes which is game specific changes in proton. Each of which itself consists of components and stuff I’ve missed. In short, it’s complicated. Unifying all this components with one tool, with one battle tested installation and compatibility and with a single source of truth in development could be another big step in Linux gaming.

    TLDR - potentially a new launcher for games under the Linux, enabling any game to be played using proton, when supported, not only steam games.