Resolve SA-CONTRIB-2024-003 in 2.x branch

2 week patch window reached, this is now open for work.

While the 8.x-1.x branch focused on filtering plugins where they were called, in 2.x the current plan is to modify getLoginDefinitions() and getValidationDefinitions() to have an $active_only parameter similar to getLoginDefinitions, see #3319595: Login plugins are always applied even when not enabled → .

The project page says "Warning: Releases 2.0.0-alpha2 and before have known vulnerabilities and should not be installed, use only latest development builds." but it seems like this vulnerability is still present in 2.x, right?

If fixing this will take a while then I guess the project page should be updated and maybe link here.

If fixing this will take a while then I guess the project page should be updated and maybe link here.

Indeed. Although the roadmap issue may be better 🌱 Roadmap for 2.0.0 release Active as the needs continue to evolve (looks like I need to update that issue, will give it a review this week).

I am not sure why a generally inactive maintainer felt compelled to push out 2 new Alpha releases on the 2.x branch when the branch is not suitable for use anywhere except a development lab (which should be deployed as 2.x-dev not a tagged release)

For actively developed projects, periodic releases make sense to me. They encourage testing and help with the QA process, as they allow for a named version to be tested.

I agree it's ideal to coordinate releases in the queue at least a few days prior to doing them so that any maintainer watching the queue can help discuss.

Thanks for the ideas on what the message should say. I've updated the project page to be more accurate about the current situation and include a link to that roadmap. Feel free to edit further, of course.

I would suggest the 2.x branch is removed from the project page then, as it might be expected that users see a D11 version and they read only that.

I am not sure why a generally inactive maintainer felt compelled to push out 2 new Alpha releases on the 2.x branch when the branch is not suitable for use anywhere except a development lab (which should be deployed as 2.x-dev not a tagged release)

As the generally inactive maintainer in question it is mostly because of the following reasons:

• The 2.x branch was tagged as alpha way back when I was an active maintainer. Back then, the objective was to tag version 8.x-1.0 and then never release anything anymore in that branch. Then life got in the way...
• When I tagged alpha3 (and alpha4 for a quick fix after) there were 1500 sites using the alpha2 tagged version that would otherwise be blocked from upgrading to Drupal 11. Not tagging those releases is actually a maintenance problem.
• There were many commits added to the 2.x branch that were not available in a tagged release and should be.

I do thank you @cmlara for taking such good care of TFA. You have the time to devote to it that I no longer have. If you do decide that the 2.x changes will never happen, then please create a 3.x branch that is a copy of the current code in 1.x, check if a migration path from 2.x to 3.x is necessary, and then unpublish 2.x. Otherwise, please do not neglect that branch, just because it has known security issues that haven't been fixed yet.

The 2.x branch was tagged as alpha way back when I was an active maintainer. Back then, the objective was to tag version 8.x-1.0 and then never release anything anymore in that branch. Then life got in the way...

My recollection is that part of this was that you were unsure how to add D10 support to 8.x-1.x and believed it was not possible due to core API changes. Sites (for better or worse) adopted this early alpha into production eager to deploy D10 with unfinished code knowing there were risk to doing so. Once the solution was added to support D10 in 8.x-1.x the critical need to release a 2.x (and for sites to run 2.x) went down allowing us to spend the time on 2.x to 'get it right' and find the 'best' code fixes rather than the 'simple quick' fixes we have been putting in 8.x-1.x.

When I tagged alpha3 (and alpha4 for a quick fix after) there were 1500 sites using the alpha2 tagged version that would otherwise be blocked from upgrading to Drupal 11. Not tagging those releases is actually a maintenance problem.

Personally, I wanted to get those users off 2.x, that was why the warnings in the releases, in the project pages, the desire to have the DST flag alpha 2 as insecure. At the time of Alpha3 being tagged there was (to my knowledge) nothing preventing a rollback to 8.x-1.x, see 💬 Can we switch site from 2.0.0-apha2 to 8.x-1.7? Active . Going off my notes in that issue the Alpha3/Alpha4 may now complicate that scenario (although that is the responsibility of a site owner for using the alpha).

For actively developed projects, periodic releases make sense to me. They encourage testing and help with the QA process, as they allow for a named version to be tested.

There were many commits added to the 2.x branch that were not available in a tagged release and should be.

I disagree with this, tagged releases are for when you want more general public usage, 2.x has however been in a "DO NOT USE" state. The only users who should have it deployed are those who are developing TFA 2.x, those types of users should be running off GIT HEAD as that is where the merge targets will be, how code interacted 2 commits prior is not relevant, it is how it interacts with the branch HEAD.

Yes we eventually want more active usage, however that is once all the security issues are closed out, any major architectural decisions are made, and general use is believed to be working.

I would suggest the 2.x branch is removed from the project page then, as it might be expected that users see a D11 version and they read only that.

I had considered that option in the past and have been on the fence about it. Its generally custom on D.O. to include the dev branches out as 'supported' indicating they are being worked on, and that they should be the target of new changes for backport to an older release. I would be a bit concerned about the signal it sends regarding the fact that 2.x is indeed intended to be the eventual solution, especially since I consider 8.x-1.x non-viable long term.

If you do decide that the 2.x changes will never happen,

Currently no plans for 2.x not to happen. It is just been in a state where it has needed larger arhictecutlar changes, some of them quite massive to get rid of what I see as significant design fault/limitations of 8.x-1.x. That said I see 8.x-1.x as non-viable long term, given changes found in other issues and the triggering of yet another Security Advisory for 8.x-.1.x that 2.x was not vulnerable to. There could be a decent argument for releasing 2.x with the known vulnerabilities, rapidly marking 8.x-1.x as unsupported, and very soon after spin off a 3.x as we still have more API breaking changes on the roadmap. I had avoided that

The only users who should have it deployed are those who are developing TFA 2.x

I think that horse has bolted. We're using 2.x in production, I can't remember the reasons why we used it at the time as this was a long time ago but it does sound like we need to downgrade now given the state of that branch.

I will test downgrading and report back to 💬 Can we switch site from 2.0.0-apha2 to 8.x-1.7? Active