4 ms·

I like the go way: import a url. If you want to alias the namespace however you want afterward then that's your problem. It doesn't solve every single security

I like the go way: import a url. If you want to alias the namespace however you want afterward then that's your problem. It doesn't solve every single security issues, obviously. But at the very least the source of the code is more transparent. Second option: signed packages. A warning when a package is not digitally signed. Finally, a package repository curated by whatever language foundation. But then we are getting close to OS wide native package management... But at the very least namespace+package name should be the norm for every single package manager out there. instead of just a package name. So it should be "pip install code.launchpad.net/beautifulsoup", not just "pip install beautifulsoup4", if it's not possible already. And then import "code.launchpad.net/beautifulsoup" as beautifulsoup in the code.

X6S1x6Okd1st 6y ago
> Second option: signed packages. A warning when a package is not digitally signed. It's trivial to sign a malicious package with a signature. The problem is to check and make sure it's signed with the signature
- Spivak 6y ago
  And it doesn't help typosquatting since baeutifulsoup will have a perfectly valid signature.
TheDong 6y ago
Sure, the go way: import ( "fmt" "github.com/dimuska139/go-email-normalizer" ) func main() { fmt.Println(emailnormalizer.NewNormalizer().Normalize("x+1@gmail.com")) } Wait, how did I know to do "emailnormalizer.NewNormalizer()"? Well, that's the package name of the package at that url. The package name is only the same as the last part of the URL in go by convention, and importing a package can put an arbitrary package identifier into your package scope.
- LukeShu 6y ago
  FWIW, `goimports` would say "OK, technically that's valid, but I'm going to complain unless you explicitly import it as 'emailnormalizer'". import ( "fmt" emailnormalizer "github.com/dimuska139/go-email-normalizer" )
  - earthboundkid 6y ago
    See https://github.com/golang/go/issues/29036 https://github.com/golang/go/issues/29036 which is still open.
- watt 6y ago
  and what happened to the "go-" prefix? is it silently dropped?
  - sheenobu 6y ago
    No. The go files just have "package emailnormalizer" within the go files, so that is the name that you use to reference it, even if the import url is different.
runarberg 6y ago
Will URL imports actually solve the problem. Couldn’t a malicious actor simply register a similar name: e.g. `pip install code.lauchpad.net/beautifulsoup`? I would also guess many packages would be hosted on github: `pip install popular-org.github.io/package` which could be typo-squatted by creating a similar sounding github user `pip install poplar-org.github.io/package`.
- TylerE 6y ago
  Or for that matter what happens if the original author loses control of the domain?
  - earthboundkid 6y ago
    If you lose the domain, the old packages can’t be changed because they have a hash. New, evil packages are a problem, but that can also happen now if someone steals your password or does an email reset of your account.
user5994461 6y ago
Plot twist: the go way works in python. You can pip install from a github URL, preferably with a branch rather than master.
btashton 6y ago
Right URLs never change. Remember when one of the most popular golang logging libraries renamed from github.com/Sirupsen/logrus to github.com/sirupsen/logrus and all of a sudden everything would break because you were using both via some dep vendor. Or Java where you get 80 char of namespaces that may or may not change because the library moved to be an eclipse project.
- earthboundkid 6y ago
  FWIW, Go’s module system (which was invented afterwards) explicitly encodes uppercase vs lowercase in a platform independent way internally to prevent that from happening again.
Terr_ 6y ago
> import a url Or at least have a strong convention that all project namespaces be url-like. That's what Java did decades ago, and it remains one of the ecosystems which care the most about traceability. Sure, the actual url may drift from the namespace, but at least you've got a much more google-able starting point than "lxml" or whatever.
junon 6y ago
Absolutely not. URL-based imports are a security risk, availability nightmare, and fragile system built with the assumption that things are never renamed, taken down or significantly changed, or that the developer always has an internet connection. Depends cannot be resolved offline, and time becomes a factor for the correctness of code (i.e. you fetch a dependency, code against it, dependency changes public API, coworker fetches your code, fetches the dependency, build is now inexplicably broken). Not to mention DNS hijacking, BGP, caching, locality, etc. can all affect how dependencies are fetched. Further, not using a registry makes in-house mirrors a nightmare due to having to re-route DNS requests all the time. It's an all around _terrible_ feature in my opinion and I am very careful to distance myself from any project claiming otherwise.

X6S1x6Okd1st 6y ago

> Second option: signed packages. A warning when a package is not digitally signed. It's trivial to sign a malicious package with a signature. The problem is to check and make sure it's signed with the signature

Spivak 6y ago
And it doesn't help typosquatting since baeutifulsoup will have a perfectly valid signature.

TheDong 6y ago

Sure, the go way: import ( "fmt" "github.com/dimuska139/go-email-normalizer" ) func main() { fmt.Println(emailnormalizer.NewNormalizer().Normalize("x+1@gmail.com")) } Wait, how did I know to do "emailnormalizer.NewNormalizer()"? Well, that's the package name of the package at that url. The package name is only the same as the last part of the URL in go by convention, and importing a package can put an arbitrary package identifier into your package scope.

LukeShu 6y ago
FWIW, `goimports` would say "OK, technically that's valid, but I'm going to complain unless you explicitly import it as 'emailnormalizer'". import ( "fmt" emailnormalizer "github.com/dimuska139/go-email-normalizer" )
- earthboundkid 6y ago
  See https://github.com/golang/go/issues/29036 https://github.com/golang/go/issues/29036 which is still open.
watt 6y ago
and what happened to the "go-" prefix? is it silently dropped?
- sheenobu 6y ago
  No. The go files just have "package emailnormalizer" within the go files, so that is the name that you use to reference it, even if the import url is different.

runarberg 6y ago

Will URL imports actually solve the problem. Couldn’t a malicious actor simply register a similar name: e.g. `pip install code.lauchpad.net/beautifulsoup`? I would also guess many packages would be hosted on github: `pip install popular-org.github.io/package` which could be typo-squatted by creating a similar sounding github user `pip install poplar-org.github.io/package`.

TylerE 6y ago
Or for that matter what happens if the original author loses control of the domain?
- earthboundkid 6y ago
  If you lose the domain, the old packages can’t be changed because they have a hash. New, evil packages are a problem, but that can also happen now if someone steals your password or does an email reset of your account.

user5994461 6y ago

Plot twist: the go way works in python. You can pip install from a github URL, preferably with a branch rather than master.

btashton 6y ago

Right URLs never change. Remember when one of the most popular golang logging libraries renamed from github.com/Sirupsen/logrus to github.com/sirupsen/logrus and all of a sudden everything would break because you were using both via some dep vendor. Or Java where you get 80 char of namespaces that may or may not change because the library moved to be an eclipse project.

earthboundkid 6y ago
FWIW, Go’s module system (which was invented afterwards) explicitly encodes uppercase vs lowercase in a platform independent way internally to prevent that from happening again.

Terr_ 6y ago

> import a url Or at least have a strong convention that all project namespaces be url-like. That's what Java did decades ago, and it remains one of the ecosystems which care the most about traceability. Sure, the actual url may drift from the namespace, but at least you've got a much more google-able starting point than "lxml" or whatever.

junon 6y ago

Absolutely not. URL-based imports are a security risk, availability nightmare, and fragile system built with the assumption that things are never renamed, taken down or significantly changed, or that the developer always has an internet connection. Depends cannot be resolved offline, and time becomes a factor for the correctness of code (i.e. you fetch a dependency, code against it, dependency changes public API, coworker fetches your code, fetches the dependency, build is now inexplicably broken). Not to mention DNS hijacking, BGP, caching, locality, etc. can all affect how dependencies are fetched. Further, not using a registry makes in-house mirrors a nightmare due to having to re-route DNS requests all the time. It's an all around _terrible_ feature in my opinion and I am very careful to distance myself from any project claiming otherwise.