mark modules with security issues
Pasqualle - March 7, 2007 - 23:28
| Project: | Update Status |
| Version: | 5.x-2.x-dev |
| Component: | Miscellaneous |
| Category: | bug report |
| Priority: | normal |
| Assigned: | dww |
| Status: | closed |
Description
Is it possible to add such functionality to this module, that it would inform me when the (last official version of) installed module has security issue(s)?
#1
it would require much more than support from this module:
1) release nodes would need to have a flag to indicate they include a security fix
2) contrib maintainers would have to set this flag accordingly
3) the XML-RPC interface on drupal.org that serves the info used by this module would have to be changed to return this data
then...
4) this module would have to display the data in some useful way in the UI.
this would all be good, and in fact, has been planned for months, but none of it is done yet. in fact, there aren't even issues posted for #1 and #3, yet. so, for now, this particular request must be postponed until these other things are resolved.
thanks,
-derek
#2
bump: i just submitted http://drupal.org/node/136172 as an issue about changing the XML-RPC protocol to be able to support this sort of thing.
#3
see http://drupal.org/node/142344 -- we've now got a "Security update" term we can apply to release nodes.
and, progress continues at full steam for http://drupal.org/node/136172
so, this issue is active again... i'm also bumping to "critical", since we need a working prototype of this functionality ASAP so we can fold it into core in time for the D6 code freeze.
#4
this is nearly done in the 5.x-2.* series...
#5
minor visual problems with the current version. see screenshot. patch forthcoming.
#6
screenshot of proposed fix.
#7
patch that accomplishes the previous screenshot
#8
committed slightly modified version to HEAD. webchick pointed out that the underline made it seem like a link, which is a no-no. it would be slick if we could have that be a link to the right SA, but that's actually a huge can of worms that would require even more work on the server side.
setting this back to active so that we can work out the edge cases with releases marked as Security updates that have extra in the version number (e.g. project_issue 5.x-0.2-beta).
#9
after discussion in IRC, we decided it's somewhat confusing on the case where a security update happened but another (non-security) release is already available. audio.module is a good example. 5.x-0.3 was a security update, but 5.x-1.0 is now out. before, if you were running 5.x-0.1 and ran update_status, it'd correctly tell you that you need to upgrade b/c of a security update, and it would correctly recommend you install 5.x-1.0, but it wouldn't give you any link to 5.x-0.3 to see what the security problem was. attached patch fixes this. it's somewhat simplistic, in that it always lists a "Security update:" row in the table, even if it's the same info as the "Recommended version:" row. however, we think that might be a feature, not a bug, since it helps drive home the point there's a security update. ;) screenshot coming next.
#10
screenshot of the above. doesn't show the case where the security update == the recommended version, but i think you can imagine that.
also, this is just a list, so if you're running something really old and there have been N security updates, each one will be listed in the table for that project. i can't find any real examples of that to demo yet, though i guess i could put some bogus data on s.d.o and point my install at that if we really wanted to test it. ;)
#11
now, with the "Security update:" label wrapped in a span with the same class as the "Security update required!" stuff.
#12
i like #10 better than #11: if the recommended version is newer than the security update, we really want them to upgrade to the recommended version, so extra visual attention to the security update release might be counter-productive. so, i committed #9 to HEAD.
#13
bump for clarity: the only reason this issue is still active is because of the edge case where the latest release for a given major version we're tracking is both a security update and a beta, as is currently the case for project.module and project_issue.module. once we handle that, we're done here.
#14
my patch at http://drupal.org/node/149918#comment-261116 solves this, too.
#15
Yay, this is working fully, now that http://drupal.org/node/149918 is committed.
However, over at http://drupal.org/node/149918#comment-261964 merlin rightly pointed out that the UI looks a little wonky for this. In IRC, he suggested just replacing the "Update available" text with the "Security update required!" part. Sounds good to me. I'll work on a patch now.
#16
#17
screenshot of the latest. i know we talked about this before, but i'm having 2nd thoughts about including both "Recommended version" and "Security update" if they're both pointing to the same thing. If there are multiple security updates, I can see it, but what's in this screenshot is a little weird, IMHO.
#18
This patch changes the text from a div to a span and removes padding and floating that is no longer necessary.
#19
Building on merlin's fixes to my previous patch:
1) Don't bold the "Security update:" part, allow the red color to visually distinguish it. We still bold the "Security update required!" part in the status area. But, excessive use of bold makes this look cluttered, and makes it harder to use bold where we might need it.
2) If there's only 1 security update, and it's the same version as the recommended version, don't print it twice. Just print the the "Security update:" line, not the "Recommended version:" one.
#20
merlin and i discussed this more in IRC. we agree we *could* use that bold in some cases, just not all. so, we'll tackle the use of bold over at http://drupal.org/node/149079. meanwhile, committed #19 to HEAD.
#21