>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #153973. --> Reported by: [dww](https://www.drupal.org/user/46549) >>> <p>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 <a href="http://drupal.org/node/153970">http://drupal.org/node/153970</a> for more.</p> <p>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.</p> <p>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:</p> <p>1) Packaging script never publishes release nodes marked with the "Security update" term.</p> <p>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.</p> <p>Is there general agreement on all of this? If so, I could whip something together in no time...</p> <p>Cheers,<br> -Derek</p>