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
Description: This is a digitally signed message part.
