3 ms·

Or just refer to packages by 2 names. Maintainer/PackageName It solves so many problems, this included.

by Klathmon 10y ago

blowski 10y ago
I guess that would work, as long as you require PackageName to be unique across all Maintainers.
- deleted 10y ago
  [deleted]
- kibwen 10y ago
  Though this would obviate the most compelling argument for namespacing, which is to allow exactly that.
jessaustin 10y ago
One imagines that "Maintainer" could be typoed as e.g. "Maintaner" just as easily as "PackageName" could be "PackagName".
- Klathmon 10y ago
  But then the attacker would need to register a ton of packages that match other popular packages under their namespace which can set off some alarms. (I guess "solve" was a bit too strong of a word to use there...) There could also be some other cool tricks you could apply (This is the first time you are installing a package from "Maintaner", would you like to continue?)
  - jessaustin 10y ago
    An attacker would only need to register the equivalent of the package under attack. Other packages would continue to error out harmlessly as they did before. The maintainer-level confirmation could be of slight assistance to advanced users, but it's no panacea.
kbenson 10y ago
This is all half of a much larger problem, which is package identification. Perl 6 specced out[1] quite a bit of a future system to handle a lot of this, and I believe a lot of it is now implemented. A few things you need to consider: - Maintainership can change over time. - Multiple people may trade off releasing a package, but it's still the same package. - There may be multiple repos (consider you may want to run a local company repo for non-redistributable modules). I imagine in the end, one of the better approaches to the installation name typo problem might be to scan the code for what packages are required (utilizing as much specific information as possible), and confirming that exists as a local package that can be installed or offering to install it. Package installers should be able to take a source file or files, and install modules listed within. This won't solve all cases (dynamically determined and loaded modules may be a problem still), but it will solve quite a bit of them. 1: http://design.perl6.org/S11.html#Versioning http://design.perl6.org/S11.html#Versioning
- Klathmon 10y ago
  Those are some good points, and I guess in my head I'm thinking of how Github does repos on their site as my "example". Github allows transferring of repos to another "namespace" (username), and will even forward requests from the old one to the new one for a while (how long i'm not sure...) Thinking about it a bit more that kind of "mutability" might not be the best idea in a package manager... Still, i think the namespaces can help more than they hurt if the platform is designed with them in mind, as even "namespace-less" systems still suffer from some of those issues like wanting to rename a package or split it up into multiple smaller packages.
  - kbenson 10y ago
    I'm not arguing for no namespaces, much the opposite. I'm arguing that the whole way most languages implement modules is fairly haphazard, and that that leads to this problem. If you review the link I included previously, you can see some examples of how you could definitively specify a particular module version. E.g. use OldDog:name<Dog>:auth<cpan:JRANDOM>:ver<1.2.1>; This would use Dog from the CPAN repository, author JRANDOM, and version 1.2.1, and namespace it as OldDog. You could also just "use Dog;" to use the canonical Dog package from the canonical sources (in order). If we could just point our package manager at this source code and it could determine "Hmm, you have a Dog module of that version, but not that author and repo, and you have a Dog module from that repo and author but not that version. Looks like we need to install it." that would leave us in a much better place, both for code using definitive versions of packages, and admins/programmers installing packages and making sure they get the right one, if it's been defined.
ubernostrum 10y ago
That gets into issues with needing to either support multiple individual maintainers for a single package, or require any multi-maintainer package to create an organization they'll all work under, and use the org name. And since the org name is likely to be the name of the package, you're back at square 1. For example, on the Python Package Index five people have authorization to publish a new Django release. Creating a "Django" org namespace wouldn't help, since someone could typo the org name and hit a squatted malicious version (and that's almost certainly what it would end up being; our github org is named "django").
fredrb 10y ago
jashkenas/coffeescript could go easily be mislead by: jashkneas/coffescript

Or just refer to packages by 2 names. Maintainer/PackageName It solves so many problems, this included.

blowski 10y ago

I guess that would work, as long as you require PackageName to be unique across all Maintainers.

deleted 10y ago
[deleted]
kibwen 10y ago
Though this would obviate the most compelling argument for namespacing, which is to allow exactly that.

jessaustin 10y ago

One imagines that "Maintainer" could be typoed as e.g. "Maintaner" just as easily as "PackageName" could be "PackagName".

Klathmon 10y ago
But then the attacker would need to register a ton of packages that match other popular packages under their namespace which can set off some alarms. (I guess "solve" was a bit too strong of a word to use there...) There could also be some other cool tricks you could apply (This is the first time you are installing a package from "Maintaner", would you like to continue?)
- jessaustin 10y ago
  An attacker would only need to register the equivalent of the package under attack. Other packages would continue to error out harmlessly as they did before. The maintainer-level confirmation could be of slight assistance to advanced users, but it's no panacea.

kbenson 10y ago

This is all half of a much larger problem, which is package identification. Perl 6 specced out[1] quite a bit of a future system to handle a lot of this, and I believe a lot of it is now implemented. A few things you need to consider: - Maintainership can change over time. - Multiple people may trade off releasing a package, but it's still the same package. - There may be multiple repos (consider you may want to run a local company repo for non-redistributable modules). I imagine in the end, one of the better approaches to the installation name typo problem might be to scan the code for what packages are required (utilizing as much specific information as possible), and confirming that exists as a local package that can be installed or offering to install it. Package installers should be able to take a source file or files, and install modules listed within. This won't solve all cases (dynamically determined and loaded modules may be a problem still), but it will solve quite a bit of them. 1: http://design.perl6.org/S11.html#Versioning http://design.perl6.org/S11.html#Versioning

Klathmon 10y ago
Those are some good points, and I guess in my head I'm thinking of how Github does repos on their site as my "example". Github allows transferring of repos to another "namespace" (username), and will even forward requests from the old one to the new one for a while (how long i'm not sure...) Thinking about it a bit more that kind of "mutability" might not be the best idea in a package manager... Still, i think the namespaces can help more than they hurt if the platform is designed with them in mind, as even "namespace-less" systems still suffer from some of those issues like wanting to rename a package or split it up into multiple smaller packages.
- kbenson 10y ago
  I'm not arguing for no namespaces, much the opposite. I'm arguing that the whole way most languages implement modules is fairly haphazard, and that that leads to this problem. If you review the link I included previously, you can see some examples of how you could definitively specify a particular module version. E.g. use OldDog:name<Dog>:auth<cpan:JRANDOM>:ver<1.2.1>; This would use Dog from the CPAN repository, author JRANDOM, and version 1.2.1, and namespace it as OldDog. You could also just "use Dog;" to use the canonical Dog package from the canonical sources (in order). If we could just point our package manager at this source code and it could determine "Hmm, you have a Dog module of that version, but not that author and repo, and you have a Dog module from that repo and author but not that version. Looks like we need to install it." that would leave us in a much better place, both for code using definitive versions of packages, and admins/programmers installing packages and making sure they get the right one, if it's been defined.

ubernostrum 10y ago

That gets into issues with needing to either support multiple individual maintainers for a single package, or require any multi-maintainer package to create an organization they'll all work under, and use the org name. And since the org name is likely to be the name of the package, you're back at square 1. For example, on the Python Package Index five people have authorization to publish a new Django release. Creating a "Django" org namespace wouldn't help, since someone could typo the org name and hit a squatted malicious version (and that's almost certainly what it would end up being; our github org is named "django").

fredrb 10y ago

jashkenas/coffeescript could go easily be mislead by: jashkneas/coffescript