Hide Forgot
Description of problem: Currently GPK shows you information about the CVE's etc that are related to an update. I think it would be helpful to hold onto this information in a graphical tools so that you can see if any packages associated with a particular bugzilla or whatever so you can see if a given issue was relevant for your system. Base installs could probably include CVE/bugzillas issues resolved during the update process of the last cycle (for example if the problem presented in a F14 version of the package but you're in F15) which is helpful if you're concerned with whether or not an issue still exists in F15 but you didn't/can't test the latest F14 system. I'd try to create at least a proof of concept, but I'm completely unfamiliar with the underlying system. Hopefully that's not too wish-fulfillment, - Joel
Perhaps some combination of the yum history and yumdb could be exported to do this?
There's no need to save it anywhere, the BZ/CVE/etc. information is always there via. updateinfo. So Eg. on F13 I can do: % sudo yum updateinfo list security all perl-suidperl Loaded plugins: PT, aliases, auto-update-debuginfo, keys, noop, ps, security, : tmprepo, updater, verify, versionlock i FEDORA-2010-11323 security perl-suidperl-5.10.1-116.fc13.x86_64 FEDORA-2011-4918 security perl-suidperl-4:5.10.1-123.fc13.x86_64 updateinfo list done ...which says that both the above security errata applied to my system, and the first one is installed. I don't think there's a specific cmd line view that matches what the OP wanted (unless "updateino info security all" is good), but the information is there.
What would the UI look like?
Actually, re: comment #2 - if this is only querying the current update info, that means I can't see if a particular CVE on my F-15 system was fixed by an update back when it was running F-14, correct?
Could the "CVE Digest" (so to speak) be incorporated in the yumdb of fedora-release? The GUI version might just query current updates and then fall back to fedora-release to see if the CVE was resolved in a previous version cycle. If they're looking for something older than a cycle and a half they probably should be looking at the bugzilla. BTW, it appears that sloppy editing and/or minor stroke mucked up the first comment, sorry about that.
as far as the UI I had in mind, I pictured just a simple query box with a list of results an the information listed on the right sort of like: http://www.linuxscrew.com/wp-content/uploads/2007/11/gnochm-large.png Without the menu obviously.
Re: comment #4 ... well there's --releasever ... and it seems dubious how much you want to know about what happened on F14, when you've moved to F15 (it's slightly different when you've on pre-F15, maybe -- but then a good summary might be "your system is slightly buggy" :). Do you have any stats. on how often a particular errata is updated, and with what? As I guess if they tend to not get changed etc. ... there's little harm in storing them for installed packages (or maybe even storing bzs/cves in the history).
I know you weren't replying to me, but my thinking with incorporating F14 CVE's/bugs in F15 was to have local visibility as to whether an issue affects the current system. If a CVE comes out and is addressed towards the end of F14, I don't think you should lose visibility of that. Obviously issues that came out release before previous are old enough for people to logically deduce that the CVE isn't an issue for them.
We're not adding new features to gpk-update-viewer at this point.