Proposing a Drupal 7 Security team on Gitlab

I would be on-board with ensuring that the Drush 8 pm-* commands work with the new location, once it is available. This should already be possible to do this just with configuration, but we could make it work out of the box with a new Drush 8 release.

Excellent initiative!

So I'm assuming the Drupal association is not endorsing this initiative. So we're basically embarking on a fork of d.o and all the repositories for D7 ?

A new update module that will look at github.com/gitlab.com or wherever.

I expect to have a new high performance server ready that could be used to host an instance of gitlab CE that I would be willing to provide for this initiative. It would be good to have a secondary server, if another organisation would offer a cloning service it would ensure that these repos would be available in one of two locations. So, basically we could set up a primary, secondary instance of gitlab CE for this.

Standing up our own instances would allow us to bypass the fees associated with github.com/gitlab.com.

@klausi, I think it'd make a lot of sense to clone all of the repos, I have a script that does this.
Easier to manage to grab all of them. We cannot rely on d.o, they want EOL and they are forcing it through.

It'll have been 14 years when it finally hits final EOL, with little funding available to support it - you can hardly blame them. But that's a topic for another issue. The DO team isn't going to be deleting the branches, you can rely upon that; everything that is being disabled has been announced in advance.

@DamienMcKenna, people have offered funding but the DO team has not solicited funding because they want to encourage people to jump to D10/D11.
It's not about funding, it's a choice.

Can we call it Drupal XP?

https://www.drupal.org/project/drupal_xp

The XP could stand for Xtra Protection.

Thanks @jeni_dc
I suggest Drupal Classic. Like Cocacola Classic and New Coke.

I don't think this issue belongs on Drupal.org; it belongs on GitHub.

FWIW, I have no concerns with this so long as:

• Nothing about it is on d.o so that current site maintainers/infra/etc. aren't responsible for it.
• The current maintainers, Security Team, and DA are not responsible for it and never get asked about it.
• All communications are clear to the effect that this is an unofficial effort and that all discussions must be in the GH project and not on d.o.
• Edit: Security issues should be reported to the Sec Team first as per the IS, but issues for D7 only are not accepted. I think we need a fix here in the proposal to ensure the Sec Team is not spammed with D7-only bugs though; not sure exactly what that should be.

-1 on random branding.

I would be interested in participating/helping out with this initiative, as long as we continue to have Drupal 7 clients. We're down to 11 at the moment, but may pick up some new ones.

#10 proves that all repos need to be cloned, a new platform mounted. Not much time left to figure this out.

btw, github.com isn't free, a reasonable amount of automated testing pipeline will cost $
Since we've already got a new gitlab pipeline in place on d.o, it would be easier to set this up on a new server with gitlab CE in a similar fashion instead of github and set up a pool of gitlab-runners to register for core and contrib testing.

I suggest we stand up a new domain and a drupal "project" instance to avoid bothering the d.o folks as mentioned in #10

I have a new server being built (with a warm spare) that will come online soon, has 128 gigs ram, 32 threads, 8T raid 1 wd gold, 2T high performance M2.1 on a RAID 1.

The reasonable option is to do something similar to what d.o did , and that was to stand up an instance of gitlab CE on a domain. This time a domain intended for Drupal unlimited life.

Setting up and running gitlab ce on a domain is something I already have experience with. It works quite well.

+1 For using Gitlab. After all, Github is owned by Microsoft.

@klausi,

github.com will cause a lot of extra issues with the testing infrastructure

gitlab.com supports registering gitlab-runners which are actually easy to set up and allow us to have unlimited testing pipelines that can run virtually anywhere

We could start with gitlab.com , with that said, I'll soon have a full hosted instance of gitlab ready and running on a high performance server/high capacity server that will have an offsite warm spare available and getting scheduled refreshes via rsync. Exporting from gitlab to gitlab works quite well, it is a way to ensure that our efforts continue and are not wasted.

investing in github.com is too risky and not worth the effort. The folks running d.o realized this, that is why they are using gitlab and not using github.

gitlab has a powerful api also that allows us to do a lot.

I have concerns about how the messaging in #10 leads to the 'two stage' policy of #15.

As a maintainer I may not be publishing new 7.x (or lets go even further back, 6.x) releases, however that doesn't mean I don't want to be informed about concerns about possibly vulnerabilities to evaluate if they still exist in my current supported releases.

I would think we would want to continue this ability for existing maintainers to support users and that the Drupal DST wouldn't just close an issue reported against a D7 release after EOL without the maintainer at least confirming they do not feel its an issue in currently supported releases.

Admittedly the subject of "The responsibilities of Forks to report security issues to their parent project" is not to my knowledge a very well discussed subject in security circles however i would hope there would be a level of respect given to those who have done the work before to notify them as well before public disclosure on a D7 fork.

I leave it to those of you with D7 sites still to decide if this is worth the effort, however I will say I respect anyone willing to take on extending security to more versions. Its a battle I fight inside of D.O and know it can be a weary position to be in.

I will note that I have seen at least one other commercial vendor (Gold tier) is marketing "Never ending support for Drupal 7" which means at this point some level of support being present for D7 past EOL is likely no matter what any of our personal feelings are on the subject. At least this project would be public (GPLv2 you may redistribute the code, not must redistribute) and perhaps would allow multiple vendors to collaborate their effort similar to the D6LTS process.

@klausi I was being a bit bombastic; what I really meant was "every effort is made to ensure that people do not incorrectly contact the DA/Security Team/uninvolved core or contrib maintainers or post issues in Drupal.org queues". I.e., it should be a part of the project's README and processes to help people use the correct channels and not use Drupal.org/contributor resources. There should be no expectation that core committers or the Sec Team do anything but wontfix D7 issues, nor any intentional use of DA resources, and every effort should be made to minimize the filing of such issues on d.o.

@cmlara, it's not about "feelings"; it's about effectively delineating unofficial support from official support. Also, full disclosure, HeroDevs is actually a client of mine (thence their certification tier). My above comments are to help find a balance that will meet the needs of those interested in this effort without causing friction with the people who need to not be chained to D7 support.

Edit: D7Security seems fine as a project namespace. By "random", I meant branding patterned after old proprietary software or beverages. :)

I prefer Github because more developers already have accounts there, lowering the bar of contributing.

I am not sure that this is true or that this is pertinent. Gitlab is easy to use and the bar is very low already.

On all Drupal project I worked with, 99 % are hosted on Gitlab and 1% on Github.

There should be no expectation that core committers or the Sec Team do anything but wontfix D7 issues, and every effort should be made to minimize the filing of such issues on d.o.

My biggest fear is Drupal.org itself. We all know it is still running on Drupal 7 and that the security team may deliberately choose not to fix any security issues in Drupal 7 core or any Drupal 7 contrib modules used by drupal.org. Or they may prefer to privatize the drupal.org codebase and not release any security fixes to core or contribs.

There is a Drupal Symfony version of Drupal.org in development, but will that version be ready before D7 EOL?

@xmacinfo, I think that's out of scope here, but rest assured the DA is working hard on getting d.o upgraded -- it's one of the things that makes the Drupal GitLab integration such a high priority -- and that d.o won't be left insecure regardless of what else happens. Infra, the core committers, and the Sec Team all work together when needed, and the lead developer for d.o is also on the Security Team.

I'd like to ask that folks limit further discussion on this issue to figuring out where this effort will be hosted, and once that decision is made, the discussion can move there (and out of the core ideas queue, since the core committers generally will not be responsible for this effort).

github.com isn't free, a reasonable amount of automated testing pipeline will cost $

According to GitHub's pricing page, CI/CD minutes are "free for public repositories". GitLab's free tier includes "50,000 compute minutes" for public repositories.

Whether we think "free" vs "free for 50,000 min" will make a difference for this effort I don't know, but I would advocate for choices that will be the most maintainable, both in time and cost, over time. It may be easy to identify funding or volunteer time in the short term, but will that always be available? For example, I would be against self-hosting GitLab for this reason.

@markdorison,
Yes for public repositories it's free as in beer but not free as in freedom.

There's reasons why we would run private repositories, such as to run automated tests against security patches prior to releasing a security advisory update.

gitlab is by far a better option for several reasons:

1. gitlab is an open source platform
2. gitlab has an export/import capability making it fairly easy to migrate from one server to another, issues, pipelines, comments, assets, configurations
3. gitlab has a powerful api that allows us to extend functionality and interact with it and integrate it
4. gitlab is already in use by d.o and therefore we can simplify the work involved by using a similar approach
5. github.com is owned by microsoft and since the takeover there has been an exodus from github.com over to gitlab
6. anyone can easily run an instance of gitlab ce
7. gitlab offers an easy way to plug in gitlab-runners , to add testing pipeline capacity even on private repos. It is extremely easy to set up a gitlab-runner on any machine in any network for expanded testing capacity without limitations.
8. gitlab is well documented
9. gitlab is constantly improving with every new release
10. gitlab has a very easy to use powerful and well documented optional stage pipeline system
11. gitlab is a mature/proven product
12. I'm sure there's many other great reasons to use gitlab.

The most important reason for using gitlab is d.o has already adopted gitlab for many of these reasons. Since we'll essentially be doing something very similar we should therefore also run gitlab. There's numerous reasons for choosing gitlab.

@markdorison you can install Gitlab Community Edition anywhere. When using your own server the "50,000 compute minutes" does not apply.

Of course, a server like the one proposed by @joseph.olstad is not free. But it is usually relatively cheap. Although backup instances should also be planned.

Some public projects are being hosted on Gitlab.com SAAS. While some others public/private projects are using their own Gitlab instances installed on their very own servers (VPS, metal boxes or cloud [including AWS]).

We need to define a governance first, and then define funding and all the technicalities, including any Gitlab instances, ownership, ticketing system and backups.

With Gitlab we can create composer-ready packages and in the future we may want to use Composer to load Drupal 7 modules as an alternative to what Drupal 7 developers do to load new modules to their sites. Gitlab would act here as a package server.

I am not here to advocate for GitHub over GitLab. What I will do is reiterate that comments like "anyone can easily run an instance of gitlab ce" and "you can install Gitlab Community Edition anywhere" gloss over the real investment in time and money to maintain infrastructure and keep it secure. Our main concern should be whether we can get sustained involvement for the bespoke PHP/Drupal side of this initiative, and I hope that it will succeed or fail based on that, not on whether it can keep the underlying tools and infrastructure healthy. The good news is that no one is advocating for building our own version of GitLab/GitHub, so we have that going for us!

If GitLab is the favorite, then I would vote for evaluating whether it would be possible to start on GitLab.com and then migrate to a self-hosted GitLab instance if/when it is needed to keep focused on the problems that are unique to this specific initiative.

Side note: I see the amount of effort it takes to keep everything running well through the lengthy discussions in the #gitlab, #drupal-infrastructure, and #drupalorg channels in Drupal Slack. Big hat tip to everyone who pitches in to keep everything humming for Drupal!

I like the idea to start on Gitlab.com and migrate away tp a self-hosted instance once ready (that migration feature is built-in).

Gitlab has its own ticketing system so that we already replace this ticket on d.o. with ticket(s) on Gitlab.

But we need a way to make this official and the initial reporter (@klausi) of this ticket could create the project on Gitlab and do the official announcement. He would then be able to set the project public and let people join and contribute.

There will be many things to setup on Gitlab and we can use the Gitlab ticketing system directly to document all the things needed to be set up. For example, document the proper namespace to host all Drupal 7 modules and create the composer packages (namespace/modulename) and other tasks.

@klausi Please add a wiki page or a Readme file to Gitlab and document the common set of values over there. I agree with those values and it makes very clear the direction you are taking is regards with security updates only. You should be able to edit those values regularly when needed.

Sadly, for numerous reasons, I do not use Slack. But that should not prevent you to use it.

From now to the official D7 EOL date, there will certainly be more discussions about forking Drupal 7 (or Classic) or adding new features to Drupal 7 (including full support for PHP 8.3 or newer versions), but all those discussions will not happen here and be redirected to other venues.

Also, in addition to Views, were you able to identify a first set of Drupal 7 module candidates for the d7security effort?

Views doesn't meet the criteria detailed above for inclusion in Klausi's d7security project, i.e. maintenance of the D7 version hasn't stopped.

adding new features to Drupal 7 (including full support for PHP 8.3 or newer versions),

We will try to make D7 core compatible with PHP 8.3 as it is one of the priorities for the next release. There are only one or two issues left, see: #3380823: [META] Make Drupal 7 core compatible with PHP 8.3 . Contrib world is a bit different, but I suppose most of the D7 TOP modules will make this until EOL as well (as there was not many changes in PHP 8.3).

Hi all. I think this is a really interesting idea, and I want to be clear that I have absolutely no objections to the community continuing to maintain security coverage for Drupal 7 core or modules.

However, reading through all of this, one question comes to mind that I haven't seen addressed yet. And I think this is an important question, because at some point someone is going to ask this. If a stie is staying on Drupal 7 (either temporarily or for a longer period) why would they not just move over to Backdrop CMS?

As far as I understand it, and I might be wrong here, but Backdrop is essentially a drop-in replacement for Drupal 7. It's essentially what is being proposed here, but the advantage being that it also receives active development on new features and has an active community with modules which can be dropped in and replace the Drupal 7 modules.

To me, that seems like a more logical answer to the problem of continued security coverage for core and modules. Think about the total cost of ownership in doing something like what is being proposed here, what you're doing is committing to keep maintaining security fixes for Drupal 7 and lost of modules. That's a lot of effort right there. Is everyone involved prepared to take on that level of responsibility? What happens in 6 months or a year when, say, some of you get busy with other things and lose momentum.

On the other hand, Backdrop has at least proven that it is self-sustaining, and assuming the goal here aligns with Backdrop, then logically by taking the well-intentioned efforts here and contributing them to Backdrop, that then has a larger impact because you're also helping to move forward everyone using Backdrop, while still helping sites using Drupal 7. If the intention here is also to provide support for contrib modules, well then again, I would suggest that putting those modules on the Backdrop site makes a lot of sense, because then you can still provide the same secuirty coverage, but you also benefit from all of the infrastructure that Backdrop has. Backdrop already has all of the infrastructure in place, the update systems in place, and key to this, they also have the processes in place for dealing with security releases.

Again, my comments here are absolutely not intended to discourage anyone from progressing with this effort, I'm just asking questions that others will reasonably ask, and proposing an alternative approach which could achieve the same outcomes. Furthermore, at some point you're probably going to need compelling answers to these questions if you want to encourage sites to switch over to this. And to be clear, I do not have any kind of motivations here, I don't have any desire to maintain any Drupal 7 sites, and I don't use Backdrop, so I'm just coming in to provide another perspective.

Thanks,
-Aaron

Going into the D7security initiative I would like to propose a common set of values:

@klausi: I am sure there will be additions/modifications, but I think the set of values you have laid out is a fantastic start.

AaronMcHale, let's please focus on Drupal here. I've discussed backdrop in great detail in other threads. Please , if anyone wishes to discuss backdrop , please open a new thread about backdrop and we can discuss backdrop in that thread. People in this thread are concerned with Drupal.

I encourage everyone interested to join the Gitlab project made by @klausi. There is now a wiki and code.

Well, Views is still maintained, so it is not a good example. But do we know about some Drupal 7 modules that need to be addressed by this project? Will that list be automatically generated or maintained?

AaronMcHale, let's please focus on Drupal here. I've discussed backdrop in great detail in other threads. Please , if anyone wishes to discuss backdrop , please open a new thread about backdrop and we can discuss backdrop in that thread. People in this thread are concerned with Drupal.

@joseph.olstad Since Backdrop started as a continuation of Drupal 7 it is relevant to mention here. I'm not familiar with any of your previous discussions on the suitability of Backdrop. My point was simply that before putting in a lot of effort it's important to consider what's already available. If Backdrop is not suitable then that's perfectly fine, as I said, I don't have a need for Drupal 7 or Backdrop.

Unfortunately Backdrop is not a drop-in replacement for the complex Drupal 7 sites I'm running. We will likely do an evaluation again next year if Backdrop is worth it or the migration to our Drupal 10 stack or if we keep running Drupal 7 longer.

I'm trying to solve the immediate pain of unsupported modules right now, because I want to know the security status of all the Drupal 7 contrib modules I'm running and collaborate with others on that.

@klausi Thanks, that's useful to know. I'm going to assume then that hosting such modules on Backdrop's site would not work, because, as you say, Backdrop is not (no longer?) a simple drop-in replacement for Drupal 7.

Please feel free to discuss Backdrop in the linked page

To make this work harmoniously, we will have to get a new release of drush or create a patch that will pull updates from the eventual gitlab repos instead of drupal.org, from there we'll have a new version of Drupal core that will look to the new location. We'll have to decide on a new namespace for packagist also. I suggest unlimiteddrupal/drupal unlimiteddrupal/views for example or drupalunlimited/ , something to that effect. Packagist is a lower priority though since few in Drupal 7 are using packagist with Drupal 7. Many drupal administrators (myself included) currently use drush up to get the latest releases so this should allow us to serve thousands of drupal sites. It will be unlikely to get all 300,000 sites onboard but this is one aspect we need to plan for. There'll be many left behind obviously but most of the active and most important ones will follow.

This should be done as soon as possible once we have everything in place so that people will continue to get security advisory update notices in their Drupal 7 environments.

I believe a strong Drupal 7 continues to be great for Drupal 10/11 and has helped immensely to justify new investments in Drupal 10/11. I encourage everyone to consider Drupal 10.1 for new builds. I use Drupal 10 on most of my projects and I'm impressed with the improvements included in D10.1. Drupal 10.1+ has gotten extremely powerful/has significantly improved performance over 10.0 and is improving with every minor release. I also applaud the recent work to incorporate profiling statistics in the pipelines which will help us improve the performance and maintain high performance over time.

@klausi,

You've created a gitlab project but you've not accepted my request to join it. There's currently no way for me to comment on your proposal other than to do so here.

Drupal 7 has been and continues to be one of the:

• most secure,
• most reliable,
• most scalable,
• highest performing (still improving)
• most flexible CMSs/digital experience platforms.
• easier than ever to develop on thanks to a very stable api
• the documentation is bountiful and very good, doesn't need frequent changes
• easy to maintain thanks to powerful tools like drush 8 (drush up for example)
• The barriers of entry are low
• high level of compatibility
• extremely vast hosting options.

Your mission statement does not currently live up to the greatness of the project.

At a bare minimum, what I would like to see is a mission statement that would allow as a bare minimum to continue fostering community work and the greatness that we have seen from the current Drupal core maintainers (FabianX and more recently Poker10 and mcdruid) as they took over for David Rothstein who also did great work with the help of the community.

I see this as a continuation, not a downgrade. Your mission statement currently appears to me like a downgrade from what we've been accomplishing over the past several years. We've fixed many bugs, we've maintained compatiblity with the latest versions of PHP, we've added more automated tests, we've got a better database abstraction layer and have added performance enhancing changes without breaking compatibility. mcdruid and poker10 and many others have worked extremely hard on Drupal 7 to make it better than it's ever been. We're closing in on release 100 for Drupal 7.

Your mission statement currently sets the bar extremely low.

With a more ambitious mission statement we could make a case to legendary contributors such as MerlinOfChaos (Earl Miles) to contribute and share a big portion of his hoard of new Drupal 7 projects. I myself am very interested in what MerlinOfChaos has been hoarding and developing for several years (and he has mentioned this). I want to be involved in a project that is compelling, is inviting to the extent drupal.org has been and try to be more forgiving than drupal.org as a specific goal, a project that nurtures contributions and contributors of all types. I've found that drupal.org is a great example of this generally and it would be great to build and improve upon this. There are others who have been holding back for various reasons, and I believe there is an opportunity for us to make a welcoming environment and bring people in. We should give a second chance to people who were rejected by the DA such as Larry Garfield (Crell) if they so desire. In Larry's case, he's no longer doing work with Drupal and is unlikely to return. MerlinOfChaos however still is doing a lot of work with Drupal I have a lot more optimism that he would join us given that the mission statement is compatible with something that he would like to see.

Since there will likely soon be more than one mission statement and more than one team.

Composer

@klausi I was proposing the creation of composer packages for the Drupal 7 security releases only because Gitlab has a top-notch built-in package manager. We only need to define a “.gitlab-ci.yml” file at to root of each project file. And then in each application built with Drupal 7, add a composer.json file in which we define the location of the package repo (gitlab).

I find that Composer is a good alternative to Drush to download a module.

One example is:

composer require D7Security/devel --prefer-source

… to download Devel with the included .git folder. With that module, work fixes, commit and push back to Gitlab.

Of course, I can simply do a “git clone https://gitlab.com/d7security/devel” to work on fixes, commit and push.

That being said, I can live without Composer on any Drupal 7 site.

Progress

The goal of this project is clear. Help generate security releases of Drupal 7 modules in use that this new team accepts to support.

I like the progress so far.

@Joseph

The goal of @klausi project is well-defined. The scope is documented. And the values are written.

That should not prevent you (or us, globally) from creating Drupal 7 post-EOL support in a NEW ticket, or new initiative. I will probably join you in that effort.

Please let's not mix the goal of the Security team (-> expand Drupal 7 security support) with the wider Drupal 7 (-> Classic) effort. That last effort is opened to many different expectations and hurdles.

Would you mind opening another ticket on d.o. or, better yet, on a Gitlab instance where we can discuss D7 life after EOL?

FYI: Herodevs is offering "never ending support" as a vendor . They will be forking the Drupal 7 codebase, providing security vulnerability coverage , compatibility support and have a reporting system.

This was a unilateral announcement by Herodevs without community consultation.

Early in 2024 my upgraded servers will be ready so I'll review then to see if I am still interested in participating and see whether or not anyone else has stepped in to fill the various gaps.

> FYI: Herodevs is offering "never ending support" as a vendor . They will be forking the Drupal 7 codebase, providing security vulnerability coverage , compatibility support and have a reporting system.

Huh. Isn't this exactly what Backdrop is?

@klausi

> How do I turn this issue around? I could use some support and positive interaction now, anyone still listening that is supportive of the initiative and wants to leave a comment?

... I'm entirely onboard with your initiative. I'm not a huge fan of D7, but we have a dozen D7 sites we are still supporting, and may get more clients going forward with some of our marketing initiatives -- we're committed to supporting the actual modules our customers are using and still need, until we've moved them off to another platform -- Backdrop, WordPress, or hopefully Drupal 10/11.

We are also supportive of this initiative. Makes a lot of sense. Most of our bigger projects have or will be moving, but some smaller non-profit clients may simply not have the budget to rebuild without successfully applying for grants which can't be guaranteed. Thank you.

@freelock,
please feel free to review the linked Backdrop issue
#3409190: Discussion on the merits of Backdrop
I created this linked issue to keep this issue focused on Drupal

@klausi and I discussed this issue a little more in DM and I pointed out in a bit more detail why this discussion needs to move off d.o and particularly out of the core ideas queue.

Now that the community has consolidated around using a GitLab project space, let's update the issue summary with a link to a planning issue in the D7Security project, and then we'll close this issue. Hopefully folks interested in this topic can continue the discussion over there. Thanks everyone!

@klausi, I suggest simplifying the onboarding process. I'm still not a member of your gitlab group and unable to comment on anything. This is especially why drupal.org continues to be so useful. Perhaps also add a slack channel.

@everyone
I have created a slack channel to get organized and discuss
#drupal-7-beyond-jan-5-2024

I have also created a drupalchat.me channel of the same name
drupal-7-beyond-jan-5-2024

These channels are open to the public
Meant to put 2025 but 2024 works

I do not wish to get beaten down for mentioning Backdrop here, but a more relevant link about our project and community is the chat platform that we use. Just an FYI.

https://backdrop.zulipchat.com/

@keiserjb, please add information about Backdrop to this issue:
#3409190: Discussion on the merits of Backdrop

@joseph.olstad

That issue is closed. I was just adding an FYI where people could find actual information about the other project. Please stop sending people to the issue you created. A better place to discuss B is with B folks. https://www.drupal.org/backdrop-cms

@keiserjb, ah yes, I see, it was not only closed, it was completely disabled.

@joseph.olstad I'm not here to debate the merits of individual projects choosing to stay on D7, move to D10, move to B, or something else entirely. The fact is, after end of life this project and the project that shall not be mentioned will have the same common goal, which is keeping contrib projects and a core with very similar codebases secure. I know I would be willing to send along anything from the modules I've ported and maintain, however most of them are so simple that it's unlikely I'd help much. There has always been collaboration about security matters between B and D7 and I'm sure an extended security team would be no different.

@keiserjb,
there's activity in the D7security communication channels
https://gitlab.com/d7security/d7security/-/wikis/Communication-Channels

Currently @klausi is leading the charge on the D7security approach (for now)
We'll see how this evolves.

Thanks everyone! Now that the GitLab discussions are linked from the IS, the discussion should continue there and not on d.o. Thanks everyone!