3 ms·

I wonder how commercial software would compare in such a situation. Assuming you have a bad actor among the employees or a breach in the security. Not a lot of

I wonder how commercial software would compare in such a situation. Assuming you have a bad actor among the employees or a breach in the security. Not a lot of eyes watching that sourcecode i'd assume.

tonnydourado 3y ago
Yeah, less eyes on it means it would be less likely to be caught, but there's also much more upfront validation on who gets to change it. Although, I can imagine a sub-sub-contractor identity being somewhat easily forged, it's still harder than just creating a GitHub account.
- wakeupcall 3y ago
  > but there's also much more upfront validation on who gets to change it. Very doubtful in my eyes. Very few companies have the strict validation which would be required to catch this. Good validation that goes into central components is often skimped on arbitrary deadlines, which companies are full of. On something tangential like this I suspect nobody would really notice. I can also hear the "I noticed now there's an extra delay which isn't supposed to be there, can I investigate?" "Sorry, but this is not critical for this deadline" agile mentality.
  - tonnydourado 3y ago
    Not sure we're talking about the same thing. By validation I mean of identity. On proprietary software , before an attacker get inside access to the code, they would have to interview, get hired, submit (presumably, fake) document id, provide (again, presumably, fake) bank details, etc. This attacker just had a GitHub account and email, as far as understood it. But, as I said, maybe tricking a sub contracting company into hiring you is not as hard. I remember working with contractors whose faces I've never seem on video, let alone in person.
    - wakeupcall 3y ago
      I didn't think of "identity" in this sense, but I don't see this as a show-stopper either. On my current jig developer churn is not high, yet I've only recently met developers hired 6+ months ago. I know first-hand only a handful of the committers I see. Barely know the most common commiters. I generally do watch commits of the trees/projects I'm interested into, but I'm a minority, and such behavior wouldn't catch something similar to the xz situation unless I'm absolutely lucky. This also ignores the fact that you can just as well corrupt a current employee.
      - tonnydourado 3y ago
        You might not know them, but HR does. No way your employer is sending them money every month without a reasonable degree of certainty that they are who they say they are. Or, at the very least, that they aren't 3 hackers in a trenchcoat. And corrupting an employee doesn't sound that easy, either. I mean, we do get paid above average. That still leaves shit third party contractors and compromising employees computers/accounts, though.
- LtWorf 3y ago
  > also much more upfront validation on who gets to change it. Some underpaid indian contractor you mean? I'm sure they'd never ever possibly accept a bribe!
JonChesterfield 3y ago
It's likely that the commercial software uses a lot of open source libraries. Maybe with attribution, maybe not. Decent chance they periodically download whatever the latest version is and link it into their software without reading it.
peteradio 3y ago
Haha, sourcecode routinely doesn't exist to be scrutinized (despite company policy). Just modify the code in prod who's going to go poking around after you there?
mr_toad 3y ago
> Assuming you have a bad actor among the employees What if the entire company is a bad actor?
- red-iron-pine 3y ago
  Which of the FAANGs are you referring to specifically?
mike_hearn 3y ago
Depends what you mean by commercial software. Consider Google. Not gonna be affected because they build everything internally themselves and for the little open source code they rely on, they replace the build system when they import it to their monorepo (or at least they used to). For everyone else? Not much different to open source.

tonnydourado 3y ago

Yeah, less eyes on it means it would be less likely to be caught, but there's also much more upfront validation on who gets to change it. Although, I can imagine a sub-sub-contractor identity being somewhat easily forged, it's still harder than just creating a GitHub account.

wakeupcall 3y ago
> but there's also much more upfront validation on who gets to change it. Very doubtful in my eyes. Very few companies have the strict validation which would be required to catch this. Good validation that goes into central components is often skimped on arbitrary deadlines, which companies are full of. On something tangential like this I suspect nobody would really notice. I can also hear the "I noticed now there's an extra delay which isn't supposed to be there, can I investigate?" "Sorry, but this is not critical for this deadline" agile mentality.
- tonnydourado 3y ago
  Not sure we're talking about the same thing. By validation I mean of identity. On proprietary software , before an attacker get inside access to the code, they would have to interview, get hired, submit (presumably, fake) document id, provide (again, presumably, fake) bank details, etc. This attacker just had a GitHub account and email, as far as understood it. But, as I said, maybe tricking a sub contracting company into hiring you is not as hard. I remember working with contractors whose faces I've never seem on video, let alone in person.
  - wakeupcall 3y ago
    I didn't think of "identity" in this sense, but I don't see this as a show-stopper either. On my current jig developer churn is not high, yet I've only recently met developers hired 6+ months ago. I know first-hand only a handful of the committers I see. Barely know the most common commiters. I generally do watch commits of the trees/projects I'm interested into, but I'm a minority, and such behavior wouldn't catch something similar to the xz situation unless I'm absolutely lucky. This also ignores the fact that you can just as well corrupt a current employee.
    - tonnydourado 3y ago
      You might not know them, but HR does. No way your employer is sending them money every month without a reasonable degree of certainty that they are who they say they are. Or, at the very least, that they aren't 3 hackers in a trenchcoat. And corrupting an employee doesn't sound that easy, either. I mean, we do get paid above average. That still leaves shit third party contractors and compromising employees computers/accounts, though.
LtWorf 3y ago
> also much more upfront validation on who gets to change it. Some underpaid indian contractor you mean? I'm sure they'd never ever possibly accept a bribe!

JonChesterfield 3y ago

It's likely that the commercial software uses a lot of open source libraries. Maybe with attribution, maybe not. Decent chance they periodically download whatever the latest version is and link it into their software without reading it.

peteradio 3y ago

Haha, sourcecode routinely doesn't exist to be scrutinized (despite company policy). Just modify the code in prod who's going to go poking around after you there?

mr_toad 3y ago

> Assuming you have a bad actor among the employees What if the entire company is a bad actor?

red-iron-pine 3y ago
Which of the FAANGs are you referring to specifically?

mike_hearn 3y ago

Depends what you mean by commercial software. Consider Google. Not gonna be affected because they build everything internally themselves and for the little open source code they rely on, they replace the build system when they import it to their monorepo (or at least they used to). For everyone else? Not much different to open source.