TATA Consultancy Services is bulk posting requests to gain maintainer access to modules

Spotted another user in one of the threads.

A sample:

Hello Team,

Currently, we have good team for managing this module.

Also, we are working on Image Widget Crop of Drupal 10 to Image Widget Crop of Drupal 11 project. In future, we will plan to upgrade in Drupal 12.

Can you please grant me access of co-maintainer so we will do good work in this module.

Hello Team,
We currently have a strong team managing this module. Additionally, we are working on upgrading verf from Drupal 10 to Drupal 11, and we plan to upgrade to Drupal 12 in the future.
Could you please grant me co-maintainer access so we can continue to do good work on this module?

Hello Team,
We currently have a strong team managing this module. Additionally, we are working on upgrading image_url_formatter from Drupal 10 to Drupal 11, and we plan to upgrade to Drupal 12 in the future.
Could you please grant me co-maintainer access so we can continue to do good work on this module?

This is pure copypasta and I think it should be treated as spam.

Adding a few more issues. Think I have spotted 6 different modules so far where a user was added as maintainer without any second thought.

Think I have spotted 6 different modules so far where a user was added as maintainer without any second thought.

I think that warrants escalation. Those users should be removed as maintainers post haste and the original maintainers should be warned to properly vet applicants before handing them the keys. This is how supply-chain attacks happen.

Just. Going. To. Leave. This. Here. 🫥

https://www.drupal.org/project/issues/search?text=offering%20to%20mainta... →

Almost all 'credited' contributions on the associated accounts seem to be simply saying yes the core 11 change works on automated patch issues.

Those users should be removed as maintainers post haste and the original maintainers should be warned to properly vet applicants before handing them the keys

What right do we have to override a maintainers decision?

Do I think TATA’s devs are qualified developers: No.
Do I think maintainers are negligent in assigning them any level of maintainer status:: Yes
Do I believe the entire adoption process system is a massive supply chain attack: Yes
Do I believe we as a community have a right to overrule a maintainer: No.

Certainly consider sending them a formal warning about vetting maintainers before blindly accepting them. Even possibly consider blocking any account that has gained maintainer level status (so that it can’t access any projects), while a cooldown is in place, however at the end of the day a maintainer made a choice. So as I asked to start with, as bad as we may think it is what right do we have to overrule them?

This is the balancing act between maintainer rights and dealing with problems we as an ecosystem created.

This is pure copypasta and I think it should be treated as spam.

Ill note it shows we finally got vendors to adopt standardized training processes with formal material. How is this copy pasta differnt than any of our other docs that say “copy this template and use it as part of the request”? Let’s be careful on shutting down vendor training.

By all means call it spam due to its bulk nature, or its use by unqualified individuals, but let’s be careful on causing the vendors to move away from centralized training repositories by complaining about the use of a template.

Do I believe we as a community have a right to overrule a maintainer: No.

That's 100% correct. And it's no difference from let's say maintaining an NPM package on GitHub. BUT I think we should at least try to find a way to make sure a maintainer is trustworthy before being added as a maintainer to a project. (see referenced META issue in the securitydrupalorg project).

Ill note it shows we finally got vendors to adopt standardized training processes with formal material.

No, it doesn't show that at all. The only reason to apply for co-maintainership of a project is because you use or need it, often with a history of working on issues. That is not the case here, not even the pretence.

I have sent a formal educational message and warning to the users referenced above and several others who appear to be senior members of the TATA Drupal team.

More maintainership is good, so hopefully they can respond by engaging more senior contributors, and/or starting by having the new folks establish a track record.

Is there a way to monitor their commits to quickly see if they do anything malicious? That could permit an immediate suspension. And have they applied for any abandoned modules?

I’m hoping that Drupal’s Security Team members have taken an interest in this issue...

@edwin.van.buuringen Yes. This issue was created by @bramdriesen, a provisional Drupal security team member. Together with a related issue to discuss potential policy changes: 📌 [META|POLICY] Think of a way to make it less easy to become a (co-) maintainer Active

Is there a way to monitor their commits to quickly see if they do anything malicious?

The Gitlab UI and API provide some data:
https://git.drupalcode.org/jayapriya-18 For example shows push history.

The rest API can also likely be utilized https://docs.gitlab.com/ee/api/events.html#get-user-contribution-events for a more automated method to monitor and filter.

Hi Bram, All,

The users mentioned above are mentored by me as we are encouraging them to contribute to community.
They are neither bot nor spam Having said that, if they missed any community guidelines, I apologize for the same and will ensure its fixed immediately .
Though these are new members on Drupal.org but have been doing Drupal development for very long and hence i encouraged them to contribute more.
On a positive note, by taking maintainership of modules which are not activity maintained, we are trying to play an active role in making such modules more responsive to demand for changes.
If their experience on Drupal.org is only the question , then i can have their mentor take on this. Idea is to have maintainers who can contribute time and be more responsive.

On a positive note, by taking maintainership of modules which are not activity maintained, we are trying to play an active role in making such modules more responsive to demand for changes.

Sorry to say this, but bulk posting requests to become maintainer is not the way to go in my opinion. This was being posted on active maintained modules as well, none of them which I checked were abandoned. There are better ways to contribute instead of asking to become maintainer of a module without even having contributed to a single issue on set module.

They are neither bot nor spam

Bulk posting the same request over and over does fall under spam.

If their experience on Drupal.org is only the question , then i can have their mentor take on this.

Their experience is not shown on an empty user profile either. I'm not questioning it, but those profiles listed in the IS do not show anything.

FWIW, you do not need to be a maintainer in order to contribute. So I would highly recommend you stop pushing your mentees in that direction.

The users mentioned above are mentored by me as we are encouraging them to contribute to community.

Being a co-maintainer of a module isn't contribution in itself, it's a permission level on a project. Contribution is working on issues, and then if you're a maintainer, also creating releases. So applying for elevated permissions without having first done the contribution bit, is not a good way to go about things, in fact it's actively harmful as evidenced by this issue.

I remembered this from a previous issue on Tablefield (which I felt had a great response):

https://www.drupal.org/project/tablefield/issues/3488566 💬 Offering to co-maintainer TableField Active

Looking at their profile, they were granted maintainership of blocktabs @

https://www.drupal.org/project/blocktabs/issues/3488855 💬 Offering to co-maintain blocktabs Active

Not from TATA, but a similar one credit on an automated security issue and then applying for co-maintainership.

I'll reopen that ticket on blocktabs and link back here. :)

That user is actually working for TATA as well, just not linked to the ORG properly.

IT analysist
tata consultancy services ltd.

Ah yeah, good catch.

Also interesting the account has existed for over 9 years but apparently hasn't been active for long.

Adding https://www.drupal.org/u/kuhikar → .
They came into Slack #d11readiness questioning how to deal with a maintainer refusing to add them as a co-maintainer even though the messages offered them alternatives.

Slack Thread:
https://drupal.slack.com/archives/C03L6441E1W/p1739345746560339
Issue Thread:
https://www.drupal.org/project/login_tracker/issues/3502566 💬 Offering to co-maintain Active
(note this issue was opened on January 27th, the warning in this thread was sent on January 16th)
Module is security opt in enrolled, user does not have the security opt in permission.

There are a number of request to be added that were recently closed that track back to 2023. I didn't see on quick glance any others from 2024/2025 however this goes to history of their account and Tata.

An interesting one in the quick history is somewhat relevant to a module I co-maintain https://www.drupal.org/project/ga_login/issues/3405783 💬 Offering to co-maintain ga_login Closed: won't fix , the user tried in 2023 to adopt a module that had been rolled into the parent TFA module making it no longer needed.

As much as I support the responsible safeguarding ... reading through this thread I could not help myself but asking "What if someone had just been really successful in motivating new contributors?"

if they missed any community guidelines, I apologize for the same

Side task: Finding ways to give the Contribution Guidelines → more visibility where they might be needed?

"What if someone had just been really successful in motivating new contributors?"

Maybe, but then it would still be totally wrong. Creating a bunch of co-maintainer requests without having even participated in a single issue for set module feels wrong on many different aspects. You don't need maintainer access to contribute to modules. Still not sure where that perception came from.

Note they also posted theses requests on modules which actually are actively being monitored and worked on by the maintainers. Making it even more bizar 😊.

Side task: Finding ways to give the Contribution Guidelines more visibility where they might be needed?

I've mentioned in the past that https://www.drupal.org/drupalorg/docs/marketplace/abuse-of-the-contribut... → really needs to be shown as part of the D.O. Terms of Service, and that users need to 'sign' that they agree to it and that a mass mailer should have been sent out when the Terms of Service were changed (the abuse policy is a ToS addendum). 'We didn't know' should never be a valid excuse for violating the ToS. If users are not forced to agree to the terms the site is making a mistake. The contribution guidelines are incorporated by reference in the Credit Abuse policy. I had also suggested these terms should be incorporated by reference directly into the Drupal Certified Partner agreement, unsure if that was ever undertaken.

I agree with you, more could be done to present the policy to users.

Re #26 and this possibly being 'new contributors':
Tata has already been warned for this however I stumbled upon a module that somewhat shows just how absurd Tata's requests are.

💬 Offering to co-maintain subsite Fixed
@kuhikar requested on Dec 2nd 2023 to become a Co-Maintainer. Advises they have a good team for managing the module
Dec 4th 2023, it appears they were added as a full maintainer (or at least a co-maintiner and updated to a full maintainer at a later time)

💬 Offering to co-maintain subsite Active
27 Dec 2024 at 05:15 PST @dileepkumargembali (A new account, checking right now it displays as "2 month 3 week" old) requested to be added as co-mainainer, on behalf of Tata using the standard comment that Tata had a good team for working on the module
This issue was closed by site moderators on 7 Feb 2025 at 04:33 PST due to inaction (likely related to this issue)

💬 Offering to co-maintain fieldblock Active
27 Dec 2024 at 05:38 PST (33 minutes after the request by @dileepkumargembali) @manishvaity requested to be added as a co-maintainer. They got the module name wrong. Possibly meant to apply for a different module. In either case they clearly were not paying attention to their actions to close the request, move the request, or rename the module in the request.
10 Jan 2025 at 05:49 PST Granted access by @kuhikar.

These 3 issues show a decent overview of just what is going on inside Tata.

• The added maintainers are not keeping up with future development despite their promises to do so.
• Tata employes are opening issue at such a rapid rate they are not even reviewing the submissions (mistakes happen, wrong queue, etc, however not noticing them for a thread that is a precursor to injecting yourself into the supply chain it is significant).
• Tata employees are potentially not aware of their own management of the modules.
• Tata appears to have no solid internal team communications to manage the modules despite their public assurances of placing a strong team behind it resulting in public requests to be added as maintainers to modules the organization already manages.

Oh wow, didn't know they were posting the requests multiple times on the same module..

The docs → currently say:

Project moderators will not add as owner, maintainer, or co-maintainer a person who cannot opt projects into security coverage

Only a project owner (/ existing maintainer) can add a user without the opt-in to security coverage attribute as a co-maintainer.

The docs also suggest that users interested in being added as a co-maintainer...

File an issue in the project's queue. Use Support request as the category and state your interest in becoming maintainer or co-maintainer. Adding links to issues for the relevant project in which you have added merge requests or patches or where you have reviewed merge requests or patches from other users will help demonstrate that you are actively involved in the project. Describe the motivation behind your request.

We could change the wording here a little to move from "should" to "must"; rather than "providing some examples of your contributions might help the application" we could mandate that such examples are provided, possibly specifying a threshold (e.g. minimum 5 examples).

We could also provide some counter-examples of "contributions" which might not be considered as valid e.g. +1's, screenshots of patches applying etc..

All of that's fairly soft in terms of being enforceable but it would at least mean that the cases of inadequately supported applications to be added as co-maintainers we've looked at here would be in clear contravention of the stated rules, which would justify action being taken to undo the applications.

It would also help to reinforce the arguments - put forward in previous comments in this issue - that contributions can and should be made without maintainership status of a project, in order to establish some credibility and track record before a user is considered as a suitable candidate to be added as a co-maintainer.

As for whether anyone has the "right" to undo an action such as granting a user co-maintainership of a project on d.o, I'd defer to the Drupal Association and their legal advisors, but the general gist of e.g. https://www.drupal.org/docs/develop/git/setting-up-git-for-drupal/drupal... → and the other Terms of Service published for d.o., suggests to me that it's quite likely that the DA would be permitted to take whatever action (on d.o and associated systems) is deemed necessary to maintain the security of the overall Drupal project and ecosystem.

I think it would be more disruptive to the users in question here to have their accounts suspended than it would for the co-maintainership to be revoked. It's a bit of a pyrrhic victory if the users remain as maintainers but cannot access their accounts.

Personally I'd support the removal of the role in these specific cases, on the basis that the spirit of the rules was not adequately followed, and that the documentation will be improved to clarify those rules to avoid a recurrence.

Here's a slightly different view based on a specific situation. I'm a maintainer of https://www.drupal.org/project/file_upload_options → and accepted a Tata employee as co-maintainer. I looked into this person and the company they work for and noticed all the requests to be a co-maintainer, many of which were rejected.

The module has very low usage and I haven't been maintaining it as much as I'd hoped to. As expected, so far only D11 compatibility has been addressed but I'm hoping he will show more interest in improving the module. Either way, I'm monitoring commits and issues and if it doesn't work out I'll remove him as co-maintainer.

This is something I've done in the past when people have offered to help, even ones with experience, then done absolutely nothing apart from getting their name on the maintainers list.