Closed (fixed)
Project:
Update Status
Version:
5.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
22 Jun 2007 at 09:05 UTC
Updated:
7 Jul 2007 at 02:16 UTC
Jump to comment: Most recent file
Given that we now handle most dev snapshots, and usuall notice if a newer snapshot is available based on date, it seems we could also flag security updates for dev snapshots, too. Here's how:
- As we process the list of releases for a given major version, if we know the timestamp of the currently installed snapshot, we use then to decide when to stop searching (currently, we end up searching through everything, since the dev snapshots are always last in the history list).
- If we see any security update releases that happened more than 100 seconds later than our currently installed snapshot, we fill in our 'security updates' array for that project.
- Once we hit an official release that's older than our dev snapshot, we stop looking.
- At the end, if we found any security updates, we flag the dev snapshot as insecure and use the usual display logic.
In fact, if we find an official release with a newer timestamp, we should still mark the dev snapshot as out of date and recommend the newer release, instead of recommending another dev snapshot.
In fact, now that I'm testing it, there's a bug in the existing logic. ;) We only hit the logic to recommend a newer dev snapshot if there are *no* official releases (stable or extra) for that branch. :( We're currently depending on $latest, and if that's a dev, we do the time check, otherwise we don't.
At the very least we should fix this bug and always check the date of the dev snapshot, even if it's not what we'd call the "Latest release". However, while we're at it, I'd also like to get the security update logic outlined above in there.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | update_status_dev_timestamp.patch_2.txt | 6.84 KB | dww |
| #3 | update_status_dev_timestamp.patch_1.txt | 6.59 KB | dww |
| #1 | update_status_dev_timestamp.patch.txt | 19.88 KB | dww |
Comments
Comment #1
dwwHere's a patch. Works great. Unfortunately, I started working in a workspace that already had the patches applied for http://drupal.org/node/153502 and http://drupal.org/node/153757 :( Whoops. So, this is a big nasty patch that includes all 3. That's what I get for not just committing my patches right away. ;)
So, as soon as those other patches land, which sould be soon, this will need a re-roll to resolve the conflicts, but I'm ok with that. I'd rather do things in smaller steps, anyway. But, if anyone wants to play with this in the meanwhile and provide feedback on the UI and behavior, I'd be most pleased.
The functional/UI changes are:
Let me know what y'all think. Thanks!
-Derek
Comment #2
dwwI just committed those other 2 issues, so this needs a re-roll.
Comment #3
dwwComment #4
dwwWhoops, I had a bug in the timestamp comparison logic for ignoring security updates older than the currently installed dev snapshot. I was trying to add the 100 seconds of leeway, but I was doing it on the wrong side of the comparison. ;) All better.
Comment #5
dwwCommitted to HEAD as revision 1.64 of update_status.module.
Comment #6
(not verified) commented