Post by Quentin MachuThanks for your open and quick answers.
We already do that in our bug traker: https://bugs.alpinelinux.org/projects/alpine/issues?set_filter=1&status_id=c&tracker_id=1
That’s great! I regret that I wasn’t aware of this yet.
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
checker;
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
tagged.
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.
Post by Quentin Machu- 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.
Post by Quentin MachuAnother 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.
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]: https://github.com/coreos/clair/pull/60#issuecomment-169699188
Best Regards,
Quentin Machu
Date: March 24, 2016 at 5:03:28 PM
Subject: Re: [alpine-devel] Alpine security tracker
Post by Leonardo ArenaHi,
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.
https://bugs.alpinelinux.org/projects/alpine/issues?set_filter=1&status_id=c&tracker_id=1
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] https://security-tracker.debian.org/tracker/CVE-2016-3115
[2] https://bugs.alpinelinux.org/issues/5286
[3] https://bugs.alpinelinux.org/issues/5287
[4] https://bugs.alpinelinux.org/issues/5288
---
Unsubscribe: alpine-devel+***@lists.alpinelinux.org
Help: alpine-devel+***@lists.alpinelinux.org
---