Add "ownership" of a vendor namespace

[Seldaek]

Largely recognized (can't wait for the debates on what that is) organizations should be able to own their namespace, so that nobody can submit a package in it. This just to avoid confusion and potential injection of bad code.

[merk]

I dont agree that only large organisations should be able to own their namespace, it should be across the board. Why artificially limit this when the problem could occur for anyone who uses a namespace?

[Ocramius]

This should also affect users IMO... I'd surely not want to have ocramius/some-pr0n-package land on packagist on behalf on someone else submitting it :)

[eddieajau]

I think the ideal would be to allow Vendors to choose what they want to do. Of the top of my head, the broad options could be:

1. Anyone can use this Vendor without "my" approval
2. Anyone can use this Vendor with "my" approval
3. Nobody else can use this Vendor

Where "my" relates to an account that has been established as the "owner" of the vendor name. The pain point for Packagist is moderating requests for owning a vendor, but after that, and subject to someone coding a solution, all the work should be in the Vendor's court. There are probably other layers to consider, such as if I have approved a package, can I take it down if we are notified of security issues, abandonment, etc.

It's not clear to me yet how such things can or will be addressed. If larger organisations (in my case Joomla) are going to look at investing heavily in the Composer and Packagist paradigm, these are things we are going to be interested in knowing where we stand.

Vendor wide stats would also be useful, but that's another topic.

[kingcrunch]

I wouldn't make it too complicated: For a registered vendor-identifier only packages from a specific github account/organization should be allowed. Something like "allow others to publish packages in my name" could be targeted later, but I don't see a real benefit: Create an organization and invite the others into it and now they can publish in the organizations name. That is nothing packagist/composer must handle.

[Seldaek]

I'm not so keen on building features that are completely github-centric. I think the only way to build this simply is to allow accounts to claim vendor namespaces. Once approved, that account alone can create packages into it.

And @merk I agree with you that it shouldn't be only for the top 3 frameworks, but I also don't think allowing a gold rush of namespaces is a great idea, so if the vendor requests are made for names that are too generic, you better have a decent presence for that name and a few packages, otherwise it makes no sense to restrict the usage of that vendor IMO.

[ghost]

Just have some kind of username registration process at packagist.org - works for everyone else....

[fprochazka]

👍 This should be a standalone feature for packagist.

Once you create package, you're automatically owner of it's vendor and nobody else could add packages to it. There should be a way to add vendor maintainers (as is for package), for someone to register packages in it.

[burzum]

👍

This is giving us a bunch of headaches right now. People report issues because people who don't belong to our organization can add our packages and added wrong URLs (lower cased).

I guess they add lower cased URLs because Github allows us to use upper cased URLs in the past and present but Packagist does not. I personally dislike that as well because we don't want to have a copy of the repo and to sync both repos just because Packagist does not allow upper cased names.

For the namespace issue the only sane way to do is a manual check I think if you want to prevent a "gold rush". For github this is more or less easy I think. It should be obvious that all repos for CakePHP belong to that account and in that namespace.

Another idea might be that if somebody adds a package but is not the person who owns the repository that the owner could be allowed to take it under his name. I think that would be fair and requires no manual check from anyone.

[stof]

@burzum The case sensitivity comes from github: their web UI allows case insensitive usernames, but their git access to clone repos does not

[robla]

I wholeheartedly agree with Evan Priestley's views on this matter. Any progress on addressing this?

[fideloper]

Consider making this a for-pay option, either monthly (like GitHub Orgs and private repos) or as a one-shot fee.

This can help offset costs to you. Perhaps make it free for OS, but for business use (or even personal use for people' side projects), monthly or one-shot fees can be nominal! Could be a nice tie-in with Toran also with a "business level" account (or even something like NPM private repositories?).

Frankly, for what you did for PHP, you should be swimming in your bank vault.

[WyriHaximus]

Vendor namespaces should totes be a thing and having one account own it with an option to transfer it to another could prevent vendor namespaces from dying out or getting locked out from use.

How ever to prevent a goldrush I would suggest added a minimum number of repo's + downloads in it. That would prevent hijacked, reserved namespaces that might never see the light of day or getting sold behind closed doors.

Just throwing random thoughts out here (numbers are some what random as well):
As some one who does a lot of OS under a small hand full of vendor names I wouldn't mind throwing 10 or 20 dollars as a one shot fee at a new project's vendor namespace. Also to prevent hijacking the namespace the author who submitted the first package to a namespace should always have first right to claim a vendor namespace. And then the second and on and on.

[rdohms]

Im my opinion, if you add a paywall to this, you will kill most of its use within the "community at large". So the "free for OS" may be a good idea.

I agree with @WyriHaximus on the first come first claim model and it gave me a few ideas.

Scenario A:

1. publish a new package
2. vendor already in use or reserved? STAHP!
3. do you wish to reserve this vendor? -> free action, vendor is now yours under the "first package" rule.

Scenario B:
I want to reserve a vendor, but have not published anything yet.
This leads to you having to pay a fee to reserve a vendor.

This means big corporations may reserve their vendors and pay, since to them that money matters little. And developers pay by being active in developing new packages. Also this would reduce the gold rush, since you need to actually have a package.

The exploitation here being you can create blank packages.. but those may get some flack or moderation, for example.

[Crell]

I like @rdohms's approach. We've been discussing this in Drupal recently, and I would love for us to be able to distribute Drupal modules via Packagist; some level of control/curation of the drupal/ vendor space, though, would likely be required. (It may not happen, but were it to do so ownership of the namespace would be a prerequisite.)

[bartfeenstra]

Were the Drupal project to have ownership over the drupal vendor, for instance, it could also expose Drupal modules as Composer packages automatically. The same goes for other projects that have their own infrastructure for hosting and documenting packages.

[cebe]

There is a problem with existing packages where people have used a vendor to publish their packages, e.g. yiisoft would be the official vendor of yii2 and extensions, but there are a few packages registered under this vendor that do not officially belong to Yii. If this gets implemented there needs to be a way to cleanup and resolve such situations.

[Seldaek]

So.. while I fully agree with @fideloper's sentiment about the pool of gold coins and all that, I had an idea about how to implement this simply, which after almost 3years is better than discussing and not implementing a perfect solution ;)

As of now, nobody can add a package to a vendor they are not a maintainer of anymore. To grant access to someone either add them as maintainer to an existing package in the vendor, or add their new package yourself and then add them as maintainer there.

Simple rule and especially simple implementation as there is no claiming process or whatever, you register a package in a new vendor and you own it, done.

Now all that is left is for the big projects (and anyone who cares) to check their vendor namespaces and try to evict any squatters. I can help with that if needed but I'd rather if people handle this reasonably and peacefully as it keeps my inbox leaner.

[TomasVotruba]

👍

[webmozart]

What about adding a simple Name Squatting Policy such as the one at GitHub to Packagist?

[rdohms]

@Seldaek I volunteer for moderation if you need an extra hand.

Also 👍 on what @webmozart said.

[phillpafford]

I'd like to add an alternative, in addition to a reserved vendor namespace could there also be a verified vendor namespace? I've been playing with https://keybase.io./phillpafford not sure if this is something you wanted to add but this does bring clarity on who is maintaining the repository

[bileckme]

I concur. Moderation is highly necessary.

[rvanlaak]

👍 What about verifying Packagist namespaces by linking them to the Github's organization users page? For Symfony that would be: https://github.com/orgs/symfony/people

That way packagist users know who they can address with questions about access to a namespace. Or can't the namespace be linked to an organization on github that easy?

[mvdkleijn]

👍 for verified namespaces! keybase.io looks like a very nice concept by the way

[judgej]

So how does this work now? Is the functionality here to add maintainers to a vendor name that I already have? I'm either simply not seeing it, or it's still work-in-progress.

I'm reading that it was nothing to do with being a collaborator of an organisation of the same name on github (which makes sense) so it's first-come, first-served. I want to get a vendor name claimed for a largish project that has a number of packages (by different project collaborators) waiting in the wings to go into packagist, but they have not quite got into gear. If I claim the vendor name, I would then like to add other maintainers, and have them manage others when they up up to speed. Is that how it will work? Is that how it is working now, with me missing it somehow?

[cebe]

As far as I got it, to add maintainers to a vendor name you have to add them to at least one package that already exists in the vendor. So as soon as you have created the first package for them and added them as a maintainer, they are able to add more packages themselfs.

[judgej]

@cebe Ah, thanks, I see it now. When viewing one of my own packages, I can add a maintainer of that package - there is a link to do so. So a maintainer of any package in a given vendor name, gets to be able to add other packages under that same vendor name.

[jesseleite]

Simple rule and especially simple implementation as there is no claiming process or whatever, you register a package in a new vendor and you own it, done.

@Seldaek: Maybe this could be clearer on packagist website?

[fredemmott]

How does this work if a package that was incorrectly under a vendor is abandoned? eg https://packagist.org/packages/facebook/xhp was an unoffical package, replaced by the official facebook/xhp-lib - is the previous owner of facebook/xhp still a maintainer of the facebook/ vendor?

[alcohol]

Not sure. @Seldaek might be able to offer some insight into this. I don't think there is currently a quick way to check who has access to a certain vendor "namespace". Perhaps it would be nice to make this visible on the vendor page (/packages/<vendor>/). Possibly limit visibility to only logged in users that already have access to that vendor space. Just a random thought :-).

[Seldaek]

Yes that any maintainer of any package within the vendor has access. I can transfer the package to you if you feel safer but down the line I doubt people would abuse this. The name squatting was usually done with good intentions.. And I can always boot them if they abuse it. Up to you. As for showing members on the vendor page yeah that sounds like a good idea.

[rvanlaak]

What about getting the members from the Github organisation page?

[Seldaek]

Because packagist isn't exclusive to GitHub and GitHub org/owners don't necessarily have a direct link with package vendor names.

[Seldaek]

I mean not a great idea imo because of the above.

[fredemmott]

If maintainers are shown, we will definitely want to boot people out - we don't want to make it appear that unrelated community members are affiliated with/endorsed by us, even if they had good intentions.

[alcohol]

Like I said, we can limit visibility to only other maintainers of the same vendor namespace. It will at least give you insight into who has access.

[chez14]

I'm sorry but is this issue has been resolved?

If it does, is there any documentation about it?

Thank you!

[cebe]

@onlyongunz this is the description of how it is currently implemented: #163 (comment) No idea if there is other documentation about it.

[cebe]

A note could be added here: https://packagist.org/about#naming-your-package there is some space left in the naming column anyway ;)

[igorsantos07]

If you ever come here looking for how to allow a second person to add packages into your namespace, just add them as a maintainer to one of those packages.

I'm yet another one that got lost on the matter and spent a couple of time digging around. This should be clearly mentioned at https://packagist.org/about#naming-your-package, but there's only some coding doc from #786.

[cebe]

sent a PR with docs update: #962