The xz backdoor thing reminds me of a story
rigor-mortis.nmrc.org
rigor-mortis.nmrc.org
Nothing against mermaid, but I guess supply chain attacks are hard to conceptualise until they happen. When we're shortsighted we risk our mitigations against vague but serious threat models losing out against convenience.
The problem is that the people who act on this and minimise dependencies are at a significant economic disadvantage to those who don't. A project with high risk tolerance has to write a fraction of the code and solve a fraction of the problems as someone who carefully writes secure software.
The trade off isn't just "convenience", we're talking massive differentials in productivity that favour insecure models. It is much cheaper to accept that data will leak sooner or later, to the point where we can assume that if something is economically developed that is evidence it can't possibly be secure. That isn't an argument for more security though; if possible it is better to just design systems where leaks don't matter (eg, here in HN it isn't clear why I'd care about a leak - everything is already public except for the IP address in the server log).
People say this, but it my experience, it simply isn't true. You're at a _slight_ economic disadvantage, and if you anticipate it, and correctly staff and plan for it, it's entirely manageable. The huge win is that in the long run you are massively more productive and you're not held back by framework incompatibilities, version updates, or web standards changing faster than you can keep up.
Many shops don't have the mentality or the expertise to actually do this, partly I feel because this canard as taken as rank truth and no one ever dares to challenge it. Web standards have gotten much better in the past 10 years, they're actually pleasant and useful now.
> we're talking massive differentials in productivity
You have an ability to get something that feels "fully featured" off the ground more quickly. I'd wait for the actual user reviews before I make a decision on the quality of the output.
Apologies for nit-picking, but that's not quite how sum-of-probabilities work. Total probability across 200 tries of 1% chance each, is ~87%:
p=0
for _ in range(200):
p=p+(1-p)*.01
print(p)
0.8660203251420382
Your "sooner or later, to the point where we can assume" conclusion, still stands, of course.1) Best of luck in an audit explaining that there is almost a 14% chance that your project is free of backdoors given reasonable assumptions. I recommend taking a photo of the auditor's expression and reporting back.
2) There are quibbles to be had about the IID assumption here; dependencies tend aren't selected randomly and attackers aren't targeting them randomly.
3) You don't need a for loop for that, you can calculate directly with `1-(0.99*200)`.
Someone had started work on this, but was unable to complete it. The maintainers were willing to consider the idea, but not do it themselves, which is (always, for any request, on any open source project, at any time) completely understandable.
I still think it would be great if someone with the ability/interest/time made it happen. Version control is useful for many things other than software, and fossil's architecture is well-suited for a linkable all-purpose revision control library.
> in that he had apparently downloaded a copy of everything
… is a day in the office? I've done this, particularly at places that are "one repo == one project" organized (i.e., not monorepo): e.g., if I make a breaking change to a library, I'm going to update all the uses of that. Still to this day, the easiest way to do that is locally, with command line tooling.
It's fairly well known that Google maintained a Stinky monorepo for a long time and one of the risks is someone just going and slurping the whole thing up onto a big enough drive and walking out the door.
They'll just release a package that has extra code than a clean build from source.
This is the part that doesn't make sense. But the other sibling comment is probably right. It might have been before e-verify was widely in use. Besides, you just run through Checkr and friends unless you know the guy, so this "no record of him" thing would pop up these days.
I suppose I'm not too concerned about this attack vector now that we have this stuff.
Here (.nl) you need either a passport or an ID card and you are supposed to verify its authenticity.
Meaning you can use a social security number of a dead person. A common form of immigration fraud.
In Germany you definitely don't have to. None of my past or current employers has ever seen my ID.
Not saying this helps in any way for employment purposes today, but the technology is out there in many places.
But seriously, why would they not be able to? They will almost certainly have high-level connections into the State Dept. (or whatever agency issues passports for your country) that allows them to create any passports they need. Same way the Police can get license plates for undercover vehicles from the DMV that don't list "One Police Plaza" if someone (i.e. "other" Police) runs the plates.
I don't understand this. People were paid by cheque in the early 2000s?
Back in the 90s when I worked for Atari (Back in the terrible Warner period) you could only get DD at the company's bank, which was a small bank with one branch, in Sunnyvale (surely the company had another bank or two as well?). I was told they did this so they could invest the float over the week end and early in the week.
To me late payment means they are possibly insolvent so I am looking for another job.
Quite unusual for a tech contractor though.
As a Norwegian that sounds so alien. They couldn't do anything but deposit money, so why wouldn't you?
Reading up on that, it seems similar in nature to our AvtaleGiro[1]. While indeed having my account number would allow a business to issue a AvtaleGiro request, it's just a request. I would then have to go to my (online) bank and approve it, including setting up a monthly withdrawal limit. So it can't happen without action on my part.
> They’re also the same numbers that appear on cheques, so someone could easily forge a cheque in your name with those numbers.
Cheques I don't know about because they were going the way of the Dodo even when I was young, but we did have BrevGiro[2] which was a way to transfer money. However it relied on the bank sending me serialized pre-filled forms, so someone would have to steal one of those as well to be able to withdraw money from my account.
However, many Americans do say on surveys that they are doing it. This happens even if they say their income is $200k/year. The likely explanation for this is that nobody knows what it means and are answering something like "if I missed a paycheck I'd feel bad about it".
https://twitter.com/besttrousers/status/1753260817389162516
A funny thing that happens with this discourse is that it comes up all the time, and every single time a hundred people reply those numbers are a trick because of outlier rich people, and then it turns out none of them know what a median is.
Almost everyone does direct deposit. But it’s not a legal requirement for an employee to be paid that way.
Good point, good point...
I went to check, and it seems we've just recently plugged[1] that hole here in Norway. Salary and other benefits must be paid to a bank account now.
[1]: https://www.gpokonomi.no/2022/01/26/forbud-mot-kontant-utbet...
Presumably to avoid this:
> Because you’re trying to plant backdoors you don’t want any paper trail?
There's companies that make their money on selling (now, usually older folk) literal books of cheques. One of the ways you can pay is literally for them to write themselves a cheque from "you" that gets processed digitally.
The US is a strange banking system wherein I have had the unpleasant experience of putting my card into the reader at a 7-11 and it just... Not work. Why? Nobody knows. ApplePay sometimes works -- some readers know how to handle it, others lose their shit and crash.
My clients usually issue paper checks online. Their bank prints the check and mails it. My receiving address is my bank, which deposits checks for me when they arrive.
Yes, you can get wire transfers or ACH at most banks with a routing number and account number. But wire transfers usually cost money to send, and sometimes cost money to get. Generalized ACH transfers usually come through a service provider, and that costs money too.
Also, the same numbers can be used to credit and debit an account, and also to forge checks. So giving your payment credentials (or writing a check) is a security risk. I'm a little fuzzy on details, but someone at my employer at the time (Facebook) had my payroll data on a device in a laptop bag that got stolen in San Francisco, and as a result I had to be hyper vigilant on checking for unauthorized transactions (or get a new account number, but that's more disruptive, assuming the theft was just normal SF theft, like it probably was)
And the payee doesn’t need to share their bank info.
https://engineering.gusto.com/how-ach-works-a-developer-pers...
(From parent) > And the payee doesn’t need to share their bank info.
And this is a US concept where having the magic numbers lets you pull any amount you want, with no ability to have a "push only" number...
The account number is on the invoice..
Leaving the checks uncashed means there's less of a paper trail to follow.
Once you get banks involved, seems like more of a risk of something getting flagged there rather than someone in payroll noticing cheques weren't deposited within the time you were there.
In short: the details of this story make no sense for the implied narrative (spy). They make a lot of sense for "not mentally well person" or "guy who suddenly had to disappear for other reasons". Combined with just "regular software developer things".
For example - I've cloned the entire git repository server of every place I've ever worked at. I have a script which does it for Github and Gitlab, because usually when you're exploring a codebase you wind up needing just "every repo" and it's easier to dump it all in a folder on my work machine ahead of time. I've run "find" on a network share because have you ever tried to figure out where a particular word document might be after looking through 10+ years of random SMB share naming systems and empty folders?
Read the stories of long-term agents from the Cold War - for both sides, but Russians in America is easier to find the stories of. Spies don't act secretive, spies blend by acting normal. They're an unremarkable next door neighbor who never draws any attention and works a respectable job. They're polite to their neighbors but keep to themselves, they do things on time and promptly, they have identities that check out and do normal things like "get paid from a regular job".
Whereas people absolutely can and do simply ghost jobs all the time. Like a simple explanation here for this guy would be "was actually an illegal immigrant and someone told him that going from contractor to full time employee might be too much exposure, got spooked and bailed". Probably was just an actual software developer. And if you here "illegal immigrant" and think "Mexican" you're also wrong - plenty of people overstay or exceed the bounds of their visas in the US.
P.S. "contributed a large number of commits to the project he was assigned to" - you know, as would be expected when you're hired to work on something? What was in those commits? Why is it omitted from the story?
I don't disagree that it was poor opsec, but the rest of the story makes it clear enough that they were burning the identity/employee quickly enough that it really didn't matter.
They are still ubiquitous today, let alone in the early 2000s.