1 |
Today, John informed me that we will still have an insecure implementation |
2 |
of Portage in 2004.1 due to a lack of effort and commitment towards solving |
3 |
this problem. |
4 |
|
5 |
We have been talking about GPG-signed packages in portage for almost |
6 |
exactly one year now.[1] Yet, we have not delivered on our promises to our |
7 |
user base. Just today, we had a user ask how she can verify the integrity |
8 |
of packages she downloads.[2] I can't give her any good answer because the |
9 |
answer is she can't. |
10 |
|
11 |
Looking at the roadmap for portage, I was horrified to discover it's not |
12 |
even listed on that page.[3] Have we all forgotten that we had an rsync |
13 |
server compromised just a few months ago?[4] |
14 |
|
15 |
Daniel, Pieter -- you are both listed as the TLP managers for Portage. Can |
16 |
you please articulate if/how/when you plan to implement GPG signing in |
17 |
Portage? |
18 |
|
19 |
--kurt |
20 |
|
21 |
[1] http://www.gentoo.org/news/en/gwn/20030407-newsletter.xml#doc_chap1_sect3 |
22 |
http://www.gentoo.org/news/en/gwn/20030421-newsletter.xml#doc_chap1_sect2 |
23 |
[2] http://marc.theaimsgroup.com/?l=gentoo-security&m=108003431908752&w=2 |
24 |
[3] http://www.gentoo.org/proj/en/portage/ |
25 |
[4] http://www.gentoo.org/news/en/gwn/20031208-newsletter.xml#doc_chap1_sec3 |
26 |
|
27 |
----- Forwarded message from John Davis <zhen@g.o> ----- |
28 |
|
29 |
- GPG signed ebuilds: I'm not directly working on it but I'm indirectly |
30 |
involved, and this is most likely not production ready for 2004.1. |
31 |
The main outstanding issues: we still don't have a key policy (where |
32 |
should we store the keys, how do we ensure they are trustworthy) and |
33 |
signing of auxiliary files (eclasses and other non-package dirs). These |
34 |
issues have to be solved before we can a) implement the verification |
35 |
code and b) make signing the default behavior in repoman (it's |
36 |
implemented but disabled by default). |
37 |
And if repoman signs packages you still have to re-commit or update a |
38 |
package before it is signed, so this will also take a lot of time before |
39 |
the majority of the tree is signed (unless we do mass-commits). |
40 |
So while the feature itself might be completed for 2004.1 (or more |
41 |
likely 2004.2) I wouldn't announce it until the majority of our packages |
42 |
are signed. |
43 |
|
44 |
------------------------------------------------------------------ |