| 1 |
On Sun, Nov 07, 2004 at 08:03:36PM -0500 or thereabouts, Chris Frey wrote: |
| 2 |
> I just downloaded a fresh portage tree to take a look, and I notice |
| 3 |
> that signatures are making their way into the Manifest files. Is this |
| 4 |
> an automated process? If so, can we expect all the Manifest files to |
| 5 |
> soon be signed? |
| 6 |
|
| 7 |
It's largely automated, yes. It still requires the developer committing |
| 8 |
the ebuild to take the time to set up their system appropriately. A doc |
| 9 |
explaining the necessary steps is available here: |
| 10 |
|
| 11 |
http://dev.gentoo.org/~genone/docs/manifest-signing.txt |
| 12 |
|
| 13 |
> Wouldn't it be sufficient to put a Manifest file in the eclass/ directory |
| 14 |
> and sign it as well? |
| 15 |
|
| 16 |
Entirely possible. I'm not a python programmer, so I don't know how |
| 17 |
hard/easy this would be to implement. |
| 18 |
|
| 19 |
> I note you mention this often, and I do appreciate the need for people |
| 20 |
> to join in and help out. The main roadblock to implementing new signing |
| 21 |
> procedures, for the outsider, is that it requires access to the server |
| 22 |
> to implement the signing, or it requires participation from all devs, |
| 23 |
> depending on the method chosen. |
| 24 |
> |
| 25 |
> Given this roadblock, I don't think it is completely fair to lay this job |
| 26 |
> at users' feet. |
| 27 |
|
| 28 |
I'm not laying anything at anyone's feet. What I'm trying to say is that |
| 29 |
the only way this problem will ever get fixed is if someone who cares about |
| 30 |
it devotes the time to fixing it. |
| 31 |
|
| 32 |
> What I'm trying to say is that signing doesn't have to be implemented for |
| 33 |
> the end user in portage before it is implemented on the server. Once the |
| 34 |
> signatures are available on the server, all this talk would go away, and |
| 35 |
> those that are concerned would do the checks, and those that aren't |
| 36 |
> wouldn't. The concerned would likely share their checking scripts as well. |
| 37 |
|
| 38 |
Back when signing was first being discussed, a conscious decision was made |
| 39 |
to avoid server-based signing, specifically because it was felt that |
| 40 |
offered a false sense of security. It didn't ensure integrity between the |
| 41 |
developer's machine and the master cvs repository. Per-dev signing, on the |
| 42 |
other hand, did. |
| 43 |
|
| 44 |
Thus, the current signing model in portage requires each dev to sign their |
| 45 |
own stuff and I don't think veering away from that strategy simply to |
| 46 |
implement something in a hurry is a very wise choice. |
| 47 |
|
| 48 |
Also, signing things on the server isn't as easy as folks have made it out |
| 49 |
to be. A simple cron'd find command isn't going to cut it. Every time a |
| 50 |
dev commits something to CVS, a new signature for that file has to be |
| 51 |
generated immediately. Otherwise, 30 minutes later, you're going to have |
| 52 |
problems when those changes make their way out to the rsync tree. Thus, |
| 53 |
it's going to have to be integrated into repoman which means changes to |
| 54 |
portage. |
| 55 |
|
| 56 |
> So, I'm quite happy that there are experimental features in portage that |
| 57 |
> deal with this, but I'd be even happier if every Manifest file in the |
| 58 |
> portage tree was signed, even if portage code didn't do the checks yet. |
| 59 |
|
| 60 |
Signing of ebuilds is coming. The foundation is being laid and, once that |
| 61 |
is stabilized, the push to get all devs to sign their ebuilds will |
| 62 |
commence. |
| 63 |
|
| 64 |
--kurt |
Archives