Proposing a Drupal 7 security team on Github

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.

@greg.1.anderson thanks a lot for the support! It will take a bit of time to put the basics in place.

@joseph.olstad my plan is not to fork all D7 repositories, but only the ones meeting 2 conditions:
1. It must be in use or supported by at least one of the D7Security participating members/companies
2. It must be unsupported on drupal.org and cannot be made supported again there.

I want to work with the existing drupal.org infra as long as possible.

Server: I'm planning to do this completely serverless on Github, which means Microsoft will pay for the hosting costs. I can use a trick so that Drupal 7 installations will download static update XML files from Github. There are no service fees on Github for open source projects.

I have not given much thought about executing automated tests for Drupal 7 modules, this could be a bit of a headache on Github.

@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 GH.

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

• Nothing about it is on d.o so that current site maintainers etc. aren't responsible for it.
• The current maintainers, Security Team, and DA are not responsible for 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.

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.

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 server with gitlab CE installed and a cloud of runners could be brought in.

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 that will come online soon, has 128 gigs ram, 8T raid 1, 2T high performance M2.1 on a RAID 1.

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

@jeni_dc appreciate the XP humor, that made me smile. And no, we will not call it XP, lol.

@xjm: I'm fine if there is nothing official about this on d.o, but of course people will discuss this in issues and forum posts, link this on module pages etc. I think that is ok.

Responsibility: fully agreed, that is the whole point of this initiative: that somebody else can take responsibility.

Being asked about it: that will not be possible, we cannot prevent that. Of course people will ask about it. I fully accept whatever you answer in this case, mentioning this initiative or not. I would recommend something along the lines "we don't support Drupal 7 anymore, but you can go to these commercial providers or check with D7Security on Github
".

Reporting Drupal 7 security issues: I would suggest 2 phases:
1. Before Jan 5, 2025: All Drupal 7 security issues must be reported via security.drupal.org. For unsupported modules the Drupal Security Team can reply with boilerplate text "We don't support this module anymore, please go away" or with a more productive reply "We don't support this module anymore, but you can report with D7Security at Github
"
2. After Jan 5, 2025: All Drupal 7 security issues should be reported at D7Security Github. We would change the instructions so that people are not sent to security.drupal.org anymore. If Drupal 7 reports are received at security.drupal.org you can again reply with boilerplate text "We don't support Drupal 7 anymore, please go away" or with a more productive reply "We don't support Drupal 7 anymore, but you can report with D7Security at Github
"

Branding: I'm a fan of being explicit and clear, hence the D7Security idea. Let me know if you have a better name suggestion.

Gitlab self hosted: I would like to avoid making big infrastructure investments upfront. First we need to find out if this proposal and this group can work. If we then run into scaling or execution problems then we can make that investment if we have the resources.

So I would propose to get started on github.com SaaS or gitlab.com SaaS. I prefer Github because more developers already have accounts there, lowering the bar of contributing.

We don't need to clone all repos, I trust that the D7 git branches will be kept on drupal.org for the time being. Even if they get deleted that would also not be a big problem, since we have the source code of the relevant Drupal 7 modules running on our D7 sites :-)

@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

We could start with gitlab.com , with that said, I'll have a full hosted instance of gitlab , exporting from gitlab to gitlab works quite well, it is a way to ensure that our efforts continue and are not wasted.

I'm fine with gitlab.com as well if there are more people preferring it. Let me know here!

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.

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 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 updates.

gitlab is by far a better option for several reasons:
1) it's an open source platform
2) it 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 interac 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
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
8) gitlab is well documented
9) 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.

@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 (VPW, 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 and backups.

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.

@xjm: Can we keep the initial discussion going here for a few more weeks? I would like to keep it open for a bit to collect feedback and attract contributors. I hope that we should be able to close the discussion here in January 2024 and move to the D7Security project space.

I'm warming up to the idea of going to Gitlab.com and have also reserved the namespace there https://gitlab.com/d7security .

I also created a channel in Drupal slack called d7security https://app.slack.com/client/T06GX3JTS/C06AP6GE05P .

@joseph.olstad: I want to set some expectations with you, because I saw some of your posts about a "Drupal Classic" fork. Going into the D7security initiative I would like to propose a common set of values:

* There will be no branding under a Drupal Classic fork.
* We accept that Drupal 7 is legacy software. Developers should not use Drupal 7 to launch new sites, they should use Drupal 10 or Backdrop instead. We don't argue about which CMS system is better in the D7Security space.
* The mission of D7security is to ensure stability, security and PHP compatibility of Drupal 7 sites, so that they have more time to upgrade and migrate. We are not interested in developing new features or doing code refactoring in Drupal 7 modules and want to keep changes to a minimum.
* We respect the Drupal Security Team and the Drupal Association and their decisions of not supporting Drupal 7 in the future. We want to make all our lives easier and make this initiative a win-win for Drupal 10 maintainers/release managers and Drupal 7 maintainers.
* We accept that security fixes will be released for Drupal 10 modules first and Drupal 7 second. This is important so that Drupal 10 maintainers and Security team are not delayed on coordinating with Drupal 7 module releases. Yes, running legacy software like Drupal 7 implies a higher security risk, but I believe we can mitigate it well enough with this initiative.

2 more points where I'm not so sure yet, but my current opinion:
* In general we want to replicate the system and workflows of coordinated vulnerability disclosure that the Drupal Security Team practices (once knowledge about a vulnerability is published there is also an update available that you can install).
* We only support Drupal 7 modules that we use and want to maintain. If we receive security reports for modules where we have nobody in the d7security group that maintains it, then we ask the community to step up with a grace period and otherwise publish the vulnerability report as full disclosure.

Let me know what you think!

In the meantime I have started the update status prototype setup at https://gitlab.com/d7security/d7security_client . It is a Drupal 7 module that will inform you of supported releases and security updates that are provided by the D7Security group.

For testing I have re-supported the Devel module. The last 1.7 release from 2019 should now show up as supported again at /admin/reports/updates on your Drupal 7 dev/test site (if you have Devel module installed). Please test on your Drupal 7 dev site and let me know of any issues.

I'm still linking to the old Devel releases on drupal.org (they have not disappeared yet). The next step would be to test an actual new Devel release at D7Security, steps needed:
* Fork Devel git repo under https://gitlab.com/d7security (only the Drupal 7 branch to avoid confusion) from drupal.org
* Create a packaging script that will add timestamps to the devel info file and create tarballs
* Create an update XML generation script that will create the release XML that can be added to the
* Add tarballs and updated XML manually and see if that works

Those steps could probably be automated when a tag is pushed to Gitlab, we can do this later.

@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: 🌱 [META] Make Drupal 7 core compatible with PHP 8.3 Active . 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

Backdrop is great, I just listened to the Backdrop episode of the Drupal 7 EOL podcast today.

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.

D7Security wiki started, copied the values there, also started a page how to join the effort https://gitlab.com/d7security/d7security/-/wikis/home

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.

@markdorison thanks a lot, appreciate your work on the D7 EOL podcast, am a big fan!

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 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 new gitlab repos instead of drupal.org. We'll have to decide on a new namespace for packagist also. I suggest unlimiteddrupal/drupal unlimiteddrupal/views for example. 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 a tough mountain to climb 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 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.

Some progress I made so far:
* Documentation expanded in the wiki on Values, Security policy, how to make a security release https://gitlab.com/d7security/d7security/-/wikis/Home
* Release prototype for devel module completed successfully, yay! There is now a new supported release and the update XML has been generated semi-automatically with a script.
https://gitlab.com/d7security/devel/-/releases/7.x-1.8
https://gitlab.com/d7security/d7security/-/blob/main/devel/7.x?ref_type=...
* I created a Gitlab pipeline to produce tarballs automatically with modified module info files that have version information and timestamp. https://gitlab.com/d7security/d7security_gitlab_components/-/blob/main/t... .

Overall Gitlab is good enough for me, the only downside I found so far is that a Gitlab pipline cannot commit our update XML out of the box. This would have been much easier with Github Actions. But I think we can find workarounds on Gitlab to get that automation done as well.

D7 modules that we will address: there is currently one module where the D10 security fix from the private security.drupal.org discussion has not been released yet. Once that is out I will add it to supported_projects.txt. This list is manually maintained (since the goal of the D7Security group is to only support what we actually run).
Let me know if you have another project you would like to re-support and I can help you with that!

Backdrop modules: I don't think hosting D7Security fixes in Backdrop repositories would be a good idea, could be quite confusing.

"drush up" support: Did not look into that yet, help welcome. Same for "drush make".

Packagist: I have no plans for that, we don't use packagist for Drupal 7. What would be the use case? Anyway, please open a Gitlab issue for that, out of scope for this issue.

Naming "unlimiteddrupal/drupal": absolutely not, that would violate my proposed Values. We are not interested to maintain Drupal 7 forever, only for the time being for security support. No branding as "Drupal classic" or "Drupal unlimited" or similar.

@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, highest performing, flexible CMSs. 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. 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.

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

@joseph.olstad please stop derailing this issue, reverting the title.

I think I have laid out the goals and purpose of this initiative clear enough. With your continued refusal to understand what the D7Security group will try to do I currently cannot accept you as member of the D7Security group, as I cannot trust you.

You can still comment and propose issues or merge requests on Gitlab for now, but please stop the distractions that violate the values I'm proposing as foundation for this initiative.

Please also stop the toxic communication style like "Your mission statement currently sets the bar extremely low." when I am putting a lot of effort and intention into making this initiative a workable success.

---

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?

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: @xjm is a member of Herodevs , the organization which co-ordinated it's announcement of offering "never ending support" as a vendor around exactly the time the LTS program was cancelled and the "final" DA extension was announced. 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 still am interested in participating to 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!

I would have hoped that we could continue here a bit longer for better community visibility, but we can continue on Gitlab, issue number 1 created: https://gitlab.com/d7security/d7security/-/issues/1

@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

Please note that the communication channels of the D7Security group are documented in the wiki: https://gitlab.com/d7security/d7security/-/wikis/Communication-Channels

We use the #d7security channel on Drupal Slack.

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.

@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.

The first d7security newsletter is out! Website, logo, user guide, new members and more! https://gitlab.com/d7security/d7security/-/issues/2#note_1706599190

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

This is not a duplicate, we can leave it as outdated.

The second #d7security newsletter is out - podcast episode, new members and more!
https://gitlab.com/d7security/d7security/-/issues/2#note_1761723679

The fourth #D7Security newsletter is out! Watch me talk about D7Security in a recorded video https://gitlab.com/d7security/d7security/-/issues/2#note_1911714087

The 5th D7security newsletter is out: https://www.d7security.org/blog/10-09-2024-d7security-team-newsletter/