1 |
Hi all, |
2 |
|
3 |
this is a little update about the current progress of GLEP 14 (the |
4 |
portage GLSA integration). |
5 |
A few URLs first (most of the stuff is also somewhere in gentoo cvs): |
6 |
|
7 |
The GLEP itself: |
8 |
http://www.gentoo.org/proj/en/glep/glep-0014.html |
9 |
|
10 |
The proposed new release plan for GLSAs: |
11 |
http://gentoo.devel-net.org/glsa/release-plan |
12 |
|
13 |
The DTD for future GLSAs (once the system is in place): |
14 |
http://gentoo.devel-net.org/glsa/glsa.dtd |
15 |
|
16 |
The userside code (I'm currently updating it and will commit it to cvs |
17 |
this week, still have to figure out a few things): |
18 |
http://gentoo.devel-net.org/glsa/glsa.py and glsa-check.py |
19 |
|
20 |
Also plasmaroo has written a QT based editor which resides in the |
21 |
gentoo-projects repository, and I've written the beginning of the GLSA |
22 |
posting script. |
23 |
|
24 |
|
25 |
If all goes well I think we can enter a first testing stage in 2 or 3 |
26 |
weeks, depend how much time I can donate to this project. If anyone has |
27 |
a problem with the current plans please tell me ASAP so we can try to |
28 |
fix it before the system is going live (so far the feedback has been |
29 |
very positive). |
30 |
Ok, so what still needs to be done before it can go live? |
31 |
|
32 |
- the code has to be finished: mostly minor things as proper error |
33 |
checking, output formatting and stuff like that. I don't expect big |
34 |
problems here. |
35 |
|
36 |
- infrastructure setup: as outlined in the release plan there is not |
37 |
much to do from the infrastructure side, mostly setting up the right |
38 |
directories and permissions. |
39 |
|
40 |
- documentation: this is currently lacking, mostly because the code is |
41 |
still work in progress. While docs are important I think it has to be |
42 |
postponed until testing stage. |
43 |
|
44 |
- portage integration: I think people have very different opinions on |
45 |
this subject, so I'll just present my "vision": |
46 |
I suggest we do a two-phase rollout. In the first phase the complete |
47 |
code will be separate from the core portage code, so no direct |
48 |
integration in emerge. People can use the seperate glsa-check script to |
49 |
use the new system. |
50 |
In the second phase we will integrate the basic functionalities of |
51 |
glsa-check into emerge. Once that step is complete we will have a new |
52 |
"security" package class beside system and world. There are other |
53 |
features we could add like a security upgrade indicator or a security |
54 |
update notification on emerge sync. |
55 |
|
56 |
There were some concerns that the xml base for this project would |
57 |
introduce xml code in portage. That's true to some degree: glsa.py which |
58 |
contains all the backend code for handling the new GLSA format uses the |
59 |
xml.dom.minidom python module for the parsing. So there is an indirect |
60 |
import once we add GLSA support to emerge, but the portage code itself |
61 |
doesn't need any xml code. |
62 |
Also that module is part of the python package, so no additional |
63 |
dependencies are added. This leads to another point. To make the system |
64 |
secure we need gpg for the signature checking. So either we have to add |
65 |
gpg as a (optional) dependency to portage or do some runtime checks, any |
66 |
opinions on that issue? |
67 |
|
68 |
If you have further questions/comments not adressed in this mail please |
69 |
join #gentoo-security on irc.freenode.net and lets discuss it there or |
70 |
reply to this mail on the gentoo-dev list. |
71 |
|
72 |
Marius |
73 |
|
74 |
-- |
75 |
Public Key at http://www.genone.de/info/gpg-key.pub |
76 |
|
77 |
In the beginning, there was nothing. And God said, 'Let there be |
78 |
Light.' And there was still nothing, but you could see a bit better. |