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