Mail archive

Re: [alpine-devel] Alpine security tracker

From: Quentin Machu <>
Date: Thu, 24 Mar 2016 18:21:25 -0400

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…).

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.

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?


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

I'm not saying that's always the case, but we try do more the actual
work, than the paperwork ;-)

- leo


Received on Thu Mar 24 2016 - 18:21:25 UTC