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.

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?