Mail archive

Re: [alpine-devel] Alpine security tracker

From: Isaac Dunham <>
Date: Thu, 24 Mar 2016 21:59:06 -0700

On Thu, Mar 24, 2016 at 06:21:25PM -0400, Quentin Machu wrote:
> Thanks for your open and quick answers.
> From: Leonardo Arena <>
> We already do that in our bug traker: 
> That’s great! I regret that I wasn’t aware of this yet.
> From: Andy Shinn <>
> I wonder if just an additional field or two in Redmine could help 
> satisfy requirements for Clair without adding too much additional 
> overhead. What if Redmine had an additional tracker called Security 
> and a custom CVE field that container the CVE. Would this be too much 
> additional work for users / maintainers entering data when it is 
> related to a CVE? 
> Redmine already provides a way to grab data from the tracker in CSV 
> and XML form. If Clair could filter on a Security tracker to get the 
> CVE and associated packages then this might be a simple addition to 
> start work on the Clair side (assuming this is a valid way of 
> consuming the CVE data). 
> Definitely, parsing properly seems to be the obstacle here. Extracting data from human-written text is unfortunately impracticable. However, Clair could undoubtedly parse Alpine’s Redmine if it would expose data in a fixed format (i.e. static fields available in CSV/XML/YAML/JSON…).

There are links to Atom, CSV, and PDF versions of the tracker data at
the bottom of the page mentioned.
Change 'issues' to 'issues.csv' and you get the CSV version.
However, as you mentioned, there's no CVE field.
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
pkgver/pkgrel fields?

Sometimes (usually? always?), if there are multiple releases affected,
there are separate issues for each release, with the affected release

For example:
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.

> About a vulnerability, Clair usually ingests:
> - Vulnerability name,
> - Severity (e.g. Negligible, Low, Medium, High, Critical),
> - Short description about the vulnerability,
> - Link (e.g. link to Redmine),
> - A list of affected package names, with their fixed version if applicable (otherwise, all versions are considered vulnerable).
> Typically, the affected packages are also namespaced by the operating
> system version. This is useful to keep track of back ports. A specific
> vulnerability affecting a package X could be fixed by 1.44+bp2 in an
> oldstable distribution but fixed by 1.59 in the stable distribution. In
> that case, we would have twice package X in the list, but with two
> different namespaces and versions. I am not familiar with Alpine Linux
> to know if this makes sense here. If it doesn't (i.e. if we can usually
> upgrade any package to the latest versions), then it doesn’t matter, a
> single namespace can be used.

You might have different versions at the same time, yes.
BTW: rather than testing/stable/oldstable, we have 'edge' and multiple
numbered releases.

> Another small concern, that we encounter with Arch Linux support [1], is reliability: it is quite important to be able to determine which data can be trusted. We must avoid consuming data filled by malicious users who would like to manipulate 3rd party applications (such as Clair). This can be mitigated with various solutions though.
> From: Leonardo Arena <>
> we try do more the actual work, than the paperwork ;-) 
> I absolutely agree with you on that point. If making Alpine’s security data a bit more formatted, thus enabling automated systems to collect data in an useful way, represents a tiny/modest amount of work, I believe that it would be an important step forward for everybody in terms of security.
> What do you think?
> [1]:
> Best Regards,
> Quentin Machu
> From: Leonardo Arena <>
> Reply: Leonardo Arena <>
> Date: March 24, 2016 at 5:03:28 PM
> To: Quentin Machu <>
> CC: <>
> Subject:  Re: [alpine-devel] Alpine security tracker
> Il giorno gio, 24/03/2016 alle 21.50 +0100, Leonardo Arena ha scritto:
> > Il giorno gio, 24/03/2016 alle 16.34 -0400, Quentin Machu ha scritto:
> > > Hi,
> > >
> >
> > Hi,
> >
> > >
> > > My name’s Quentin Machu and I am the primary maintainer of Clair [1],
> > > an open source project for the static analysis of vulnerabilities in
> > > containers, by CoreOS. The project, which aim at bringing security
> > > awareness to everyone, recently went 1.0 [2] and is considerably well
> > > received by the community.
> > >
> > >
> > > As Alpine grows more and more popular, especially for containers to
> > > which it becomes a really common base image, I believe that it would
> > > be extremely valuable for Alpine to track vulnerabilities that may
> > > affect its packages.
> >
> > We already do that in our bug traker:
> >
> >
> >
> > > Several Linux distributions, such as Debian [3][4], Ubuntu [5][6],
> > > RHEL [7][8], Arch [9], already do through advisories and parsable
> > > databases.
> > >
> >
> > We don't issue our own advisories if that's what you mean. That would
> > require more man power which I think we prefer to spend on fixing the
> > security issues.
> >
> Just as an example, apparently Debian stable and older are still
> vulnerable to CVE-2016-3115 [1]. We didn't issue an advisory but Alpine
> is no longer vulnerable [2][3], not even its older supported release
> [4].
> I'm not saying that's always the case, but we try do more the actual
> work, than the paperwork ;-)
> - leo
> [1]
> [2]
> [3]
> [4]

Received on Thu Mar 24 2016 - 21:59:06 UTC