This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
GLEP:14
This GLEP is no longer maintained in the Gentoo Wiki and remains here only as a historical record. Please visit https://www.gentoo.org/glep/glep-0014.html for the current version of this GLEP.
| GLEP 14: security updates based on GLSA | |
|---|---|
| Type | Standards Track |
| Status | Accepted |
| Author | Marius Mauch <genone@genone.de> |
| Editor | |
| Replaces | |
| Replaced by | (none) |
| Requires | GLEP:21 |
| Post History | |
Abstract
There is currently no automatic way to check a Gentoo system for identified security holes or auto-apply security fixes. This GLEP proposes a way to deal with this issue
Status Update
Preliminary implementation glsa-check in gentoolkit, final implementation pending set support in portage (GLEP 21).
Motivation
Automatic checking for security updates is a often requested feature for Gentoo. Implementing it will enable users to fix security holes without reading every security announcement. It's also a feature that is often required in enterprise environments.
Proposed change
Update tool
The coding part of this GLEP is a update tool that reads a GLSA, verifies its GPG signature, checks if the system is affected by it and executes one of the following actions, depending on user preferences:
- run all steps necessary to fix the security hole, including package updates and daemon restarts.
- instruct the user how to fix the security hole.
- print the GLSA so the user can get more information if desired.
Once this tool is implemented and well tested it can be integrated into portage. A prototype implementation for this tool exists.
GLSA format
The GLSA format needs to be specified, I suggest using XML for that to simplify parsing and later extensions. See implementation for a sample DTD. The format has to be compatible with the update tool of course. If necessary a converter tool or an editor could be written for people not comfortable with XML (update: a QT based editor for the GLSA format written by plasmaroo exists in the gentoo-projects repository). Every GLSA has to be GPG signed by the responsible developer, who has to be a member of the security herd.
GLSA release process
Additional to sending the GLSA to the gentoo-announce mailing list it has to be stored on a HTTP/FTP server and in the portage tree. I'd suggest a script should be used to release a GLSA that will:
- check the GLSA for correctness
- sign the GLSA with the developers GPG key
- send a mail to gentoo-announce with the XML GLSA and a plaintext version attached
- upload it to www.gentoo.org/security/en/glsa (via cvs commit)
- put it on the rsync server (via cvs commit)
- notify the moderators on the forums to make an announcement
Portage changes
Until the [[#Update tool|Update tool][ is integrated into portage there will be no code changes to portage. The update tool might require a few new configuration options, these could be placed in make.conf or another config file in /etc/portage.
Rationale
The lack of automated security updates for Gentoo is one of the most often requested features for portage as it is one of the standard features of other distributions. As Gentoo already provides GLSAs for important security bugs it is only natural to use these to implement this feature.
To parse a GLSA in a program the format needs to be specified and a parser has to be written. I suggest the use of XML for future GLSAs for the following reasons:
- can be parsed and validated with existing libraries
- easy to extend while maintaining backwards compatibility
- tools can convert XML GLSAs in other formats, the other direction would be harder
- websites can use XSLT to markup GLSAs
Putting the GLSAs in the portage tree allows all users to check their systems for security updates without taking more actions and simplifies later integration of the update tool into portage. For security minded persons the GLSAs are available on a HTTP server to ease the load of the rsync servers.
To verify the signatures of the GLSAs the public keys of the developers should be available in the portage tree and on the HTTP server. The verification is necessary to prevent exploits by fake GLSAs.
Implementation
A prototype implementation (including the update tool, a DTD and a sample XMLified GLSA) exists at http://gentoo.devel-net.org/glsa/ and in the gentoo-projects/gentoo-security/GLSA repository. This GLEP is based on that implementation, though it can be changed or rewritten if necessary.
Backwards compatibility
The current GLSA release process needs to be replaced with this proposal. It would be nice if old GLSAs would be transformed into XML as well, but that is not a requirement for this GLEP.
Copyright
This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/.