On 02/08/2018 01:32 PM, Matthew Miller wrote:

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.

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.

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.


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.

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.