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.

The recent events going on in the Wordpress community involving the ACF/SCF module brings quotes that are relevant to this discussion. I will admit there are some differences in the current WP situation where the maintainers were active (prior to being blocked making them inactive) we have had the same situation in our past when the CWG has banned users #3094854: Plan for dealing with projects that may be abandoned → and to my knowledge is the currently prescribed process to happen again.

I will note before the recent situation have said Wordpress.org had a better (written) policy that did not allow as much room for takeovers. The recent situation calls into question their commitment to the policy. We do have the following quote from ACF implying unlike D.O. where this is common, is rare in the WP community.

A plugin under active development has never been unilaterally and forcibly taken away from its creator without consent in the 21 year history of WordPress.

https://x.com/wp_acf/status/1845169499064107049

Automattic’s actions also echo a supply chain attack in some ways. In a plugin directory, it’s considered a supply chain attack if an actor silently takes over a plugin and ships functional changes without disclosure, which is exactly what happened in this case.

https://blog.pragmaticengineer.com/did-automattic-commit-open-source-theft/

This incident is a nightmare scenario for companies serious about supply chain security. Automattic has shown it’s ready to take over plugins as it pleases. It has also shown that it rolls out quiet changes with little to no testing. This would make it irresponsible for enterprises and government organizations to rely on the WordPress.org plugin directory.

https://blog.pragmaticengineer.com/did-automattic-commit-open-source-theft/

Enterprise customers will not trust *any* managed WordPress provider that was part of this supply chain attack silently replacing a major plugin (ACF)

https://x.com/GergelyOrosz/status/1845883272192049156

We do have the following quote from ACF implying unlike D.O. where this is common, is rare in the WP community.

I do not think that this is common on d.o. Can you provide an example? We are talking about "A plugin under active development", which all projects going thru ( https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → ) are not, because you need at least 14+14 days without an answer from all maintainers (contacted via issue queue and via contact form / email).

At the moment, when there is an unfixed security issue reported to s.d.o, and the maintainers aren't responsive, then the security team can intervene to mark the project unsupported, and issues an SA at the same time (without disclosing specifics, obviously the reporter could decide to do so at that point, often they don't). This process alerts site owners (via update status) that there is an unfixed issue in the project.

It is possible to resurrect a project marked unsupported in this way by fixing the security issue, and then asking the security team to re-instate it and add a maintainer - this can be done by either the previous maintainers, or a new one if someone volunteers to take it over and also fixes the issue.

See the process documented on https://www.drupal.org/drupal-security-team/security-team-procedures/mar... →

As I read this issue, it would prevent any of this from happening, so what would happen in that case?

As I read this issue, it would prevent any of this from happening, so what would happen in that case?

Yes this policy would prevent that existing practice from occurring.

We would be compelled to follow the more general method of maintainers fork the project into a new repository and work from there. D.O. or the D.S.T. could still place an announcement flagging the module as insecure and in that message they could recommend an alternative.

I do note in the cons that yes this will create more namespace pollution in exchange for increased supply chain integrity. This could be minimized for example by search not displaying modules that are known security vulnerable.

Forking is a method that works for the vast majority of the internet, there is no reason to belive it can not or would not work here. This could already occur today if a maintainer decides to do so. At least for users who do not have the security opt in permissions has occurred to create a new project when a maintainer is inactive on a security covered module.

Also as noted yes this would require a site owner to change their deployment to use the new project over the old in order to obtain the security fix. Best practice is that you should uninstall the existing project the moment the unsupported SA is announced. We know from experience this does not always occur. This would need some community time for site owners to learn that they need to stay on top of the modules and can no longer assume that if left installed they will eventually “magically” become supported again.

There also has been recommendations in other issues on how to avoid modules becoming unsupported in the first place (such as contacting maintainers regularly to ensure they are still interested in working with the security team which could act as a point for them to willfully transfer ownership to another community member that is active on the project before they leave the community).

and in that message they could recommend an alternative.

In which message?

I was primarily referring to the warning text added per https://www.drupal.org/drupal-security-team/security-team-procedures/mar... → as it will be present on the top of the modules info page and it is already generally touched (removed) as the last step in https://www.drupal.org/drupal-security-team/becoming-primary-maintainer-... → the security team would not be excessively burdened by adding a link to an alternative instead of deleting a notification block.

This proposed policy would not limit where the D.S.T. could publish that a module is unsupported for security reasons or limit where they could publish helpful information. The security team could choose to amend the Security Advisory, publish an auxiliary newsletter either through the PSA system or a dedicated system regarding alternatives for unsupported modules, or utilize any other announcement system that may as of yet not already been created.

This policy would just prevent transferring a namespace to another user without the approve or the current namespace “owner”.

as it will be present on the top of the modules info

So no indication via update status that there is a secure/release project that can be updated to from an unsupported one, which feels like a severe regression from the current situation.

This policy would just prevent transferring a namespace to another user without the approve or the current namespace “owner”.

Current namespace 'owners' are always given at least a month to respond to any project ownership requests, this is quite a long time - especially considering the actual length of time when they're unresponsive is usually a lot longer than a month in practice.

Why is it preferable to be able to strip the namespace from the current owner, something you apparently agree with, than for e.g. a member of the security team, a core committer, or a well known contrib maintainer of other high usage modules to be able to fix security releases for what could be tens of thousands of sites using a project?

So no indication via update status that there is a secure/release project that can be updated to from an unsupported one, which feels like a severe regression from the current situation.

Nothing technically stopping us from adding that as field on the module that Update Status can pull from to display the alternative. Equally Composer could also show this as part of its security audit report by including the alternative module in the description of the report. This would go under the comment above of 'other announcement streams that have not yet been created"

Current namespace 'owners' are always given at least a month to respond to any project ownership requests, this is quite a long time - especially considering the actual length of time when they're unresponsive is usually a lot longer than a month in practice.

It can actually be as low as 14 days if they have not logged in in over a year the Project Ownership Queue will not necessarily reach out to them. Addtionaly I have seen the Project Ownership Queue maintainers reach out before the first 14 day window expires and consider the second 14 day window clock already started. Both provide means that the request could be as little as 14 days.

I imply over in 📌 Automate the majority of the ownership transfer process (retain human approval) Active that the not reaching out 100% of the time also means it is possible they may never have been emailed expending them to look at every issue in the issue queue daily to know such contact has occurred (there have also been raised questions in the pastt of possibility of using slight naming differences to trick the project ownership queue maintainers though that issue may have been solved last year).

Why is it preferable to be able to strip the namespace from the current owner, something you apparently agree with, than for e.g. a member of the security team, a core committer, or a well known contrib maintainer of other high usage modules to be able to fix security releases for what could be tens of thousands of sites using a project?

I assume you mean "not be able" (clarifying here as that is how I'm answering the question).

For me this centers around the built trust that maintainer has gained from me over the years. It is impossible to review 100% of commits from 100% of projects I use on a day to day basis from Drupal to my web server to my web cache to my server operating system. There are likely numerous studies on this fact that open source does not necessarily mean 'more secure' since not all commits are indeed audited.

What this means is at the end of the day I"m trusting an owner to make decisions and audit their modules and those whom they give permissions to, a decision I would not trust to the Project Ownership Queue.

The XZ backdoor last year gave us an example where this can fail, its not a perfect system to trust just the code owner, however at least in that case the code owner made the decisions, they personally signed off that "I will allow this user to commit and publish releases in my name" while the D.O. adoption process allows a small group of people (who take no long term responsibility to audit the actions of the users they approve) to give someone whom an owner may not agree with access to attack silently attack as you put it "tens of thousands" of sites (and their tens of thousands of end users).

I can say with confidence that the only safeguard preventing me from pulling off the example attack given in the Issue Summary is the fact that I am not an attacker and that I have no desire to successfully pull of such an attack.

Getting enough social reputation is only a question of time and effort. For many the time and effort would not be worth perusing, for the dedicated attacker looking at the long attack, it could be easy and cheap.

At least with a forked project it is very apparent to me as a site owner I'm working with a new maintainer that needs to earn my trust.