[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Gentoo Security Project Summary -- was Re: [gentoo-dev] Project summaries
From:       Robert Buchholz <rbu () gentoo ! org>
Date:       2009-05-25 21:20:17
Message-ID: 200905252320.23130.rbu () gentoo ! org
[Download RAW message or body]


Gentoo Security Project Summary

Short Summary:
The Security Team is up and running, but we are dealing with numerous
tasks and a high load in daily maintenance. Fresh blood is not only
appreciated, but needed to continue the luxury of Security Support we
currently have. We have too many open bugs, too many undrafted GLSAs
that are eventually sent too slow, and a lot of channels to monitor.
There are some bugs that need extensive amount of work to be resolved.
The Security Team is also developing applications to support our
workflow and user's systems, such as improvements to glsa-check and our
DTD, a new Ruby on Rails application to draft GLSAs and an application
to coordinate Kernel security support and check local systems.

== Personal changes ==

=== Lead Election ===

Since the last election had been longer than a year ago, we held a new
election during the first two weeks of May. It was determined
unanimously that Pierre-Yves Rofes (py) and Robert Buchholz (rbu) will
be the new French-German duo that is our Team Leads. We would like to
publicly thank Raphael Marichez (falco) and Matthias Geerdsen (vorlon)
for doing the job the years past. They were both not available for
another term.

=== Additions to the team ===

Alex Legler (a3li) recently joined the Security Team. However we still
need more people helping with the daily maintenance work. This call for
help applies to both developers and users.

For more details on how to join the Security team, see:
http://www.gentoo.org/proj/en/security/

Or, more specifically:
http://www.gentoo.org/security/en/padawans.xml
http://www.gentoo.org/security/en/coordinator_guide.xml
http://www.gentoo.org/security/en/vulnerability-policy.xml
http://www.gentoo.org/security/en/bug-searching.xml

== Maintenance ==

=== Bugs and GLSAs ===

We have reached new highs in the number of open bugs and the length it
takes all of us to resolve them. A shortness in Gentoo developers in
general and on our team is leading to three issues:

(1) Security bugs are not resolved by ebuild maintainers

Some security bumps are staying open for weeks with teams not responding
to pings. Even issues that could be resolved before being public (what
we call "embargoed bugs") are not resolved due to maintainers not being
responsive on such bugs.
In fairness, I have to note this is limited to only some herds and not
architectures. Architectures and in particular their Arch Security
Liaisons are doing their job in a reliable and timely fashion.

(2) GLSAs are delayed

We're slow! We are sorry. I feel this is a great disappointment
especially in those cases where maintainers and arch teams are doing a
fast job and we take 4 weeks to write the accompanying GLSA. I see
potential for improvement with the GLSAMaker rewrite described below.
Contributors to GLSA writing are greatly welcome.

(3) Security Team is not resolving bugs either

In the past, we have been conducting simple version bumps ourselves or
have masked vulnerable ebuilds. Currently, doing other people's jobs in
the security process is mostly on hold as we have a hard time struggling
to cope with our part of the job.


=== Documentation update ===

We actually updated our existing documentation to reflect more of our
security process. Isn't that awesome? Read our project pages to find out
more:
http://www.gentoo.org/proj/en/security/


=== GLSA dtd and glsa-check ===

We have been discussing changes to the GLSA DTD for ages now. There's
few people interested in the subject and I have been slacking on it. I
have picked up glsa-check maintenance recently and we will announce
changes to the DTD to the dev lists as soon as they are fully drafted.
Since the GLSA format is supported in all package managers, the change
will be announced at least 6 weeks before going live.

Oh, and glsa-check will see some bugs fixed, I hope. And support for
UTF-8. And support for mask-glsas. Hmm.. anyone else here to help?

glsa-check changes in 0.2.4:
http://sources.gentoo.org/viewcvs.py/gentoolkit/branches/gentoolkit-0.2.4/src/glsa-check/
glsa-check changes in trunk (0.3):
http://sources.gentoo.org/viewcvs.py/gentoolkit/trunk/gentoolkit/
New DTD proposals:
http://git.goodpoint.de/?p=glsa-check.git;a=tree;h=refs/heads/glsa-2


== Feature extensions ==

=== GLSAMaker ===

The GLSAMaker is a web application that we use to draft, comment on and
refine GLSAs. It allows for the export of the GLSA texts and XML files
you might know from gentoo-announce or /usr/portage/metadata/glsa. The
application is considered helpful by all of us, however its shortcomings
require to duplicate some work that could be automated and its usability
makes working with it less fun than it could be and slows our work down
quite a bit.

Alex Legler (a3li) and Pierre-Yves Rofes (p-y) are currently working on
a rewrite that covers the current functionality and extensions to ease
the workflow dramatically by integrating metadata from Portage,
Bugzilla, the CVE database and Secunia.

We are looking forward to GLSAMaker 2 becoming the central point for
coordinating our efforts.

A refined access control will allow us to give access to the tool to
people that are not (yet) members of the team, and this allows us to
accept contributions from the community and other developers that want
to push GLSAs for their packages through our system faster.

If you are into Ruby On Rails development, or are looking for a project
to start, your help is greatly appreciated.
You can follow development here:
http://git.overlays.gentoo.org/gitweb/?p=proj/glsamaker.git
https://redmine.stingray.a3li.info/projects/show/glsamaker2


=== Kernel Security ===

Since 2005, we are not issueing GLSAs for Kernel vulnerabilities which
is an unfortunate flaw in our Vulnerability Policy. This is related to
the fact that these vulnerabilities are extremely hard to track and we
have a lot of Kernel sources with several maintainers. Unlike other
projects, the Kernel is actively maintained upstream and by bumping to
newer versions you will fix vulnerabilities automatically. This way, our
ebuilds are staying secure even without GLSAs. You machines, however,
may not.

However, we are looking to improve the process of handling these issues
as well. We are currently tracking all known bugs in Bugzilla, building
a large database of Kernel vulnerabilities -- most of which are fixed in
gentoo-sources. At the same time we are working on a tool to export this
data into a format that could be distributed as part of the Portage
tree. A tool will then allow checking of the locally running kernel
version against the vulnerability data to determine which updates are
required.

This work is conducted by Björn Tropf (asyme) and Robert Buchholz (rbu).
The part concerning the Portage tree will be proposed to this list at a
later time when we have a working module to collect and evaluate the
data.

Follow our work here:
http://git.overlays.gentoo.org/gitweb/?p=proj/kernel-check.git

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]