Hello,

I already discussed this point with some of the team on IRC and the 
conclusion has been to take it up the list.

Every major distribution includes a "changelog" option in their package 
manager. This makes things very easy to list all the CVEs affecting your 
network.

For example "yum --changelog update" outputs something like that for 
each package:

ChangeLog for: libxml2-2.9.1-6.el7_2.3.x86_64
* Mon Jun  6 14:00:00 2016 Daniel Veillard <veillard@redhat.com> - 
libxml2-2.9.1-6.3
- Heap-based buffer overread in xmlNextChar (CVE-2016-1762)
- Bug 763071: Heap-buffer-overflow in xmlStrncat 
<https://bugzilla.gnome.org/show_bug.cgi?id=763071> (CVE-2016-1834)
- Bug 757711: Heap-buffer-overflow in xmlFAParsePosCharGroup 
<https://bugzilla.gnome.org/show_bug.cgi?id=757711> (CVE-2016-1840)
- Bug 758588: Heap-based buffer overread in 
xmlParserPrintFileContextInternal 
<https://bugzilla.gnome.org/show_bug.cgi?id=758588> (CVE-2016-1838)
- Bug 758605: Heap-based buffer overread in xmlDictAddString 
<https://bugzilla.gnome.org/show_bug.cgi?id=758605> (CVE-2016-1839)
- Bug 759398: Heap use-after-free in xmlDictComputeFastKey 
<https://bugzilla.gnome.org/show_bug.cgi?id=759398> (CVE-2016-1836)
- Fix inappropriate fetch of entities content (CVE-2016-4449)
- Heap use-after-free in htmlParsePubidLiteral and htmlParseSystemiteral 
(CVE-2016-1837)
- Heap use-after-free in xmlSAX2AttributeNs (CVE-2016-1835)
- Heap-based buffer-underreads due to xmlParseName (CVE-2016-4447)
- Heap-based buffer overread in htmlCurrentChar (CVE-2016-1833)
- Add missing increments of recursion depth counter to XML parser. 
(CVE-2016-3705)
- Avoid building recursive entities (CVE-2016-3627)
- Fix some format string warnings with possible format string 
vulnerability (CVE-2016-4448)
- More format string warnings with possible format string vulnerability 
(CVE-2016-4448)

As you can see, it's then fairly easy to parse the output to get a list 
of the CVEs.

I'd love to see an "apk upgrade -s --changelog" option that would mimic 
this behaviour. Ideally only the changelog between installed version and 
available update should be displayed

The questions are:
   - How to do it?
   - How to get the needed informations?


Cheers,
-O.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Hi,

On Thu, 03 Nov 2016 10:45:27 +0100
Olivier Mauras <olivier@mauras.ch> wrote:

> I already discussed this point with some of the team on IRC and the 
> conclusion has been to take it up the list.
> 
> Every major distribution includes a "changelog" option in their
> package manager. This makes things very easy to list all the CVEs
> affecting your network.
> [snip]
> 
> As you can see, it's then fairly easy to parse the output to get a
> list of the CVEs.

I think ncopa was working on a CVE feed / database. The idea is to
provide a tool that tells which CVEs are affecting you and are fixed in
newer versions. Maybe he can elaborate that.

Would this be sufficient for you?

> I'd love to see an "apk upgrade -s --changelog" option that would
> mimic this behaviour. Ideally only the changelog between installed
> version and available update should be displayed
> 
> The questions are:
>    - How to do it?

I'm planning to work on new apk-tools. I can add this to design
requirements on the apk side.

>    - How to get the needed informations?

The CVE data should be generatable already. Full changelog is not kept,
but could probably be parsed from the git. But I think this is two
features: changelog and CVE. The CVE output could be machine parseable,
whereas the changelogs are more for human eyes.

This also raises question, how to store the information if we want full
listing between versions. Should we keep some of it in a database for
removed versions? Should each package contain cumulative listing?

I don't really like bloating the packages with cumulative data - or
even the package index. So this should probably go in a separate db.

Another dark area is when switching stable branches. How to calculate
change log then, because the git history is not linear.

I wonder if other developers have other questions/ideas.

/Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---