6 ms·

> The only alternative to arbitrating your own identity layer is to tie yourself to some other preexisting identity layer (e.g. GitHub, DNS) Devolving identity

> The only alternative to arbitrating your own identity layer is to tie yourself to some other preexisting identity layer (e.g. GitHub, DNS) Devolving identity down to DNS has been a really good decision for Go. I'm not sure why everyone doesn't do it. It's like XML namespaces, but actually useful.

kryptiskt 6y ago
Organizations live shorter than packages, just look at all the com.sun stuff in Java. And even in the absence of corporate changes, you may well want to transfer a package to a new home.
the_mitsuhiko 6y ago
> Devolving identity down to DNS has been a really good decision for Go If it works for go, the because go is not old enough. Domain registrations lapse quickly and then someone else can buy them. That's very close to the worst that can happen for trust in packages.
- kelnos 6y ago
  Ok, then how about Maven Central? They give you publishing rights to a particular group ID by verifying your ownership of the corresponding DNS names. They've been around long enough, I think, even if Go hasn't.
  - tsimionescu 6y ago
    Maven Central uses that as a first-time verification (actually, it's OSSRH that requires this, technically there are other ways to publish to Maven Central). Golang's package system depends on the current DNS records. With maven, there are plenty of old projects that do not own the domain names for their group ID, and that doesn't cause any problems - they are well-known, established projects, and there's no reason to introduce breaking changes to everyone just because they want to go through some DNS naming changes. Because of this, there's little reason to fear that if you publish your project today as "io.github.my-project:my-module" you may find yourself having to break all your users if github blocks your account tomorrow (or just changes their URL schema) and you move to gitlab.
- tedunangst 6y ago
  For better or worse, nearly everyone uses github, which also provides second level name spacing.
- earthboundkid 6y ago
  If you lose your domain, spreading bad software is the least of your concerns. They can reset all email passwords and access every service you’ve ever used.
  - reificator 6y ago
    > If you lose your domain, spreading bad software is the least of your concerns. But if you lose your domain spreading bad software is the top of my concerns.
    - earthboundkid 6y ago
      Either the package manager site allows email resets and the same issue applies, or it doesn’t and you can be locked out forever by forgetting a password. Both failure modes suck.
      - reificator 6y ago
        You're still assuming the domain owner's participation. How many domains lapse while the owner is active and responsive in the community?
        earthboundkid 6y ago
        You just agreed with my original point that outsourcing identity to DNS/TLS is a good practice!
  - dragonwriter 6y ago
    > If you lose your domain, spreading bad software is the least of your concerns. OTOH, it's probably higher on the list of downstream code users’ lost of concerns. > They can reset all email passwords and access every service you’ve ever used Not if you dealt with all that before letting the domain lapse. And if you don't, more to the point, that's your problem, but not the package manager user communities problem. And that it is a bigger concern of yours than the impacts on the package manager user community is exactly why that community might want to protect themselves from you neglecting their concerns..
tsimionescu 6y ago
Not really. Look at the protobuf 'renaming' and think about how silly that is.
- solipsism 6y ago
  Protobuf renaming?
  - tsimionescu 6y ago
    I was referring to this: https://blog.golang.org/protobuf-apiv2 https://blog.golang.org/protobuf-apiv2 > The github.com/golang/protobuf module is APIv1. > The google.golang.org/protobuf module is APIv2. We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider. Basically, Google realized that it's not a good idea to tie your package's identity to GitHub's URL scheme. This is easy for Google to fix, but the majority of Go packages suffer from the same problem, and it is much harder for a small project to start maintaining a DNS record that they control to point that to GitHub. Not to mention, if GitHub decided to change its URL scheme for some reason, almost all Go builds on the planet would have to change. And of course, the whole problem stems from relying on DNS to name your packages. No one wants to bother with DNS, so they go for the low effort option and let some hosting provider handle it for them, without caring what happens in 10 years time.

kryptiskt 6y ago

Organizations live shorter than packages, just look at all the com.sun stuff in Java. And even in the absence of corporate changes, you may well want to transfer a package to a new home.

the_mitsuhiko 6y ago

> Devolving identity down to DNS has been a really good decision for Go If it works for go, the because go is not old enough. Domain registrations lapse quickly and then someone else can buy them. That's very close to the worst that can happen for trust in packages.

kelnos 6y ago
Ok, then how about Maven Central? They give you publishing rights to a particular group ID by verifying your ownership of the corresponding DNS names. They've been around long enough, I think, even if Go hasn't.
- tsimionescu 6y ago
  Maven Central uses that as a first-time verification (actually, it's OSSRH that requires this, technically there are other ways to publish to Maven Central). Golang's package system depends on the current DNS records. With maven, there are plenty of old projects that do not own the domain names for their group ID, and that doesn't cause any problems - they are well-known, established projects, and there's no reason to introduce breaking changes to everyone just because they want to go through some DNS naming changes. Because of this, there's little reason to fear that if you publish your project today as "io.github.my-project:my-module" you may find yourself having to break all your users if github blocks your account tomorrow (or just changes their URL schema) and you move to gitlab.
tedunangst 6y ago
For better or worse, nearly everyone uses github, which also provides second level name spacing.
earthboundkid 6y ago
If you lose your domain, spreading bad software is the least of your concerns. They can reset all email passwords and access every service you’ve ever used.
- reificator 6y ago
  > If you lose your domain, spreading bad software is the least of your concerns. But if you lose your domain spreading bad software is the top of my concerns.
  - earthboundkid 6y ago
    Either the package manager site allows email resets and the same issue applies, or it doesn’t and you can be locked out forever by forgetting a password. Both failure modes suck.
    - reificator 6y ago
      You're still assuming the domain owner's participation. How many domains lapse while the owner is active and responsive in the community?
      - earthboundkid 6y ago
        You just agreed with my original point that outsourcing identity to DNS/TLS is a good practice!
- dragonwriter 6y ago
  > If you lose your domain, spreading bad software is the least of your concerns. OTOH, it's probably higher on the list of downstream code users’ lost of concerns. > They can reset all email passwords and access every service you’ve ever used Not if you dealt with all that before letting the domain lapse. And if you don't, more to the point, that's your problem, but not the package manager user communities problem. And that it is a bigger concern of yours than the impacts on the package manager user community is exactly why that community might want to protect themselves from you neglecting their concerns..

tsimionescu 6y ago

Not really. Look at the protobuf 'renaming' and think about how silly that is.

solipsism 6y ago
Protobuf renaming?
- tsimionescu 6y ago
  I was referring to this: https://blog.golang.org/protobuf-apiv2 https://blog.golang.org/protobuf-apiv2 > The github.com/golang/protobuf module is APIv1. > The google.golang.org/protobuf module is APIv2. We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider. Basically, Google realized that it's not a good idea to tie your package's identity to GitHub's URL scheme. This is easy for Google to fix, but the majority of Go packages suffer from the same problem, and it is much harder for a small project to start maintaining a DNS record that they control to point that to GitHub. Not to mention, if GitHub decided to change its URL scheme for some reason, almost all Go builds on the planet would have to change. And of course, the whole problem stems from relying on DNS to name your packages. No one wants to bother with DNS, so they go for the low effort option and let some hosting provider handle it for them, without caring what happens in 10 years time.