4 ms·

My understanding is that validating identity for package authors is a hard problem thus expensive to solve robustly, and the crates.io folks have hitherto defer

My understanding is that validating identity for package authors is a hard problem thus expensive to solve robustly, and the crates.io folks have hitherto deferred tackling it in earnest. That is arguably a responsible approach up to a point, in that they haven't committed prematurely to something half-baked. As described elsethread, there is prior art — Maven's identity verification is substantially better: https://news.ycombinator.com/item?id=29266591 https://news.ycombinator.com/item?id=29266591 Validating ownership of a namespace reliably enough that it is difficult to spoof is tough. It's possible for PGP creds to be stolen. But then at least the keys can be revoked, and old packages signed with a new key.

miohtama 5y ago
I believe Debian Maintainer process and its keyring is one, if not only, project that gets this as good as it can get. https://wiki.debian.org/DebianMaintainer https://wiki.debian.org/DebianMaintainer
PragmaticPulp 5y ago
They don’t need to validate anything, though. Just treat the namespace as something that can be claimed exactly the way that a crate name can be claimed. Only owners of the namespace can add crates to that namespace, in the same way that only people who own a crate name can publish to that crate.
- kibwen 5y ago
  If you're not validating anything, then that violates the assumptions of users who see an amazon/ namespace that isn't officially associated with Amazon. We don't even need to presume malicious or squatting intent; the entire left-pad fiasco was precipitated by a person who innocently registered "kik", and then later a company named Kik demanded that NPM transfer ownership to them. This happened with a package, but it would just as easily happen with a namespace. Once you introduce an identity layer, people start to expect identity validation. It's a problem worth solving, but crates.io would need to move beyond being merely staffed by part-time volunteers to solve it.
  - anderskaseorg 5y ago
    > This happened with a package, but it would just as easily happen with a namespace. But that’s exactly the point. This is equally a problem for packages and namespaces, so it should not be considered a reason to avoid adding namespaces to a system that already supports packages. And namespaces do help. Yes, maybe the user has to externally validate that the namespace is registered to the owner they expect, just like they would for an individual package. But the difference is that, with a namespace, they’ve now validated the ownership of every package inside it and don’t need to repeat this process for each package.
    - kibwen 5y ago
      > But that’s exactly the point. This is equally a problem for packages and namespaces, so it should not be considered a reason to avoid adding namespaces to a system that already supports packages. I think this is missing that crates.io doesn't transfer packages between owners. That NPM decided that it was acceptable to unilaterally transfer ownership of the kik package from the original maintainer was an lapse of judgment on their part. It would be unprecedented for crates.io to begin doing so. > And namespaces do help. I agree with this entire paragraph and have made these same arguments in favor of namespaces before. As I mentioned, I am mildly a proponent of namespaces. But we can't delude ourselves into thinking that an identity layer is simple to maintain, regardless of how much we want namespaces. It's a messy social problem.
not2b 5y ago
Robustly verifying identity isn't enough, because a developer with an outstanding reputation could lose their credentials to a spearphishing attack, and the attacker could then modify crates using stolen credentials.
- rectang 5y ago
  I agree that authentication is not sufficient on its own, but I argue that it's necessary as part of the solution. A source package should meet the following criteria: • Package contents match exactly the source tree at a PGP signed commit at a public repository URL. This must be verified before the package is made available through the package manager. Now, if I am whitelisting PGP keys, an attacker needs to steal creds to get something by me. Ideally you want multiple signatures by trusted keys prior to publication. Each additional signature makes it significantly less likely that a package is provided by a malicious attacker. EDIT: Hmm, how about package signing parties held over videochat? If we already know each other and you tell me that a particular package was created by you, I sign it.

miohtama 5y ago

I believe Debian Maintainer process and its keyring is one, if not only, project that gets this as good as it can get. https://wiki.debian.org/DebianMaintainer https://wiki.debian.org/DebianMaintainer

PragmaticPulp 5y ago

They don’t need to validate anything, though. Just treat the namespace as something that can be claimed exactly the way that a crate name can be claimed. Only owners of the namespace can add crates to that namespace, in the same way that only people who own a crate name can publish to that crate.

kibwen 5y ago
If you're not validating anything, then that violates the assumptions of users who see an amazon/ namespace that isn't officially associated with Amazon. We don't even need to presume malicious or squatting intent; the entire left-pad fiasco was precipitated by a person who innocently registered "kik", and then later a company named Kik demanded that NPM transfer ownership to them. This happened with a package, but it would just as easily happen with a namespace. Once you introduce an identity layer, people start to expect identity validation. It's a problem worth solving, but crates.io would need to move beyond being merely staffed by part-time volunteers to solve it.
- anderskaseorg 5y ago
  > This happened with a package, but it would just as easily happen with a namespace. But that’s exactly the point. This is equally a problem for packages and namespaces, so it should not be considered a reason to avoid adding namespaces to a system that already supports packages. And namespaces do help. Yes, maybe the user has to externally validate that the namespace is registered to the owner they expect, just like they would for an individual package. But the difference is that, with a namespace, they’ve now validated the ownership of every package inside it and don’t need to repeat this process for each package.
  - kibwen 5y ago
    > But that’s exactly the point. This is equally a problem for packages and namespaces, so it should not be considered a reason to avoid adding namespaces to a system that already supports packages. I think this is missing that crates.io doesn't transfer packages between owners. That NPM decided that it was acceptable to unilaterally transfer ownership of the kik package from the original maintainer was an lapse of judgment on their part. It would be unprecedented for crates.io to begin doing so. > And namespaces do help. I agree with this entire paragraph and have made these same arguments in favor of namespaces before. As I mentioned, I am mildly a proponent of namespaces. But we can't delude ourselves into thinking that an identity layer is simple to maintain, regardless of how much we want namespaces. It's a messy social problem.

not2b 5y ago

Robustly verifying identity isn't enough, because a developer with an outstanding reputation could lose their credentials to a spearphishing attack, and the attacker could then modify crates using stolen credentials.

rectang 5y ago
I agree that authentication is not sufficient on its own, but I argue that it's necessary as part of the solution. A source package should meet the following criteria: • Package contents match exactly the source tree at a PGP signed commit at a public repository URL. This must be verified before the package is made available through the package manager. Now, if I am whitelisting PGP keys, an attacker needs to steal creds to get something by me. Ideally you want multiple signatures by trusted keys prior to publication. Each additional signature makes it significantly less likely that a package is provided by a malicious attacker. EDIT: Hmm, how about package signing parties held over videochat? If we already know each other and you tell me that a particular package was created by you, I sign it.