All of this would be avoided if Debian downloaded from GitHub's distributions of the source code, albeit unsigned.
In that case they would have just put it in the repo, and I'm not convinced anyone would have caught it. They may have obfuscated it slightly more.
It's totally reasonable to trust a tarball signed by the maintainer, but there probably needs to be more scrutiny when a package changes hands like this one did.
it had a way to know it was being emissions tested and so it adapted to that.
Not sure why you got downvoted. This is a good analogy. It does a lot of checks to try to disable itself in testing environments. For example, setting TERM will turn it off.
GrapheneOS + Pixel phone is the only true option if you want any kind of ensure that even of the device is lost your data won't be accessed.
I think that's an exaggeration. You don't need secure boot for your data to be encrypted. What secure boot prevents is someone modifying the device without your knowledge (e.g. to capture your keys).
There's a couple of ways I could imagine debugging this.
One would be to disassemble MapEngine.MapsContainer.IsExists and see why it would throw that exception. It's quite strange because it should act like it's running on windows.
The other would be to enable WINEDBG stuff or possibly use strace to figure out what it did before throwing that exception.
According to the Journal, plaintiff attorneys usually get one-third of a verdict or settlement amount.
This isn't a an amount awarded in a verdict though, is it?
Plaintiff's Counsel have not been paid for their work, nor have any of their costs or expenses been reimbursed, and litigating this Action required the allocation of a substantial amount of Plaintiff's Counsel's time and resources over six years, including considerable out-of-pocket expenses,
So that's roughly 100 lawyers working full time for 6 years at $5k per hour. Seems legit.
In any case this is hilarious and exactly the kind of thing Elon would try.
I feel like node's async model makes it really easy to cause a bug like this, and really difficult to track it down.
It was left to the OS to catch the leak, because the program was written in such a way that it was able to run a gazillion of these tasks concurrently.
I wonder if anyone is doing large scale searches for source releases that differ in meaningful ways from their corresponding public repos.
It's probably tough due to autotools and that sort of thing.