| Summary: | RFE: Retain bugzilla/cve/etc information for future review. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Joel Davis <jodavis> |
| Component: | gnome-packagekit | Assignee: | Richard Hughes <richard> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | ffesti, james.antill, maxamillion, mclasen, pmatilai, rhughes, richard, rvokal, tla |
| Target Milestone: | --- | Flags: | james.antill:
needinfo?
(notting) |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-05-28 20:29:25 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Joel Davis
2011-04-20 22:25:49 UTC
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. |
