Another defense against ever printing bogus available update results

While working on http://drupal.org/node/209242, I had another thought about defending ourselves from printing bogus available update results. One of the big symptoms of that other bug is that when we can't find the currently installed release in our list of available updates, we print all kinds of wrong things, especially if that project *ever* had any security updates.

The reason for these bogus results is that the available update comparison logic remembers all the security updates it can find until it hits your currently installed release, so that we can correctly mark a project as needing a security update, even if the most recent official release isn't itself a security update (e.g. 6.x-1.0 is installed, 6.x-1.1 is a security update, and 6.x-1.2 is now available... we want to tell people to upgrade to 6.x-1.2, and warn them that their site is insecure). So, if we *never* find the current release, we think the site is missing every possible security update. :(

So, here's a pretty simple solution. We just use a flag to remember if we ever found the currently installed release in our list of available updates. If we get to the end of the available releases and still haven't found the current release, we know something is seriously fubar, and instead of printing bogus results, we set the status of this project to UPDATE_UNKNOWN, with "Current release not found" and the following extra help text:

Unknown release: The currently installed version of this project was not found in the list of available updates.

This works great in local testing. However:

A) This would break the string freeze again (ugh, sorry!). :( I suppose we could use the same logic, and try to reuse some existing strings (e.g. "Unknown", "Invalid info", "No update data available", "No available releases found", "Can not determine status", etc), but most of those seem lame/misleading. "Can not determine status" is probably best, but we actually know better.

B) This case would probably never be reached if we commit the ctime patch and fixed the d.o server side problem where we don't always refresh the XML release history files right away (http://drupal.org/node/184418). So, some could (perhaps rightfully) argue that this is unnecessary and therefore bloat/cruft.

C) If we do want to commit this, just to be safe, there's still a // TODO in the patch -- do we want to invalidate the available updates cache when we hit this case, too?

D) If we want commit this, should the extra help text also mention that users should try to "check manually" for available updates again? Currently, update.report.inc runs all this extra help text through a theme('placeholder') (which in turn does the check_plain()) to be extra paranoid/safe, since other modules can fill in the extra help text). If we wanted to include a link in there, we'd have to undo this theme('placeholder') (perhaps via another optional element in the 'extra' nested arrays to override it?).

I'm submitting this as CNR. However, given which of the above questions wins out, the status should be something else:

A) postponed (or code needs work, if we want to reuse an existing string).
B) won't fix.
C) code needs work.
D) code needs work.

So, Gabor/Dries, which of those should this really be, and why? ;)

Thanks,
-Derek