| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On Thursday 25 March 2004 12:26, Chris Bainbridge wrote: |
| 5 |
> You need to be in the ACL at /usr/portage/pkg-parent-dir to create the |
| 6 |
> new package. To update an ACL, the new ACL has to be signed by people |
| 7 |
> in the old ACL. |
| 8 |
|
| 9 |
What if the old ACL on the system is so old that the people signing the |
| 10 |
new ACL were not in the old ACL. I don't think forward signing is a good |
| 11 |
(or secure idea). The parent dir system would require all devs to be in |
| 12 |
the /usr/portage ACL anyway so still complicating things. |
| 13 |
|
| 14 |
> > - - How do you propose all those ACL's get created. Especially as we |
| 15 |
> > don't want to limit who may commit where. In some cases it is |
| 16 |
> > actually essential that certain parties (managers) perform fast |
| 17 |
> > commits on a package they are not normally involved with. |
| 18 |
> |
| 19 |
> This is a management issue. Decide who is responsible for different |
| 20 |
> parts of the tree. If you allow everyone to commit anywhere then you |
| 21 |
> are heading for trouble - would you give someone you only know through |
| 22 |
> irc root access to your pc? Thats effectively what you're doing. Every |
| 23 |
> new developer adds a new point of compromise; there have to be some |
| 24 |
> restrictions. |
| 25 |
|
| 26 |
If we implement such restrictions (which are usefull, however not the |
| 27 |
point of the current discussion) those restrictions would not be |
| 28 |
category based. They would probably be herd based and crosscut |
| 29 |
categories. Categories are only to indicate to USERS what a package is |
| 30 |
about. |
| 31 |
|
| 32 |
> > The current IMPLEMENTED system is even less work for developers. An |
| 33 |
> > update just requires signing the manifest. This is done |
| 34 |
> > automatically by repoman so it just means one needs to enter his |
| 35 |
> > passphrase (or use gpg-agent) |
| 36 |
> |
| 37 |
> Same here, everything can be automated with scripts. |
| 38 |
|
| 39 |
That still need to be written. One also needs to maintain ACL's. Further |
| 40 |
this proposal tries to accomplish two separate goals. It not only gives |
| 41 |
signing, it also enforces restricted access to packages. While we will |
| 42 |
probably sometime in the future enforce some kind of ACL's we are not |
| 43 |
ready to do so at the current point. |
| 44 |
|
| 45 |
We want to be able to implement ebuild signing fast (mainly to combat |
| 46 |
rsync mirror compromise). Changing procedures beyond what is absolutely |
| 47 |
necessary (entering your passphrase) would be a big impediment to doing |
| 48 |
so. |
| 49 |
|
| 50 |
If you want to hold the ACL discussion you can do so, but be advised that |
| 51 |
a similar discussion took place about a month ago, and do it outside the |
| 52 |
ebuild signing discussion. It are separate issues and need to be |
| 53 |
discussed separately. |
| 54 |
|
| 55 |
> > This approach still relies on minimum signatures being bigger than |
| 56 |
> > 1. While that would work for ACL's this will currently not work for |
| 57 |
> > manifests. It would put alternative architectures to a grinding halt |
| 58 |
> > and seriously limit the possibilities of the x86 development. |
| 59 |
> |
| 60 |
> Unpopular packages may only require one signature, but surely |
| 61 |
> something that would compromise every user (like glibc) should require |
| 62 |
> multiple signatures? If you really need it add a FEATURES flag to |
| 63 |
> ignore signatures. Obviously normal users should never set it. I'm not |
| 64 |
> sure why you think it wouldn't work for manifests; its just a file. |
| 65 |
|
| 66 |
The problem is that a manifest changes for any change in ebuilds or |
| 67 |
patches. That means that for adding a keyword to a package one needs to |
| 68 |
resign the manifest. |
| 69 |
|
| 70 |
Also multiple signatures can be easilly implemented once single |
| 71 |
signatures are in place. A straightforward approach would be to create a |
| 72 |
signed list of "main" packages which must have double signatures, |
| 73 |
however we want to implement basic signing with some speed. While it is |
| 74 |
probably too late for 2004.1 we want it there for 2004.2 |
| 75 |
|
| 76 |
> > ps. Based on one public key on a single trusted source (A CD), how |
| 77 |
> > do you ensure that the whole tree is uncompromised. |
| 78 |
> |
| 79 |
> You can't. Its an old tree which has already been signed. Trust it, or |
| 80 |
> update to a new tree. |
| 81 |
|
| 82 |
As it is possible to have an approach that does offer such security, this |
| 83 |
solution is inferior. |
| 84 |
|
| 85 |
> > pps. How do you ensure that at a compromise of a key / or a rogue |
| 86 |
> > developer this key is invalidated even when revocation is not |
| 87 |
> > possible (like with a rogue developer) |
| 88 |
> |
| 89 |
> Remove the key from the ACL. |
| 90 |
|
| 91 |
Ok, how do you ensure that the ACL is updated? From what I understand it |
| 92 |
would be easy to prevent the ACL from being updated just by generating |
| 93 |
an invalid ACL. |
| 94 |
|
| 95 |
Paul |
| 96 |
|
| 97 |
- -- |
| 98 |
Paul de Vrieze |
| 99 |
Gentoo Developer |
| 100 |
Mail: pauldv@g.o |
| 101 |
Homepage: http://www.devrieze.net |
| 102 |
-----BEGIN PGP SIGNATURE----- |
| 103 |
Version: GnuPG v1.2.4 (GNU/Linux) |
| 104 |
|
| 105 |
iD8DBQFAYs0YbKx5DBjWFdsRAtWaAKCCrOyavEbmTeMKcpFUtjjtbxUVlQCgvvZS |
| 106 |
VbfZzN0AVJEuaQPe3B+tVRk= |
| 107 |
=KM7a |
| 108 |
-----END PGP SIGNATURE----- |
| 109 |
|
| 110 |
-- |
| 111 |
gentoo-dev@g.o mailing list |
Archives