[meta] Looking for Drupal 6 security maintainers

I would be interested in being involved in this, but curious what the time commitment would be - is there any indication on how much time existing security maintainers spend (average per month say) on this activity?

I think it's reasonable to expect at least an hour a week on average to do it well. If there's a release then it can easily be more like 4 or 6 hours during that release window. Some of the work is asynchronous and some is real-time, so it's OK if someone has free time on their own schedule as long as they are good at working in an issue queue (i.e. good written communication skills).

I would say what we need first is someone who will actually test Drupal 6 breaking. https://groups.drupal.org/node/5974 this. If we do not have someone doing it, it's irresponsible to continue.

One idea that catch threw out was finding a subset of big D6 users w/ trustworthy admins, and give them early access to security patches for testing on production. This would probably be much better than individuals trying to follow the manual test suite I put together back in the day, because that'll only catch problems in a clean install, not problems with X,000 comments/nodes/users and the like.

I'd definitely be interested in doing this. I currently maintain (and still develop on) several Drupal 6 sites, some of which clients have no interest or budget for updating to Drupal 7 or 8. Others will be migrating (probably to D8) in time, but I think that the addition of a grace period for D6 support as described above is a great idea.

I am interested too

For folks interested in joining, I encourage you to read http://security.drupal.org/join

For folks interested in joining, I encourage you to read http://security.drupal.org/join

Will do. Thanks.

In an unusally personal comment: if techsoldaten joins this effort then my concerns over trying to support Drupal 6 will decrease significantly.

Thank you, Dries. I will help out. We invested a substantial amount of time and money in our D6 site last year. I have experience with security and revision control systems. I'm in the greater Boston area. PGP Fingerprint=A4C6 C505 6949 B942 9C36 CEF4 180B 8BAF 13B2 7893. charlies at dharma dot org

I think it's reasonable to expect at least an hour a week on average to do it well. If there's a release then it can easily be more like 4 or 6 hours during that release window.

Thanks Greg, that sounds manageable.

In general I appreciate this initiative. It's good to see that drupal as a project starts to care more about its users.

But I'm missing a proposal how contrib maintainers should deal with 3 incompatible core versions in parallel. Supporting 6 and 7 in parallel is already hard. 7 and 8 in parallel will become insane because you can't share any code.

A maintained drupal 6 core is worth nothing without maintained contrib modules. So at least security updates for d6 contrib modules have to happen.
But who will do that? The new drupal 6 core security maintainers?

We, Ny Media AS, have several D6 sites in production, some ranging from tens of millions of nodes to tens of millions of page views per month. These sites will NOT be ported to D7/D8 in the foreseeable future. The costs of such and undertaking would be enormous.

We are "exceptionally good at breaking things", because we have often pushed Drupal to it's limits, then broken it, then recovered by working around discovered limitations. We are sitting on a large amount of custom code/modules/hacks to make D6 work with slave/master solutions, memcache, redis, Solr (on most sites we do not use the "official" solr module).
What I'm thinking is that I could provide support by looking over/commenting on suggested fixes based on past and present experience with Drupal 6/PHP and also because I can do comparisons with our "in house" code/changes.

I'm missing a proposal how contrib maintainers should deal with 3 incompatible core versions in parallel

Some statistics: there are ~8000 contrib projects with D6 branches. In the last 18 months, there have been security announcements issued for ~80 of them. Only 7 have had 2 SAs in the last 18 months, and none had more than that.

So assuming that for an additional 18 months of D6 security maintenance beyond 8.0 release (the upper end of what is mentioned in the issue summary), if these same statistics hold, for each contrib project, that maintainer has a small percentage chance of needing to implement 1 security fix to the D6 branch and a tiny percentage chance of needing to implement 2. (Some contrib maintainers maintain multiple projects, so their workload would increase accordingly.)

No individual contrib maintainer is forced into continuing in that role. They can choose to abandon that role entirely, or stop supporting a particular branch. Many projects have different maintainers for different branches. If for a particular project, no one is willing to maintain a particular branch, then that branch can be marked unsupported, and site owners can decide whether to stop using that project or continue using it despite the risk.

I'm really interested on this. I have been working for more than a year exclusively with Drupal 6 (I also have developed using Drupal 7 some time before). In addition, I'm strongly focused on web application security (OWASP, ethical hacking...), so maybe I could be of some help.

Dries: I'd be interested, but how to apply? Usually I'm good at breaking things by design.

@effulgentsia you're right that the amount of time to spent on security issues of d6 contrib modules might be low. But you have to take into account that if a module is still available you receive bug reports and support requests for that version.
But I'm fine to see if you could manage to establish some Drupal 6 security maintainers first. The consequences for contrib might be discussed afterwards.

For contrib, one fairly common practice is to set your project maintenance status to "Seeking co-maintainers" and put out a call for a branch maintainer for previous branches you no longer care about. For example, Moshe gave me access to OG 4.6 back in the day, when he was only interested in 4.7. I would back-port the 4.7 patches, which I needed for my "day job" anyway, so it was a good fit.

@webchick: As we don't have branch-level access permissions for D.O projects (yet ;)), I'm assuming that this setup is based purely based on trust, and that you COULD have pushed to a different branch if you'd have wanted to though?

Yes but the next time the maintainer tries to push and it fails the game is up. You can't sneak in changes. And at the end of the day we all trust each other. Do you do a through security audit of every module you install? See...

I would love to be part of this great initiative which will benifit so many sites and their users.

I am working on Drupal from last 8 years and have worked on Drupal 4, 5, 6, 7 and now 8. I started contributing in Drupal community couple of years back and it really helped me in learning so many things.

Participating in this initiative will definetly be a great experince for all of us!

Hi,

can anyone advise me as to the official outcome of this initiative. My company support several large Drupal 6 installs for government agencies. Whilst they have measures in place to migrate to Drupal 7, knowledge of timelines for security support on D6 will help make informed decisions.

Dries's stance and the generous offers of help from you all can only contribute to persisting existing Drupal adoption and encourage others to do so. Thanks

Paul

This makes a huge difference for me to migrate a Smithsonian site. If D6 security is extended, I may skip straight to 8. If not, then D7, and it'll be there until the next time this comes around. The reason is that the hammer comes down on the site the first time a security patch does not come out. If the site is still on D6 when D8 comes out, and there is no plan to support security, the site will go offline. Eventually, it'll be moved off Drupal if this keeps coming up. I can only comment on what I hear from our IT department at the Smithsonian. People here don't like the idea of a site having such a short lifespan. Money is hard to come by, and a site may exist as is for longer than two cycles of Drupal. Our IT has stated that sites on unsupported systems will be unplugged. If people think their site may get unplugged in 4 or 5 years, then they'll start looking for alternatives. I think if Drupal wants to stay relevant in the Gov't space, the length of time security is supported needs to be rethought. There are a slew of sites in D7 that will, in theory, need upgrading when D9 comes out. I can't imagine there will be money to upgrade them all, at least not based on my experience.

Sean

Several people have followed the instructions on https://security.drupal.org/join

If someone is interested in doing this and has not yet read or followed the instructions on that page...please do ;)

What is the next step on this thread? I think this has been useful to raise the profile of the need and identify candidates, but what next?

This is the kind of thing that is never really "fixed" - more help would always be useful. So, perhaps we should agree to leave this issue open forever as a major task (or even critical bug) so that people curious about Drupal 6's maintenance will see it.

Could it be marked as a meta issue?

Sure.

Actually, it would also be good to add the relevant "what next" bit from #25 to the issue summary, so people know what they need to do without reading 25+ comments. I added a blurb to the top of the issue summary (marked it as coming from me, rather than Dries, since his instructions are slightly different and changing the text of them feels weird).

From my perspective, having the details in the comments instead of the summary makes more sense.

Wait, really? How are people going to know, once this thread is 100+ comments long, that #25 has the thing they're supposed to do?

I agree with webchick on this one. Easier to have a link at the top of the thread.

Easier for what purpose? This is a situation where getting dozens of applicants has significant cost. Every applicant to the team means that the team has a discussion that involves at least 4-5 people who read up on the profile of the person, do digging on them, consider if they would be a good fit, reach out to network of friends to do as much background checking as possible, and then write an email with the results of that work. If the person isn't committed...that's a net decrease in team efficiency.

Among the people who passed the first review and were accepted as provisional team members (since March of 2012) we've had 6 applicants to the security team who were accepted and 2 who bailed on the process (I'm probably missing 1-3 people). We had probably 6 more applicants who were not accepted to the provisional level. When someone bails on the process it means at least 2 members of the team are following up with them via email and irc for a few months first trying to help out, seeing if there are workflow issues, etc. to help get that person engaged. Those 6 applicants who were accepted have done amazing work, are very proactive and detail oriented, etc. I'd like to keep the ratios along these lines ;)

In short: It's not always better to make a signup process easier.

#8 also has the right thing to do.

And I forgot to add that for the ~6 people who applied and weren't accepted as provisional members someone did write (or should have written) a nice email giving specific advice encouraging that and giving them a roadmap to re-apply. So the review process takes time as does the "rejection" process (really it's a "not yet" process).

Ok, fair enough.