5 ms·

Good warning for the future... but what about the past? Any thoughts on retroactively looking at behavior for existing OS projects? Seems like an impossible amo

Good warning for the future... but what about the past? Any thoughts on retroactively looking at behavior for existing OS projects? Seems like an impossible amount of work.

andix 2y ago
Maybe not so impossible. Start with making a list of projects that are everywhere. Inside every Linux distribution, inside every react/angular/vue/etc project, … Then check which companies support those projects with active development, and calculate a rating. Are the companies located inside democracies or are they mostly from china or Russia? It’s probably not that many packages in the end. A few thousand high impact/risk projects probably.
- int0x29 2y ago
  Backdoor attempts won't be that obvious. The xz incident just had a random unaffiliated burner account and nothing of any clear national origin.
  - andix 2y ago
    I wanted to make a different point. If for example Google or Red Hat were deeply involved within the xz project, there might have been more people reviewing the code. The evil changes to xz were easy to overlook, but not impossible to notice. Especially the added "accidential" semicolon made me think about probabilities. I think in a code review I would notice that with a probability of 10-20%. So if 10 people would've looked at it, there might have been quite a low chance to get away with it. Having some high profile companies involved into an open source project the risk score would drop in my opinion, which would highlight the projects that are completely community maintained, and might be more susceptible. Having such a list might be a security threat by itself though, because attackers would focus on the "low risk" projects first.
    - galaxyLogic 2y ago
      One possibility could be a license that requires big companies to dedicate one or more people as maintainers or at least reviewers of a project if they want to get license to use the software.
      - andix 2y ago
        GPLv4? I doubt this would be a bigger success story than v3 and v2. Permissive licenses won the war against Copyleft a long time ago.
- BobbyTables2 2y ago
  The list you speak of already exists — it is the package registries of Debian/Ubuntu, RHEL, etc. What about American companies using mainland China developers to drive their (well known) open source projects with crappy code? Who’s to blame? We’re currently smoking at the gas station and things haven’t blown up yet…
  - mistercheph 2y ago
    It would be nearly impossible to ignite gasoline or its fumes with a lit cigarette.
01100011 2y ago
I think the only feasible option, due to the shortage of SWE talent, is a combination of automation, tooling and safer languages. We need better threat analysis systems, and we need to rely more on safe-by-default languages that make program behavior more obvious.

Good warning for the future... but what about the past? Any thoughts on retroactively looking at behavior for existing OS projects? Seems like an impossible amount of work.

andix 2y ago

Maybe not so impossible. Start with making a list of projects that are everywhere. Inside every Linux distribution, inside every react/angular/vue/etc project, … Then check which companies support those projects with active development, and calculate a rating. Are the companies located inside democracies or are they mostly from china or Russia? It’s probably not that many packages in the end. A few thousand high impact/risk projects probably.

int0x29 2y ago
Backdoor attempts won't be that obvious. The xz incident just had a random unaffiliated burner account and nothing of any clear national origin.
- andix 2y ago
  I wanted to make a different point. If for example Google or Red Hat were deeply involved within the xz project, there might have been more people reviewing the code. The evil changes to xz were easy to overlook, but not impossible to notice. Especially the added "accidential" semicolon made me think about probabilities. I think in a code review I would notice that with a probability of 10-20%. So if 10 people would've looked at it, there might have been quite a low chance to get away with it. Having some high profile companies involved into an open source project the risk score would drop in my opinion, which would highlight the projects that are completely community maintained, and might be more susceptible. Having such a list might be a security threat by itself though, because attackers would focus on the "low risk" projects first.
  - galaxyLogic 2y ago
    One possibility could be a license that requires big companies to dedicate one or more people as maintainers or at least reviewers of a project if they want to get license to use the software.
    - andix 2y ago
      GPLv4? I doubt this would be a bigger success story than v3 and v2. Permissive licenses won the war against Copyleft a long time ago.
BobbyTables2 2y ago
The list you speak of already exists — it is the package registries of Debian/Ubuntu, RHEL, etc. What about American companies using mainland China developers to drive their (well known) open source projects with crappy code? Who’s to blame? We’re currently smoking at the gas station and things haven’t blown up yet…
- mistercheph 2y ago
  It would be nearly impossible to ignite gasoline or its fumes with a lit cigarette.

01100011 2y ago

I think the only feasible option, due to the shortage of SWE talent, is a combination of automation, tooling and safer languages. We need better threat analysis systems, and we need to rely more on safe-by-default languages that make program behavior more obvious.