4 ms·

> As for cargo-vet vs 2fa, as the article mentions (but I think bears emphasis), they solve different problems. I disagree. On the surface and a technical leve

> As for cargo-vet vs 2fa, as the article mentions (but I think bears emphasis), they solve different problems. I disagree. On the surface and a technical level cargo-vet and 2fa do different things, yes. However, the intended effect here is very similar. PyPi is asking some authors to use 2fa because they want to avoid popular packages getting compromised. Cargo-vet tries to achieve the same end result through a different method. > A lot of this article also seems to boil down to some sort of slippery slope. 2FA today, package signing tomorrow, the end of the world next week? I'm unconvinced. While unlikely, it does bring up the question of how much control a package index, or similar org, should be able to exert control over contributors. In theory, its their index and they are hosting your code for free so they can do as they please. On the other hand, they are the de-facto standard and are, in my opinion (perhaps a bit far fetched and certainly not as malicious as Google) the Play Store of the python world.

staticassertion 4y ago
I suppose so. To me, 2FA is solving the "who manages the package" whereas vet is a solution for distributed auditing of what the package does. Ultimately their goals align in that they're both trying to prevent an attacker from manipulating the code and having that successfully deploy to users' systems. I think they're just so wildly different in every way that it's hard to say they're solving the same problem unless you zoom way out. The reality is, however, that the `vet` approach has never been shown to work at scale, and 2FA has. 2FA has decades of implementation work, threat modeling, etc. `vet` is a one off tool for Rust and no integration into the wider ecosystem. I would love to see a `vet`-like tool for PyPI, I would love that, but saying "we could have used vet" is really glossing over a lot of practical issues. > . On the other hand, they are the de-facto standard and are, in my opinion (perhaps a bit far fetched and certainly not as malicious as Google) the Play Store of the python world. Yeah, sure. At the same time, why is it that open source maintainers get to say "I have literally 0 ethical responsibility to do anything ever"? That's the status quo - maintainers who distribute their code through these repositories owe you nothing. We accept that. But we don't hold the same thing true for the package repository? They suddenly owe the maintainers something? More directly, maintainers have their goals, repos have their goals, users have their goals. They'll align where they can, but no one is beholden to anyone else, and we can't really change that.
- deleted 4y ago
  [deleted]
raggi 4y ago
2fa aims to reduce the volume of released attacker controlled code prior to release. vet aims to reduce the volume of attacker controlled code and accidentally dangerous code after release. they operate on distinctly different timelines, against different threat models, with different actors.
- morelisp 4y ago
  Regarding the threat model and actors, the vet approach seems a superset of the 2FA approach, not really different.
  - staticassertion 4y ago
    One obvious difference is that 2FA prevents the attacker from taking ownership of the package and distributing a malicious version, vet theoretically prevents installation of the malicious version. The vet approach comes into play much later. Also, as I mentioned before, there's no evidence whatsoever that the 'vet' approach even works, let alone scales.
    - morelisp 4y ago
      I didn't say they're the same, or even practically equally effective at all cases, I said one is a superset of the other's threat model. 2FA covers cases where the attacker is not supposed to be authorized to distribute the package. But vet covers all cases where the code isn't doing what it's supposed to do; that includes cases where the attacker wasn't authorized to distribute it, but also cases where the attacker was correctly authorized, or the authorized person simply made a mistake. An actual disjoint model is something like Go's TOFU proxy, which makes no claims about who was authorized to do what or what the code should be doing, only that it's the same for everyone.

staticassertion 4y ago

I suppose so. To me, 2FA is solving the "who manages the package" whereas vet is a solution for distributed auditing of what the package does. Ultimately their goals align in that they're both trying to prevent an attacker from manipulating the code and having that successfully deploy to users' systems. I think they're just so wildly different in every way that it's hard to say they're solving the same problem unless you zoom way out. The reality is, however, that the `vet` approach has never been shown to work at scale, and 2FA has. 2FA has decades of implementation work, threat modeling, etc. `vet` is a one off tool for Rust and no integration into the wider ecosystem. I would love to see a `vet`-like tool for PyPI, I would love that, but saying "we could have used vet" is really glossing over a lot of practical issues. > . On the other hand, they are the de-facto standard and are, in my opinion (perhaps a bit far fetched and certainly not as malicious as Google) the Play Store of the python world. Yeah, sure. At the same time, why is it that open source maintainers get to say "I have literally 0 ethical responsibility to do anything ever"? That's the status quo - maintainers who distribute their code through these repositories owe you nothing. We accept that. But we don't hold the same thing true for the package repository? They suddenly owe the maintainers something? More directly, maintainers have their goals, repos have their goals, users have their goals. They'll align where they can, but no one is beholden to anyone else, and we can't really change that.

deleted 4y ago
[deleted]

raggi 4y ago

2fa aims to reduce the volume of released attacker controlled code prior to release. vet aims to reduce the volume of attacker controlled code and accidentally dangerous code after release. they operate on distinctly different timelines, against different threat models, with different actors.

morelisp 4y ago
Regarding the threat model and actors, the vet approach seems a superset of the 2FA approach, not really different.
- staticassertion 4y ago
  One obvious difference is that 2FA prevents the attacker from taking ownership of the package and distributing a malicious version, vet theoretically prevents installation of the malicious version. The vet approach comes into play much later. Also, as I mentioned before, there's no evidence whatsoever that the 'vet' approach even works, let alone scales.
  - morelisp 4y ago
    I didn't say they're the same, or even practically equally effective at all cases, I said one is a superset of the other's threat model. 2FA covers cases where the attacker is not supposed to be authorized to distribute the package. But vet covers all cases where the code isn't doing what it's supposed to do; that includes cases where the attacker wasn't authorized to distribute it, but also cases where the attacker was correctly authorized, or the authorized person simply made a mistake. An actual disjoint model is something like Go's TOFU proxy, which makes no claims about who was authorized to do what or what the code should be doing, only that it's the same for everyone.