Add "Insecure" term to "Release type" vocabulary

pathauto 5.x-2.0 is now the recommended version of pathauto. since there was an update between your current release and the 5.x-2.0 release that was flagged as a security update, update_status is telling you that you'd better upgrade to the latest release due to potential security problems. there's no bug here.

remember 1.2 do not have this bug. update_status has no way to know this. all it knows is:

a) you're running an older version, no longer recommended by the maintainer.
b) in between your version and the currently recommended release, a security vulnerability was fixed.

therefore, you should upgrade.

what if 5.x-1.2 is so broken and insecure that greggles dropped it and decided it wasn't worth fixing? update_status never tells you? no thanks.

i repeat, there's no bug here.

Yes, I understand the problem. If this is now what you're talking about, it's duplicate with http://drupal.org/node/176776 and/or http://drupal.org/node/189546#comment-624677

What you keep misunderstanding is the limitation in project* that it still has a notion of a single recommended branch for a given version of core. Before the release system, there was only *ever* 1 branch per version of core. You don't seem to appreciate how difficult it is to make sweeping changes in the Drupal community. So, I had to move from only 1 branch ever, to 1 that's recommended, with the possibility of others. There are many larger changes I would have liked to make all at the same time, but it was simply impossible to get the community to agree to all of them at once, so I had to pick my battles and make the most important changes first, and lay the ground work for others.

With hunmonk, aclight, drewish, and a small handful of other people in the past few months, things have finally changed for the better with project* regarding outside help. At long last, I'm not the only person generating, testing, and deploying patches. But, before that, it was overwhelmingly me operating on my own, entirely unpaid/volunteer, in what little time I could spare. Much of that time was sucked up fending off duplicate requests in the queue from people who hadn't bothered to read the plans I had clearly laid out for what needed to happen next. So, things didn't always move as fast as I'd like to see them (and they still don't, but it's at least getting better).

Back to your original issue, the only way for update_status to know that 5.x-1.2 is secure, while 5.x-2.0-beta2 is not and 5.x-2.0 is again secure, is if we added another "Release type" term called "Insecure". It has nothing to do with trying to apply these taxonomy terms to branches (which is both impossible given the architecture of Drupal, and itself wrong, since 2.0 might be fine, 2.1 introduces a vulnerability along with a new feature, and 2.2 is the security update that fixes 2.1). Every time a "security update" release is created, the maintainer and/or security team would have to back and flag all the insecure versions retroactively with this term. Then, update_status would notice on the next check that the version you're currently running is now marked insecure. In a perfect world, that'd be the best solution to this problem.

Unfortunately, it creates even more work and potential for maintainer error. :( That's another thing you don't seem to appreciate -- how difficult it is to try to get people to correctly use the tools they already have. We constantly get releases marked with "Security update" that shouldn't be. The security team is already stretched thing, so the burden of figuring out exactly which existing releases are vulnerable to a given bug and which are not, and marking all of the release nodes accordingly, is a lot of extra work. All that effort just to handle an edge case where a switch from one branch to another is accompanied by a security update and update_status accidentally tells you to upgrade for security concerns, when really you should just upgrade because that's now the maintainer's recommended version.

If we do this at all, we'd need a good administrative interface for selecting a set of release nodes all at once and bulk adding/removing release type terms from them. Core doesn't allow this, so we'd need custom code for d.o to make this work. However, if we're actually going to ask the security team to maintain this term (both for viewing on d.o, and for update_status to report), we have to make it as easy as possible for us to do our job.

For all of this to be really ideal, *only* d.o users with the right permission would even be able to use the "security update" and "insecure" terms on a release node, bulk editing or not. That's functionality core doesn't provide, either, so we'd need more custom code to make it work.

Feel free to actually contribute some code instead of bitterly complaining about how I don't understand, and if only I saw things your way the world would be a better place. I can't tell you how many times I've written up lists of issues and roadmaps and everything else to encourage and enable people to help.

Great, now that that's clear, here's what would have to be done before this could actually happen:

A) Agreement from the rest of the security team that it's worth doing all this work for such a relatively minor edge case.

B) New issue against update_status with code to see if the current release is marked as "insecure" and warn the site admin accordingly.

C) Agreement from Gabor and/or Dries that they'd be willing to accept a reroll of the patch from (B) for core this late in D6.

D) d.o-specific helper code to restrict these terms to a certain permission (for now, could be either 'administer nodes' or 'administer projects' i guess). this belongs in the drupal.org module issue queue.

E) d.o-specific helper code to mass edit release nodes to set "Release type" terms. also belongs in the drupal.org module issue queue.

F) Draft handbook text about how all this works and what module maintainers need to do about all of this.

Once those 6 things are done, we can actually create this new term. We can use this issue to coordinate progress on these tasks, so once other issues are submitted/completed, we can update here. When A through F are all done, we can actually implement the new term. I'm not spearheading this effort.

Re: (A): I just emailed the security team soliciting feedback on this. That's as far as I'm going to take this effort at this time.

I don't know about everyone else, but I am exhausted after reading Derek's todo list in #9. I personally think this is too much work for an edge case. If someone wants to do it voluntarily, then I congratulate them. I agree that i is low prority for the project team and drupal.org in general.

i'm in agreement with moshe. the project team and d.o infra/security team have more pressing tasks than servicing this edge case. any progress would have to come from an outside volunteer.

See http://groups.drupal.org/node/7440 for a proposal for a complete solution to all of this.

The administrative overhead looks acceptable to me

As one of the persons who most likely will be doing the actual 'insecure' marking, I strongly disagree. The marking is not the problem, looking through the code is (as dww indicated already). IMO if 5.x-1.1 is not vulnerable, but 5.x-1.2 is and 5.x-1.3 fixes the issue, all users should upgrade.

Webmaster Issue Queue Cleanup - 2 year old issue

Postponed for 2 years... is tagging the project release something planned? (It seems that the project release tables have gotten more refined in the last couple months re: http://groups.drupal.org/node/7440#comment-24654 )

Yup, no outside help ever came, and I have more important things to do.