|
On 02/08/2018 01:32 PM, Matthew Miller
wrote:
This is very useful in my opinion. I know that it's not a consistent policy driven technology, but rather a sort of a kindness extended by consciencious packagers, but it's a great way to correlate specific CVE issues to the update stream. Without it, there's no clear way to find out if the system is vulnerable or not---the software versions aren't necessarily sufficient because of backports, and require manual checking to find out when a fix is being included.This seems like a lot of churn. If we're going to do this, let's go big and get rid of RPM changelogs. When we have a package update, there are basically two different kinds of changelog information. Well, three. [...] Third, though, there's end-user information. [..] *and* it often also covers things like "fixes CVE-####' also carried the specfile changelog. Many environments (corporate, government) actually require keeping track of this stuff, so addressing it would help the acceptance of Fedora and Redhat in such environments rpm -q --changelog mypackage | grep CVE is really useful in such circumstances. Having said that, the informality of the current setup makes it a little haphazard: I know that not all CVEs are being mentioned--and if they are, they don't always mention specific audit information like the BZ entries, software revisions etc. I don't like the idea of a separate file; I'd like to preserve and maybe codify the security fix info in package metadata. If not changelog, then whatevern replaces it should mention the CVEs in a complete and organized way, i.e. the packaging rules should require mentioning CVEs and linking them to problem reports and specific patches that address them.This is neither most helpful for user *nor* ideal for packages. Why don't we drop changelogs entirely in favor of 1) using the dist-git logs for specfile maintainers and 2) providing the end-user information in a different way. This could be through specially formatted log lines going with the commit, or it could be simply in a standard separate file (`fedora.user-visible-changes`). Optionally, it could include both a high level end-user summary, and a detailed description for sysadmins and the curious.
|
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
