Prohibit the ability to adopt a project

Pulling relevant quotes from https://drupal.slack.com/archives/C2AAKNL13/p1715712783335239

Wouldn't forking a module with a new maintainer be a better experience than silently passing hands to a new maintainer, at least in terms of security? With a module takeover all the community members using it are completely unaware any new release was actually made by a new maintainer. The built up trust over a long period of time in the previous maintainer shouldn't immediately transfer to the new one.

-- Joe GL (emphasis mine)

Just to do a concrete statement about the starting comment of this thread: Moving ownership is a potential security risk. So we need more checks about everything related to it.

-- c_logemann

Taking over a module is to easy also in my opinion. Another situation is if the module "owner" is not available or doesn't care about because taking over can just be done with bypassing of co-maintainers. I had exactly this situation where I was a co-maintainer for a D7 Module. A new project owner stepped in to claim just the namespace for a complete different approach for a D8 module and just closed all D7 Issue and removed me as a Co Maintainer. Luckily my customer project which was the reason to step in ended long time before incl. shutting down. So I had no impact to my own work. But I was shocked how it easy to just push me aside and I lost a little bit of trust to d.o "meta project management".

-- c_logemann

-1 from me on this proposal.

IMHO, the following claim is false:

If there is no ability to "adopt" modules the majority of the supply chain attack risk disappears and the ecosystem is protected.

In a free software environment, a threat agent can do perpetrate a supply chain by introducing a new package into the ecosystem that contains some exploit. To tie this risk to to the ability to "adopt" abandoned modules is IMHO obfuscating the fact that a free software ecosystem that allows anyone to contribute is inherently vulnerable to supply chain attacks.

The principal argument for prohibiting the "adoption" of an abandoned module seems to be this one:

Wouldn't forking a module with a new maintainer be a better experience than silently passing hands to a new maintainer, at least in terms of security? […] The built up trust over a long period of time in the previous maintainer shouldn't immediately transfer to the new one.

The adoption process is not "silent" as stated. The process is transparent. A public issue must be created in the project's issue queue and stay there for at least two weeks. Anyone concerned about supply chain attacks should monitor the issue queue and recalibrate their trust in the project's team if they don't trust the new maintainer.

c_logeman writes:

I had exactly this situation where I was a co-maintainer for a D7 Module. A new project owner stepped in to claim just the namespace for a complete different approach for a D8 module and just closed all D7 Issue and removed me as a Co Maintainer.

As a project ownership maintainer, I am not familiar with the this specific incident. For the record: This is not how namespace transfers is supposed to work. As long as Drupal 7 is supported, a new owner who wants the namespace for a Drupal 10 project is not allowed to interfere with a still supported Drupal 7 branch of the project. If you had taken this incident up the site moderators in the Project Ownership issue queue, this would have been reversed. And of course, if you had monitored the project's issue queue, you could have objected to the namespace transfer request even before it took place.

IM(NS)HO, this proposal is addressing the problem from the wrong angle. Yes, there is a risk of a supply chain attack taking place is a Free Software ecosystem. I don't know about any actual exploits, so we may discuss how severe this problem is.

Letting a project stay abandoned because the team that once maintained it has moved on is harmful to the Drupal ecosystem, and projects becoming abandoned is a very real problem that we now mitigate by letting new people adopt them (following a well documented process). I am open to improving this process, but I honestly think that to prohibit the ability to adopt a project will be harmful, without really doing much to mitigate the risk of supply chain attacks in the Drupal ecosystem.

I've updated the IS to try and make it more clear since this issue is in context of the adoption procedure and not globally trying to fix every supply chain attack possible through D.O. (as noted in the META issue). If anyone has a better overreaching solution to fix all the supplychain vectors instead of targeting small known risks please open an issue and add it to the META.

As an argument for this:

GitHub: Does not allow this
GitLab.com: Does not allow this
NPM: Generally does not allow takeovers for lack of activity, does have a process for dealing with Squatting which is different from code ever having a published valid release. Does explicitly call out that due to the risk of supply chain attacks some otherwise valid disputes may not be approved.
Packagist: I can't find a policy however I don not believe they allow this since an owner controls an entire namespace not just a package.

Personal note:
This solution had the least support on Slack, though by all security standards it is IMHO the most reasonable solution, it requires the least actions from site owners and closes this specific supply chain attack vector the most.

I understand that what you want "fix" the risk of supply chain attacks exploiting the project "adaption" process.

However, given that AFAIK, there has been exactly zero such attacks in the decade-long history of Drupal having allowed abandoned projects to be put under new management, what you're trying to "fix" is seems to be a hypothetical risk. And because the proposed "fix" shall be very disruptive to the Drupal ecosystem, breaking Drupal websites because projects that become unsupported will remain unsupported.

This is free and open source software. Some people here read code. A supply chain attack (if there ever is one) has a high likelyhood of beeing discovered by someone reading the code. The single such such incident I am aware of ( #3112841: Elfsight ecosystem modules collect site configuration data and site admin email without opt-in → — not related to the "adoption" process that is on-topic here) was discovered and the malware releases unpublished before the code saw any adoption.

My proposal is that we safeguard "adopted" modules against supply chain attacks by reviewing changes to the code (as documented in the commit history log) for some time after a new maintainer has been added and look for potential exploits. I sometimes do this as part of my work as a project ownership maintainer (in particular if the new maintainer has not much of an trust record in the community). However, it may be a good idea to organize a team of code reviewers to do this in a more systematic fashion.

I sort of mentioned at the parent, but I’ll say it again here: if this were for discussing actual supply chain attacks we knew to have occurred, we’d need to be doing it privately on the security.drupal.org issue queue. The only reason we’re talking about any of this publicly is precisely because it’s all “hypothetical” and we’re trying to mitigate vectors proactively before they’re exploited, not scramble to deal with the fallout of a real attack.

That said, I’m -1 to this proposal, too. 😅 I’d rather make it more clear when owners have changed if a (set of) maintainer(s) has/have gone missing and someone else has taken over than to encourage forking. In my biased opinion, one of the great strengths of Drupal is that we have always enabled and encouraged collaboration over forking as the fundamental model of contribution.

I, too, don’t at all agree with this:

If there is no ability to "adopt" modules the majority of the supply chain attack risk disappears and the ecosystem is protected.

I don’t believe project adoption is a (hypothetical) vector for the “majority” of supply chain attacks. Doesn’t mean we should not change anything about the process and the tools related to it, but completely preventing adoption would do much more harm to the ecosystem than it would potentially “protect”.

If there is no ability to "adopt" modules the majority of the supply chain attack risk disappears and the ecosystem is protected.

This was intended to be read in the narrow context of targeting code ownership changes on D.O. and not the much wider acope of all supply chain attack vectors.

A supply chain attack (if there ever is one) has a high likelyhood of beeing discovered by someone reading the code.

Code review is one of the better methods, though this is not simple. This conversation started as a tangent discussion from the XZ exploit, a situation that with all the developers using and reviewing the code came down to the Linux community being saved by luck. PHP code is harder to obfuscate compared to the compiled build of XZ, but not impossible.

XZ also again shows how much of what we do is “trusting others” none of us have time to review every single line of code in every single program/module we use. We for better or worse depend upon others. XZ reminded us angain that Open Source does not mean backdoor free.

My alternative proposal is that we try to safeguard "adopted" modules against supply chain attacks by reviewing changes to the code (as documented in the commit history log) for some time after a new maintainer has been added and look for potential exploits.

That would be an interesting alternative if we continue to allow adoption (which I’ll admit is very probable given the opinion I’ve seen most of the well known D.O. users express) though I fear this may significantly increase the project ownership queue admins burden and change it from an administrative skill position to a programmer position. Not as good as preventing an individual from taking over a project but certainly far better than the current system of virtually no oversight at all after a change.

Adding on to my comment in #4:

WordPress does appear to allow adoption, though with what appears to be more stringent requirements than we do. https://developer.wordpress.org/plugins/wordpress-org/take-over-an-exist...

I could not find a process for taking over abandoned extensions for Joomla.

IMO, allowing a person who is not a maintainer to become project owner does not make sense. At least, I would limit the requests to people who are already maintainers for that project (people with all the permissions on the project). The exceptions are for when there are other reasons to make a person project owner for a project another person created. (I think those exceptions are already documented.)
If somebody wants to contribute to a project, being a co-maintainer should be sufficient, as start, since that allows to make commits, to edit the project page, to maintain issues, and to administer releases.