Isn’t Ubuntu Pro basically just an extended support for a set of universe packages for their LTS versions and free for private use?
How is making enterprises pay for extended LTS because of corporate no-update-just-insert-coin mentalities even remotely close to ransomware?
Like I get everyone who doesn’t like Ubuntu for various reasons, but this sounds completely dumb to me.
The smallest footprint for an actual scripting probably will be posix sh - since you already have it ready.
A slightly bigger footprint would be Python or Lua.
If you can drop your requirement for actual scripting and are willing to add a compile step, Go and it’s ecosystem is pretty dang powerful and it’s really easy to learn for small automation tasks.
Personally, with the requirement of not adding too much space for runtimes, I’d write it in go. You don’t need a runtime, you can compile it to a really small zero dependency lib and you have clean and readable code that you can extend, test and maintain easily.
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.
Chrome cookies are encrypted, for exactly the reasons stated. If malware gains access to your system and compromises it in a way that DPAPI calls can be replicated in the way Chrome does it, then your sessions will also be compromised. But this is way harder to do, and at least prevents trivial data exfiltration.
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.
Yes, in your head, and in your second factor, if possible, keeping derived secrets always encrypted at rest, decrypting at the latest possible moment and not storing (decrypted) secrets in-memory for longer than absolutely necessary at use.
Been a few days since using electron, but AFAIK electron can’t be used as a wrapper for android apps, or can it? Or is their android app a web app wrapped into a “native” android app too?
Also, since this seems to be an issue since 2018, 6 years should be plenty to rewrite using a native secure storage…
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.
Take the following with a grain of salt, it depends on your specific setup, environment and preference, but might help you:
Regarding system backups, and depending whether you need to run fedora, check out nixos, which takes a declarative file and builds your system based on that. Declarative immutable system, no moving parts, no breakage. If your system breaks, revert to a prior version and keep using what you’ve had before before retrying. Your backup is a git repo or whatever is keeping your handful of config files. Has been an absolute game changer for me, and the community and ecosystem around it is far beyond the point of quirky esoteric immutable distro.
VSCode has a powerful feature that I’ve yet to see in another editor/IDE - remote development, and it works really, really well. Spin up a VM however you like (I’d recommend checking out Vagrant), and depending on how much you need to do in windows either use the windows box as a remote run target (just running your built artifact in windows), or as a remote development box (running everything in windows and using your Linux VSCode as a “Frontend” for everything else happening in windows). Both methods can be made to work seamlessly in vsc.
Excel - again depending on your usage, you can try wine, you can use a VM, dual boot, M365 in browser, or a remote VM.