diff options
authorMichał Górny <>2017-09-14 23:14:39 +0200
committerUlrich Müller <>2017-10-09 12:08:51 +0200
commitc6fe2071a2e83be2203196ad7f9459941821a034 (patch)
treed81e1d9898c05917e05203af9803b581dff0d915 /glep-0014.rst
parentglep-0045: Mark Final since GLEP 1 now uses ISO 8601 dates (diff)
Rename all GLEPs to .rst
Diffstat (limited to 'glep-0014.rst')
1 files changed, 138 insertions, 0 deletions
diff --git a/glep-0014.rst b/glep-0014.rst
new file mode 100644
index 0000000..e73742e
--- /dev/null
+++ b/glep-0014.rst
@@ -0,0 +1,138 @@
+GLEP: 14
+Title: security updates based on GLSA
+Version: $Revision$
+Last-Modified: $Date$
+Author: Marius Mauch <>,
+Status: Accepted
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 18 Aug 2003
+Post-History: 22-Aug-2003, 24-Aug-2003, 10-Nov-2003, 25-Oct-2004
+Requires: 21
+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).
+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
+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 (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`_ 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.
+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.
+A prototype implementation (including the update tool, a DTD and a sample
+XMLified GLSA) exists at 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.
+This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
+Unported License. To view a copy of this license, visit