GitLab reminds me about access every two hours

changed title from GitLab to GitLab reminds me about access every two hours

changed the description

added IT-prioritylow IT-severitylow service:GitLab team:webdev labels

@malowe is our sync script responsible for that?

Very likely, yes. It matches the cadence of the Gitlab sync, and roughly matches the time I'd expect. I'll look into this today

"You have been granted access to the Eclipse Projects / webtools / Releng group with the following role: Maintainer. This is a default role."

Wondering if there is a race conditions issue?

@nitind is a project lead under this project: https://projects.eclipse.org/projects/webtools.releng/who

The email they are receiving says that they were granted maintainer role, however, Gitlab report they have the developer role:

https://gitlab.eclipse.org/groups/eclipse/webtools/releng/-/group_members

assigned to @malowe

added statetodo label

added statewip label and removed statetodo label

So the reason this is happening is that the hierarchy is kinda messy as a project group was nested inside of another project group. This isn't currently supported, but it isn't super clear in the handbook, where we just say we support TLP sub-grouping.

What is currently happening is the following. @nitind is a part of both the webtools and webtools.releng project. In terms of permissions, their permissions in the webtools project is committer level, while it is that of project lead under webtools.releng. What seems to be happening is the following:

Script starts running and syncs all projects. Nitin gets set properly within each of the projects, being added as a maintainer in the Releng group. Once all perms are sync'd, the script then does a cleanup. As part of the clean up, we remove users in sub-groups and projects to catch cases where projects try and circumvent election processes to grant users access to projects they shouldn't be on. In this case, we don't check that the sub-grouping isn't part of another project, so Nitin gets removed from the releng project as maintainer, and the cycle repeats.

I'm fairly sure we should support this, but I will note that this isn't a recommended use case, as people within the TLP will be granted access to all sub projects nested in the TLP sub-groups. This effectively circumvents the election process, even if this is a safer version of circumvention as the individuals are trusted to be in the TLP of the project.

@wbeaton what should we do in cases like this? Do we want to allow the permissions leak from the TLP into the sub-projects, or push for TLPs repositories to be set into their own folder within the TLP group? If we choose the first option, I can look into a fix that would make exceptions in the cleanup to support this case. Otherwise, we can look at confirming how we want to manage this and update the handbook

According to the EDP, there is no inheritance of privileges. Having committer status on a TLP does not grant committer privileges on subprojects.

I have a vague recollection of discussing this at some point, so I may not be remembering a decision regarding granting PMC members privileges on TLP resources. But... according to the EDP, committers have access to Git repositories. According to the EDP, PMC leads and members do not get commit privileges on anything. PMC leads and members should not be appearing in any GitLab groups.

AFAICT, the Eclipse Web Tools project has no committers, so nobody from that project should be in any group related to the project. Since there are no committers, having eclipse/webtools as a GitLab Project doesn't make any sense.

Nesting resources from different (even related) Eclipse projects in GitLab is... problematic.

Now... we'll argue that the TLP website is most certainly a TLP resource. Since resources need to be maintained by committers, we should grant some subset of the PMC committer status on the TLP, create a distinct group in GitLab (e.g., eclipse/webtools/tlp), assign that group to the Eclipse Web Tools project, and move the webtools-website repository into that group.

The other option -- and this may be the better choice -- is that we change the EDP to permit a notion of inheritance of committer privileges. A change of this nature would have other impacts.

AFAICT, the Eclipse Web Tools project has no committers, so nobody from that project should be in any group related to the project.

In this case, there seems to be 5 committers on the project: https://projects.eclipse.org/api/projects/webtools.

Regarding the outcome of updating the EDP vs aligning with current EDP standards and adding clarifications, just let me know which we are doing and we can move forward. Nitin will receive emails until we resolve this in one way or another unfortunately, so I'd recommend a pretty specific email filter if possible in the meantime as a stop gap!

Okay then... different problem. The website does not list the committers.

https://projects.eclipse.org/projects/webtools/who

I guess that I'll open a separate issue for that.

Regarding the outcome of updating the EDP vs aligning with current EDP standards and adding clarifications, just let me know which we are doing and we can move forward.

Regrettably, no. A change to the EDP will take literal months, so this can't be on me. We have to resolve this within the current constraints.

The fundamental problem is that the GitLab hierarchical model does not match the EDP's non-hierarchical model.

My suggestion is the only path out of this that is consistent with both.

~~Now... we'll argue that the TLP website is most certainly a TLP resource. Since resources need to be maintained by committers, we should grant some subset of the PMC committer status on the TLP,~~ create a distinct group in GitLab (e.g., eclipse/webtools/tlp), assign that group to the Eclipse Web Tools project, and move the webtools-website repository into that group.

I took a quick look at the code and the foundation database. First, we do have users with the committer role in the foundation database for the WebTools project.

However, when generating the "Who" webpage, I noticed an exception in our code that replaces our fetch for committers to instead fetch "PMC Member". This explains why we see PMC Leads and PMC Members on the page but not committers.

That said, I don’t believe this exception exists in our API. The API is simply returning users with the committer role for the specific project in the foundation database

@wbeaton should we resolve this by removing these relationships in the foundation database, or would you prefer we add an exception in the API to stop returning committers and possibly project leads for a top-level project?

//cc @epoirier

+ @mbarbero - This decision will likely impact how we manage defaults for the security team for TLP.

@wbeaton should we resolve this by removing these relationships in the foundation database, or would you prefer we add an exception in the API to stop returning committers and possibly project leads for a top-level project?

No. It's completely fine for a TLP to have committers and project leads.

Background information:

A TLP should not be developing actual deliverable software. The resources that a TLP maintains should be in support of the subprojects. This most commonly manifests as a repository to contain TLP website content, but there are some other examples (e.g., the EE4J TLP maintains a parent POM for its subprojects). A TLP having committers and project leads is entirely a practical matter: committer and project lead status is how we manage access to resources.

The solution to this problem is stop fighting GitLab. GitLab doesn't support the configuration that we're trying to implement.

In this case, if the goal is to grant committers on WebTools TLP write access to the website, we could create a new group (e.g., webtools, webtools-tpl, tpl) under eclipse/webtools and move the website project under it, as suggested by @malowe.

Once that's done, we just need to update the GitLab group in PMI to reflect its new location, which would resolve the cascading permission issue.

This will probably mean an update to the validation logic as we have that field locked down atm. tlp or {id}-tlp is probably a good name, and we can always throw a vanity name on it in settings if people want something a little different

@malowe You are correct Martin - We do have strict validation rules on that field. We would need to add a new valid exception(s) for TPLs to allow us to save this new group.

Will you need to make some updates to the sync script if we add these new valid format(s) (eclipse/{id}/tlp or eclipse/{id}/{id}-tlp)?

I would yeah. The formats allowed right now are the following:

${rootGroup}/${project.short_project_id}
${rootGroup}/${project.top_level_project}/${project.short_project_id}

So I'd need to add the following for when top_level_project == project_id:

${rootGroup}/${project.top_level_project}/${project.project_id}-tlp
${rootGroup}/${project.top_level_project}/tlp

Do we want to block ${rootGroup}/${project.short_project_id} when the project is a TLP? I think it would help enforce the rules and conventions, even if it's a tiny bit more complex

Do we want to block ${rootGroup}/${project.short_project_id} when the project is a TLP? I think it would help enforce the rules and conventions, even if it's a tiny bit more complex

I think that is a good idea, if we want to avoid this problem in the future, we need to add some validation rules to stop users/staff from entering this as the default GL group for a TLP.

@wbeaton, do you have any concerns with the proposed solution?

Add validation to stop us from setting the GL group for TLP as ${rootGroup}/${project.short_project_id}
add exceptions for TLP to be able to set their GL group as:
- ${rootGroup}/${project.top_level_project}/${project.project_id}-tlp
- ${rootGroup}/${project.top_level_project}/tlp

I'd like us to prioritize fixing this since people affected are receiving emails from us every 2 hours.

@malowe, would it be alot of work foryou audit our project API data to identify if other projects are in a similar state? I’d like to understand how widespread this issue might be.

The "vague recollection" that I referred to but couldn't find earlier is here. My read is that we decided that this is an invalid, but tolerable state.

With this in mind, I believe that the problem changes from "stop fighting GitLab" to make the ECA checker stop fighting itself.

would it be alot of work foryou audit our project API data to identify if other projects are in a similar state? I’d like to understand how widespread this issue might be.

@cguindon Like in a nested state? Probably not too crazy, a couple of hours at most to whip up a quick script to run over the data with some filters and checks.

With this in mind, I believe that the problem changes from "stop fighting GitLab" to make the ECA checker stop fighting itself.

@wbeaton For clarity, this is purely a sync problem and is unrelated to the ECA checks! I can make updates that at least stop the noise in the case of nested projects when it's a TLP. Do we want to move forward with an update to add a new recommended structure for TLP storage under a tlp group, or hold off on that part?

I can make updates that at least stop the noise in the case of nested projects when it's a TLP.

Perfect.

Do we want to move forward with an update to add a new recommended structure for TLP storage under a tlp group, or hold off on that part?

Hold off.

Longer answer: Imposing this sort of restriction is going to annoy folks (and they'd be right). We've already decided that the current situation is tolerable, so let's just run with it. And make sure that we do indeed document the decision.

changed due date to October 11, 2024

added priorityhigh label

added IT-priorityhigh label and removed IT-prioritylow label

added severitymajor label

added IT-severitymajor label and removed IT-severitylow label

added statereview label and removed statewip label

Code for this is done and reviewed. I've done as much local testing as I can without just running the sync locally, so I'll look to get this out tomorrow morning.

This change is now live. @nitind you should now be in the webtools.releng project as a maintainer and also should not have received an email in the past half hour (around 11am EST).

@wbeaton this is now live, and we now handle the case of multiple sets of permissions granted by projects. It'll use the highest known permissions when checking, so it should still do corrections without doing unnecessary cleanup like in this case pre-fix!

closed

removed statereview label

GitLab reminds me about access every two hours

Summary

What is the current bug behavior?

What is the expected correct behavior?

Relevant logs and/or screenshots

Priority

Severity

Impact

Designs

Child items ...

Activity