From: Isaac Dunham <ibid.ag_at_gmail.com>
There's also no associated package version.
However, it's theoretically possible to retrieve the package version in
an automated manner:
each issue has an associated git revision, and the diff will include a
change to the APKBUILD touching at least one of the two version numbers:
pkgver and pkgrel.
This is obviously going to be rather cumbersome to retrieve from a CVE
is there a way to hook into Redmine so it automatically parses this to add
From what I saw, the descriptions usually mention the packages and their fixed versions (if any) . Could we simply create fields to store them instead of writing them in the description? So we could easily parse them using any of the Redmine's export format (XML, …)?
Sometimes, I am confused though because multiple different fixed versions are listed, for the same Alpine Linux release .
Sometimes (usually? always?), if there are multiple releases affected,
there are separate issues for each release, with the affected release
5288,Alpine Linux,Bug,Closed,Normal,[3.0] openssh: missing sanitisation of input for X11 forwarding (CVE-2016-3115),Natanael Copa,03/23/2016 10:48 AM
5287,Alpine Linux,Bug,Closed,Normal,[3.1] openssh: missing sanitisation of input for X11 forwarding (CVE-2016-3115),Natanael Copa,03/23/2016 10:48 AM
5286,Alpine Linux,Bug,Closed,Normal,[3.2] openssh: missing sanitisation of input for X11 forwarding (CVE-2016-3115),Natanael Copa,03/23/2016 10:48 AM
If a bug is filed against the current release only, it will not be tagged.
This is pretty great, with that information and the package names/versions as discussed above, we basically have the hard part figured out. The rest is rest vulnerability name, severity, description as mentioned in my previous e-mail. Except for the severity, the CVE names and descriptions are also present either in the title and/or in the description. It probably just needs a more stable format to be parsable, I am not sure how it could be achieved with Redmine though.
You might have different versions at the same time, yes.
BTW: rather than testing/stable/oldstable, we have 'edge' and multiple
Sure, that makes a lot of sense. That’s how Clair do it with other distributions, it uses numbered versions and then “unstable” (or “edge” in Alpine's case). I just wanted to simplify.
To summarize a bit, Clair (or any automated system with similar purposes) has to be able to parse something like that at the end of the day:
- bind9 (fixed by 9.10)
- dnsmasq (unfixed)
- bind9 (fixed by 9.15)
- dnsmasq (fixed by 9.40)
- skydns (unfixed)
Received on Fri Mar 25 2016 - 16:35:05 GMT