Live data from Hacker News

The xz backdoor thing reminds me of a story

rigor-mortis.nmrc.org

81–90 of 99 posts

Re: The xz backdoor thing reminds me of a story

#81

Most of the details are out there but … > 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.

Places with reasonable build systems can do that for you. For example, poudriere on FreeBSD.

Re: The xz backdoor thing reminds me of a story

#83

Earlier quoted context omitted.

They can’t forge a chipped passport unless they somehow got hold of the private key for the country’s CSCA certificate.

Why would you need to? Passports are not required to hire a person; most americans don’t even have one.

Proof of ability to work in the county legally is though, of which a passport is one of the allowed documents.

Re: The xz backdoor thing reminds me of a story

#84
post #82

The next time something like this happens it will be a distribution packager (RedHat, arch, etc). They'll just release a package that has extra code than a clean build from source.

Reproducible builds can help in theory, but in practice you're always using the potentially-compromised system itself to reproduce the build

Re: The xz backdoor thing reminds me of a story

#85

Earlier quoted context omitted.

> Because you’re trying to plant backdoors you don’t want any paper trail? 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...

why is that a hole?

> why is that a hole?

Presumably to avoid this:

> Because you’re trying to plant backdoors you don’t want any paper trail?

Re: The xz backdoor thing reminds me of a story

#86
post #80

Earlier quoted context omitted.

> the numbers provided for direct deposit are the same numbers used for direct/pre-authorized debit (i.e. withdrawals) 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'…

That’s the biggest difference - here there isn’t a request, the money’s just gone. I can of course go through the process of calling my bank, filing a fraud claim, waiting 6-8 weeks and then hopefully getting my money back, but that’s not particularly ideal. Especially since lots (most?) of the population is living paycheck to paycheck, and all that they have is probably sitting in the same bank account that they rec…

The median US household has $8k in checking+savings accounts, three months of expenses saved, and a net worth of $193k and therefore is probably not "living paycheck to paycheck" in the sense you meant. Also, "living paycheck to paycheck" is a made up status with no clear definition, invented by payday loan companies for lobbying purposes.

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.

Re: The xz backdoor thing reminds me of a story

#87

Earlier quoted context omitted.

It must be bad if you are using your employees as a short term LOC. An inverse payday loan.

Not really. More like, “we could make an extra hundred bucks a week by doing X”. So they do X. If it’s annoying to the employees, that cost is not considered.

Yeah it isn’t profitable when you then spend 30% of your staffing costs on hiring new people as the old ones leave

To me late payment means they are possibly insolvent so I am looking for another job.

Re: The xz backdoor thing reminds me of a story

#88
post #65
post #5

I remember a few months ago there was a discussion[1] here about how fossil, the VCS for sqlite, should bring in a dependency on mermaid charts already. 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. [1] https://news.ycombinator.com/item?id=388…

Well... supply chain attacks are trivial to anticipate. A lot of modern programming (I'm thinking JavaScript especially when I say this) involves what seems to be 100s of dependencies. If there is a 1% chance of a random repo having a backdoor, the project will be compromised. That is clear and obvious. The problem is that the people who act on this and minimise dependencies are at a significant economic disadvantage…

> 100s of dependencies. If there is a 1% chance of a random repo having a backdoor, the project will be compromised

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.

Re: The xz backdoor thing reminds me of a story

#89

Most of the details are out there but … > 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.

If you look at the Nintendo Gigaleaks, you'll discover that most of Nintendo hardware had one single CVS (later SVN) repository that held everything. Same with BroadOn, even up into 2010, when the cvs backup was taken.

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.

Re: The xz backdoor thing reminds me of a story

#90
post #65

Earlier quoted context omitted.

Well... supply chain attacks are trivial to anticipate. A lot of modern programming (I'm thinking JavaScript especially when I say this) involves what seems to be 100s of dependencies. If there is a 1% chance of a random repo having a backdoor, the project will be compromised. That is clear and obvious. The problem is that the people who act on this and minimise dependencies are at a significant economic disadvantage…

> 100s of dependencies. If there is a 1% chance of a random repo having a backdoor, the project will be compromised 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.

Eh. I suppose 3 points, all minor:

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)`.

Post reply on HN