Offering to co-maintain Redirect 403 to User Login

+1

This module needs to D11 version. I pinged @markdorison few weeks ago, but without any answer

Hi,

+1 for a new maintainer/co-maintainer.

I use r4032login on a lot of projects and would like to be able to update to D11.

Hi all, I have no problem with this request, but I do not have sufficient permissions to add you as a maintainer. Adding my +1 though.

deekayen, shrop, ms2011 and bdone can add new maintainers:

https://www.drupal.org/project/r4032login/maintainers.json

I have also mentioned two of the maintainers in Slack #contribute channel https://drupal.slack.com/archives/C1BMUQ9U6/p1734422515626019

2 weeks have passed and @markdorison, one of the co-maintainers, also agrees.

These offers need to be moved from the person who created them. If the person is no longer interested, moving the request in the Drupal.org project ownership queue is pointless.

Looks like I could do this - I am a maintainer, but don't technically have "administer maintainers" on there. however, I can do it via my security team role

As dieterholvoet confirmed that he wants to maintain the module, can this move forward? A lot of users are waiting for the module to be updated to support Drupal 11, but this blocks it.

Thank you in advance.

I added dieterholvoet as a maintainer with full acccess

Adding the Questionable approval tag for tracking.

@pwolanin is not listed on https://www.drupal.org/project/projectownership as a user allowed to approve applications.

@pwolanin by own admission used their security team role to override their authority as a co-maintainer.

No note in this issue of having reached out to the official maintainer or of official maintainer being inactive for over a year.

@dieterholvoet requested co-maintainer not maintainer.

@cmlara any updates? We need to r4032login Drupal 11 version. :) Can @dieterholvoet start to contribute?

Can @dieterholvoet start to contribute?

I have no control on this one way or the other, I am primarily just tagging the issue so that it can be referenced easier at some point in the future when discussions come up regarding the security and integrity of the existing process such as in #3452326: [META] Increase Security of Project Ownership Transfer Process or it’s children.

There have been a number of incidents in this queue in the past that may raise questions (such as this one) that are hard to locate without some sort of tracking flag being added.

@pwolanin addressing the concerns raised would go a far way into clearing up the situation if @dieterholvoet is concerned about the ethical questions this raises regarding their new access.

Setting this back to "Needs work" as it's obviously not "Fixed", but I'm unsure if another Status is more appropriate.

@deekayen, @shrop, @ms2011 and @bdone - please be aware of and provide any guidance/assistance in this matter.

@cmlara - as you flagged this as questionable, it would make sense for you to provide more guidance as well, including:

1. "reaching out to the official maintainer" - unless I'm missing something, it appears both @dieterholvoet and @a.dmitriiev attempted to reach out to the maintainers
2. are there guidelines for recommended/required:
   1. channels for this, e.g. Slack, user profile contact form, email, etc.
   2. number of outreach attempts (or number of channels attempted)
   3. elapsed time to allow for response
3. is there also a process whereby to audit maintainers and remove inactive members - 13 seems a bit excessive, especially with no engagement on this issue from a maintainer for two months
4. should @dieterholvoet be made a co-maintainer instead to proceed?
5. what should happen now? next step?

Flagging as questionable sounds appropriate if the proper process wasn't followed, but it's not actually helpful in rectifying the issue without some additional context/direction.

"reaching out to the official maintainer" - unless I'm missing something, it appears both @dieterholvoet and @a.dmitriiev attempted to reach out to the maintainers

The current process docs described in https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or-distribution-project/maintainership/offering-to-become-a-project-owner-maintainer-or-co-maintainer/how-to-become-project-owner-maintainer-or-co and How project moderators handle requests to be project owner, maintainer, or co-maintainer calls for a Project Ownership queue maintainer to reach out on their own to validate.

I will note I've been told these are not binding policy's and that they are more guidelines.

While not intending to accuse anyone here of perhaps not reaching out, there is no way in the current system to verify @dieterholvoet (the important one as the requestor) and @a.dmitriiev (not as important as they are not a queue admin) actually did reach out to the maintainers via the contact form (security engineering: assume everything it is a misleading statement until proven otherwise) telling them if they did not respond they would loose access to the module.

If you look at the message at #2 for example, it in no ways conveys that failure to respond could lead to a new maintainer being added without the existing full level maintainer consent. Compare this to a message such This one sent by @avpaderno which makes it more clear that failure to respond will result in permission changes.

This is important when we consider the project adoption process is essentially a supply chain attack, forcing a new maintainer onto a project without the consent of the maintainers that are authorized to add/remove users.

I mention over in #3452333: Automate the majority of the ownership transfer process (retain human approval) that some of this ambiguity could be removed by moving to a more code controlled processed where automated systems send out the email on the requestor behalf (this allows bypassing the contact form being disabled, and provides a 'trusted' record that messages have been sent).

are there guidelines for recommended/required:

The recommendation are that Project Ownership Queue Admins will attempt to reach out again to be sure the maintainer is aware of the request unless it is clearly obviously they inactive.

Based on the public data of GitLab appear to have the maintainer logged into D.O. in the past year, its close to the year mark, however still within a year which in my experience has been treated as "not presumed completely inactive" and given the chance to respond.

should @dieterholvoet be made a co-maintainer instead to proceed?

If this application were to be completed I would say yes. Lets assume for sake of argument @avpaderno did contact the module maintainers, they would have been told that the user requested a role that will give them only permission to commit to the project, not to add other users.

From a risk analysis standpoint while this is still risky, it is much less risky than a user being given full privileges where they could remove other maintainers (but not the owner) that could still act as a checks and balance. It is fair to believe that such an issue will receive a lower priority to response and is more likely to accidentally not be responded to.
(Again not intended to imply @dieterholvoet has any ill intention, this is solely from a security analysis standpoint).

what should happen now? next step?

For me the big question is, by what authority did @pwolanin grant the access?

Is the security team allowed to interact in this queue for modules that are not unsupported due to security issues? I see that nowhere in the documentation on D.O. They are allowed to transfer ownership for known insecure modules.

Is @pwolanin actually a Project Ownership Queue maintainer allowed to enforce the policy? If so why did they mention using their security role?

I can't speak for D.O. and the D.A., however to me these raise serious questions about possible permissions misuse. I've been told on Slack that D.O. permissions have been misused in the past with CWG reports made but no apparent action taken (hence the need to track these scenarios).

That is probably the main problem, including the fact there are site moderators who, with the excuse a contact form is not enabled, proceed to change the project owner, or add maintainers without even notifying the project owner. (edited)

It would be a CWG report. I have already posted one, but it does not seem it helped.

-- @avpaderno_
https://drupal.slack.com/archives/C2AAKNL13/p1718570858385279?thread_ts=...

If the permissions were not misused it could be helpful for D.O. to better document this, and @pwolanin could help by providing the normal comments that Project Ownership queue maintainers put in (eg: "I've contacted the maintainers, postponing for 14 days" ) (for some reason we do seem to see a number of people contacted by a Project Ownership Queue moderator respond when they do not respond to normal users) followed by with the transfer of ownership.
Side Note: I'm aware @pwolanin was pinged via Slack to consider taking action on this issue, unsure if they saw the message.

If the permissions were misused that would be a question for the D.A. on how they respond. I would suggest at a minimal the process should be restarted at the "Project Ownership Queue Moderator reaches out to Project Maintainers" stage of the process.

but it's not actually helpful in rectifying the issue without some additional context

Unfortunately I don't have any authority to enforce this one way or the other.

I had hoped @avpaderno would have commented which would have given this issue guidance.

I question if D.O. users with the enhanced powers feel they have any right to intervene as well. I do question if I should fire this up to @hestnet and/or the Drupal Security Team as a possible breach, however I want to give @pwolanin more time to respond before I go that far as perhaps there is some policy somewhere I am either not aware of or have forgotten that allows this.

I'm making an assumption however I read #21 to mean this transfer was made outside of the normal Project Ownership Queue approval process which further causes me question how this transfer occurred.

Thank you for the additional information @cmlara - it sounds like we wait to see if any of the maintainers chime in, while also possibly pursuing some changes to the maintainer review and authentication process?

I would also recommend instituting a mandatory periodic review of maintainers for modules (with current versions of supported Drupal - shield "covered by security team") reportedly used on over 10k (or some threshold) sites.

I would also recommend instituting a mandatory periodic review of maintainers for modules (with current versions of supported Drupal - shield "covered by security team") reportedly used on over 10k (or some threshold) sites.

Not exactly sure what you are suggesting so throwing out a couple of possibly related issues for you to look into to see if they meet your desire.

#1134450: Automatically degrade maintenance and development status of projects over time was also opened to try and indicate to the public that modules are not being maintained that might be related to your suggesiton.

Something similar was also suggested to ping maintainers to ensure they are still active (to try and avoid modules reaching a state where a security vulnerability was found yet no maintainers were responsive) in #3260712-12: Discuss involving ecosystem maintainers in security support degradation process.

I will note that I have another issue open (that is somewhat divisive) that argues we should never allow adoption of modules at all #3452328: Prohibit the ability to adopt a project instead we should encourage forking of modules. @dieterholvoet would of been able to do so back in November with zero delay, and a simple post in the D11 compatibility issue could have started user migrating to a new namespaced module (allowing the existing namespace module to die a natural death through attrition, which could also be helped by the above issue of auto degrading maintenance status).

Here is the proof that I have contacted the maintainers in Slack https://drupal.slack.com/archives/C1BMUQ9U6/p1734422515626019

There are also at least 3 messages in Slack #contribute channel from Ivnish:
https://drupal.slack.com/archives/C1BMUQ9U6/p1736425954066919
https://drupal.slack.com/archives/C1BMUQ9U6/p1732684301373429
https://drupal.slack.com/archives/C1BMUQ9U6/p1733723989226619

And from other people:

https://drupal.slack.com/archives/C1BMUQ9U6/p1735935169012749
https://drupal.slack.com/archives/C1BMUQ9U6/p1733935783496769

Unfortunately, there is no proof for contact form request, as I didn't set the copy to be sent to me.

I understand that there are rules, but having 13 maintainers and no one is responding and the module that has a lot of installations and people are waiting for Drupal 11 support. I think here could be some help from d.o admins to solve this problem.

At some point this module was considered to be added to Drupal CMS, but because of lack of Drupal 11 support, it was not added there too.

There are also at least 3 messages in Slack #contribute channel from Ivnish:

And from other people:

None of these 5 messages directly make note of the ownership transfer request being open.

Here is the proof that I have contacted the maintainers in Slack

This one is better, and I missed its linking earlier in message #9.

This message includes @shrop and @pwolanin and none of these other maintainers. @shrop has permission to manage maintainers and responded they were willing to discuss though it appears they never visited this issue or took actual actions.

As this was message #9 there is still no note to the maintainer that they MUST take action or D.O. staff/volunteers will intervene, at that point it still looks like a low priority “I would like to help, but it’s entirely your choice”.

Rather than re-pinging @shrop (who has permissions) the messages instead re-pinged @pwolanin. This is questionable as well since @shrop could have legitimately taken action on the module while @pwolanin is still unclear.

I will add that @dieterholvoet was not pinged until @pwolanin sent a message in the thread mentioning they had added the user. This looks like a missed opportunity early on for them to have talked to @shrop and maybe moved this forwards. Not a requirement by any rule, just pointing out communications disconnects here that helped end up in this situation we are now.

I will add a ping in there to @shrop that he can clear up the current ethical concerns regarding @dieterholvoet. That likely will not clear up the all the questions regarding the transfer before now that will still need to be addresses however it can at least set a clean date for actions by @dieterholvoet going forward.

I understand that there are rules, but having 13 maintainers and no one is responding and the module that has a lot of installations and people are waiting for Drupal 11 support.

12 prior to adding @dieterholvoet, Only 4 or which have the authority to add other maintainers.

Having a large number of installations makes following the rules even more important and taking clear actions even more important not less. As noted above this is D.O. injecting a new user with the ability to commit code without the consent of the namespace owner, while D.O.’s adoption process has made rbis seem like common place behavior it is still manipulation of the supply chain.

I think here could be some help from d.o admins to solve this problem

This is a fair criticism. I mentioned somehere recently that it might be worth having D.O. better lay out expectations for those with increased power, the word “volunteers” is often used to excuse away inaction on D.O. without regard for the fact that taking on enhanced roles can and should increase the expectations of responsibility for those with the role.

At some point this module was considered to be added to Drupal CMS, but because of lack of Drupal 11 support, it was not added there too

This should not factor into the overall situation, the process for Drupal CMS started early last year allowing plenty of time for this process to occur. There is also the Project Update Group that could have addressed this concern. Both od these could have been completed easily on the time allotted.

I am good with @dieterholvoet continuing co-maintainership of Redirect 403 to User Login. Certainly, there are things to be learned here. Take a look at the referenced doc below around related processes. Marking this fixed as the overall goal was completed, but also acknowledging we had some failures along the way.

Reference: How to become project owner, maintainer, or co-maintainer

I adjusted the permissions, removing. “Administer maintainers” since the original request was to become a co-maintainer to add Drupal 11 compatibility and have permissions to merge code, manage issues, and create releases, which @dieterholvoet can do. Thank you for your help to get this module to Drupal 11 and anything else you do to push the module forward!

Awesome! @dieterholvoet you can start now creating a new module! We are desperately waiting for this! :-) Thanks a lot for the efforts.