3 ms·

One of the places this worried me the most was Golang, where domains for repositories are used as a package source. Credit where credit's due, when I contacted

One of the places this worried me the most was Golang, where domains for repositories are used as a package source. Credit where credit's due, when I contacted Google about a developer who had passed before their domain expired, and they were able to lock out the domain from pulling anything new into their cache.

snickerdoodle12 1y ago
On the other hand it's pretty crazy you could just get a domain blacklisted like that
- ocdtrekkie 1y ago
  It was quite possible to independently prove my report was genuine. I am confident they didn't take my word for it. I give Google a lot of well-deserved criticism, but they handled this issue pretty well and quite promptly.
  - sidewndr46 1y ago
    Couldn't you pay pretty much any random official in a corrupt country to produce a death certificate in any name you want? Maybe it's a bigger bribe than normal, but it seems like it would be routine
    - ocdtrekkie 1y ago
      So this is where I'd highlight the benefits that an actual human looked at and responded to my email (a rarity for Google), and hence could use human discretion to decide that what I indicated was indeed accurate, and not randomly from a random corrupt country. I really have to emphasize: Any security process that actually works has humans in the loop! (Security doesn't scale.) The other thing of course, is that the domain was expiring. So similar to PyPI just accepting in the parent article that an expired domain isn't trustworthy, Google could verify shortly thereafter whether or not the domain was renewed by the developer in question. And ultimately, you're suggesting paying off an official to pretend someone is dead, so you can block package updates to a domain, which doesn't really introduce a security issue, and of course, is trivially reversible when the person in question is, in fact, still alive. As Tony Stark would say, "Not a good plan".
      - sidewndr46 1y ago
        I don't think you've ever dealt with the likes of US credit bureaus if you think getting something like a death announcement is "trivially reversible". I forever am and forever will be a civil engineer somewhere in upstate New York thanks to them. Nevermind I was still in high school at the time and don't even have a shred of engineering qualifications. Whoever you are, thanks for the borrowed ladder my friend.
        vdqtp3 1y ago
        Reminds me of this presentation from a decade ago https://www.youtube.com/watch?v=9FdHq3WfJgs https://www.youtube.com/watch?v=9FdHq3WfJgs
sneak 1y ago
go’s lockfiles include cryptographic hashes which prevent even Google from maliciously replacing packages in the cache.
- ocdtrekkie 1y ago
  A malicious actor could, however, quite trivially add one to the version number. ;)
  - arccy 1y ago
    No technical solution is going to save you from an upstream going rogue and you blindly updating. The only way is to properly review your dependencies.
    - dwattttt 1y ago
      The problem isn't an upstream going rogue; it's an upstream going dark, and someone taking advantage of that. Upstreams going dark happens much more often than them going rogue. A system that requires you to prove more than you just control a domain isn't as vulnerable to this problem.
- junon 1y ago
  This doesn't address availability or discoverability though. There are no upsides other than a fleeting sense of "decentralization", without any of the securities of a real decentralized protocol.
- tsimionescu 1y ago
  For a given version, yes. But the security risk here is about publishing a new (malicious) version of a previously trusted package, by taking control of an expired domain. Say I'm using mydomain.org/abc and it's a perfectly fine package. I'm currently using v1.25.7. Two months later, I see a new version of mydomain.org/abc, v1.25.8. I will likely update to it and use it relatively confidently. But, unbeknownst to me, mydomain.org's registration expired one month ago, and a malicious actor has grabbed it in the meantime; and they have now released a malicious version of this package. Nothing in Go's security model prevents this type of attack, except that Google's package "cache" (the package repo that Go downloads things from) can be configured by Google to not provide that malicious package. This is a major design flaw with the silly idea of using an extremely imparmenent identifier - DNS names, which can only be leased for a limited time and are automatically auctioned off after they expire - as the main identifier for something as long lived as Go packages. No other package ecosystem has this terrible design concept - even when they do use DNS, they use it only for an initial authentication, not as the only identifier. For example, in Java's Maven repo, to publish a package org.mydomain.abc from a Maven Central account, you need to prove that you have ownership of abc.mydomain.org once when associating this package. Afterwards, the package name remains associated with your Maven Central account, forever. If you lose access to that domain name and someone else obtains, they can't go through the same steps, Maven Central won't let them, since that package name is already tied to your account.
junon 1y ago
This is why URI based imports make little sense to me, honestly.
WhyNotHugo 1y ago
go.mod keeps checksums, so this should come up easily for downstream consumers. However, when devs change dependencies, an innocent `go mod …` might update to a new (compromised) version of a dependency.

snickerdoodle12 1y ago

On the other hand it's pretty crazy you could just get a domain blacklisted like that

ocdtrekkie 1y ago
It was quite possible to independently prove my report was genuine. I am confident they didn't take my word for it. I give Google a lot of well-deserved criticism, but they handled this issue pretty well and quite promptly.
- sidewndr46 1y ago
  Couldn't you pay pretty much any random official in a corrupt country to produce a death certificate in any name you want? Maybe it's a bigger bribe than normal, but it seems like it would be routine
  - ocdtrekkie 1y ago
    So this is where I'd highlight the benefits that an actual human looked at and responded to my email (a rarity for Google), and hence could use human discretion to decide that what I indicated was indeed accurate, and not randomly from a random corrupt country. I really have to emphasize: Any security process that actually works has humans in the loop! (Security doesn't scale.) The other thing of course, is that the domain was expiring. So similar to PyPI just accepting in the parent article that an expired domain isn't trustworthy, Google could verify shortly thereafter whether or not the domain was renewed by the developer in question. And ultimately, you're suggesting paying off an official to pretend someone is dead, so you can block package updates to a domain, which doesn't really introduce a security issue, and of course, is trivially reversible when the person in question is, in fact, still alive. As Tony Stark would say, "Not a good plan".
    - sidewndr46 1y ago
      I don't think you've ever dealt with the likes of US credit bureaus if you think getting something like a death announcement is "trivially reversible". I forever am and forever will be a civil engineer somewhere in upstate New York thanks to them. Nevermind I was still in high school at the time and don't even have a shred of engineering qualifications. Whoever you are, thanks for the borrowed ladder my friend.
      - vdqtp3 1y ago
        Reminds me of this presentation from a decade ago https://www.youtube.com/watch?v=9FdHq3WfJgs https://www.youtube.com/watch?v=9FdHq3WfJgs

sneak 1y ago

go’s lockfiles include cryptographic hashes which prevent even Google from maliciously replacing packages in the cache.

ocdtrekkie 1y ago
A malicious actor could, however, quite trivially add one to the version number. ;)
- arccy 1y ago
  No technical solution is going to save you from an upstream going rogue and you blindly updating. The only way is to properly review your dependencies.
  - dwattttt 1y ago
    The problem isn't an upstream going rogue; it's an upstream going dark, and someone taking advantage of that. Upstreams going dark happens much more often than them going rogue. A system that requires you to prove more than you just control a domain isn't as vulnerable to this problem.
junon 1y ago
This doesn't address availability or discoverability though. There are no upsides other than a fleeting sense of "decentralization", without any of the securities of a real decentralized protocol.
tsimionescu 1y ago
For a given version, yes. But the security risk here is about publishing a new (malicious) version of a previously trusted package, by taking control of an expired domain. Say I'm using mydomain.org/abc and it's a perfectly fine package. I'm currently using v1.25.7. Two months later, I see a new version of mydomain.org/abc, v1.25.8. I will likely update to it and use it relatively confidently. But, unbeknownst to me, mydomain.org's registration expired one month ago, and a malicious actor has grabbed it in the meantime; and they have now released a malicious version of this package. Nothing in Go's security model prevents this type of attack, except that Google's package "cache" (the package repo that Go downloads things from) can be configured by Google to not provide that malicious package. This is a major design flaw with the silly idea of using an extremely imparmenent identifier - DNS names, which can only be leased for a limited time and are automatically auctioned off after they expire - as the main identifier for something as long lived as Go packages. No other package ecosystem has this terrible design concept - even when they do use DNS, they use it only for an initial authentication, not as the only identifier. For example, in Java's Maven repo, to publish a package org.mydomain.abc from a Maven Central account, you need to prove that you have ownership of abc.mydomain.org once when associating this package. Afterwards, the package name remains associated with your Maven Central account, forever. If you lose access to that domain name and someone else obtains, they can't go through the same steps, Maven Central won't let them, since that package name is already tied to your account.

junon 1y ago

This is why URI based imports make little sense to me, honestly.

WhyNotHugo 1y ago

go.mod keeps checksums, so this should come up easily for downstream consumers. However, when devs change dependencies, an innocent `go mod …` might update to a new (compromised) version of a dependency.