GitLab | Workflow for contrib projects (#99)

[Amar Takhar (@amar)]

Amar Takhar commented on a discussion: https://gitlab.rtems.org/administration/gitlab/-/issues/99#note_124712


Only administrators can create toplevel groups on our instance so that is not a concern for us.  The CODEOWNER one is not a concern either because it's only used if you have developer+ access.  Even if someone grabs a name that's in a CODEOWNER file they won't have any relevant permissions to be able to do anything about it but it is annoying for sure.

GitLab internally uses IDs for everything the name is just display so takeover of a group is not possible as their user ID would be different.  CODEOWNER uses usernames which is why it's an annoyance but you'd still have to re-add that person with the relevant permissions to that namespace/repo in order for them to be able to do anything.

As far as the redirection, you're right that's how it works there is only one level of inference and the redirect stays alive as long as a repo isn't named.  But there could be no hijacking as on our instance the only permissions any user has is to create personal repositories and groups within their _own_ namespace.  Only people with admin access can create toplevel groups and owner level in that namespace to create further namespaces inside.

I'm fine if automation breaks if it's using the API having to deal with a redirect is a slowdown anyway.

Thank you for the highlights great to have this written down somewhere.

-- 
View it on GitLab: https://gitlab.rtems.org/administration/gitlab/-/issues/99#note_124712
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20250616/897b160c/attachment.htm>