Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.In IRC, a few of us were discussing how drastic update_status should be when it finds a missing security update. One of the ideas was to have a setting to put your site directly into site maintenance mode when it finds a missing security update. ;) See http://drupal.org/node/153970 for more.
However, if we did that, it'd be really, really bad if someone accidentally put out a release node marked as "Security update" if it wasn't really a security release. :( Also, no one should be making security releases without coordinating with the security team, anyway. There were already a few examples of people who didn't understand what they were doing tagging releases as security when there was no SA and no vulnerability fixed, etc. Finally, Heine once requested we had a way to delay the publishing of security releases nodes so the security team would have time to test the resulting tarball, etc, etc, before the node goes out and the SA is published.
All of this points to a clear need for a security release node workflow and moderation. Luckily, there's a pretty easy solution that doesn't require much code:
1) Packaging script never publishes release nodes marked with the "Security update" term.
2) We add a trivial php node somewhere on d.o that only admins and/or the security team can see, which lists all unpublished security release nodes with "edit" links. We can make this page more fancy in the future, if we want (make it a form with checkboxes to publish, download links to grab the tarball, whatever). That said, I don't really think this page belongs in project_release.module. All this "Release type" stuff is d.o-specific taxonomy tricks, there's nothing hard-coded into project_release to deal with this. So, I'd rather leave this a d.o php node instead of putting the code into project_release. However, if there's major resistance to that, I'd be willing to reconsider, but I think this is easiest and best.
Is there general agreement on all of this? If so, I could whip something together in no time...
Cheers,
-Derek
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | package-release-no-publish-security.patch.txt | 1.74 KB | dww |
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedyuck. automatically put a site into maintainence mode? thats way too much mothering for my taste. your security node workflow is fine but i object to this nanny state proposition.
Comment #2
gregglesThe auto-maintenance-mode-nanny-state is not the thrust of this issue.
+1 for everything else
Comment #3
dwwHere's the patch against the packaging script (contributions/modules/project/release/package-release-nodes.php). Untested, but I think this is all we need. Note that in the scheme of things, it's rare for the packaging script to actually publish an official release, so I'm not too worried about the additional query for each release node it's about to publish. The main query that drives the script is already insanely expensive and in much need of optimization, so adding another LEFT JOIN on {term_node} for this seems like a bad move.
Anyone feel like working on some draft php code for the d.o node that'll act as the moderation UI? I gotta get some sleep. ;)
Comment #4
dwwCommitted and installed on d.o. There's a watchdog('package_security', ...) with a node link every time it decides not to publish one, so worst case, that can be our moderation queue for now (since we can filter watchdog on that unique type). A more slick page can come later if/when we want.
Comment #5
(not verified) CreditAttribution: commented