On Sun, Nov 07, 2004 at 11:26:55PM +0000, Kurt Lieber wrote:
> If you believe this happens for even 20% of the packages in our tree,
> you're mistaken.  Most devs look at changelogs.  Few devs look at code
> diffs.  Note I did not say "Gentoo devs".

I hope they at least check the signatures of the packages that have them
available.

This would be an interesting poll question, if we could get a number
of devs to participate (and not just Gentoo devs). :-)

I know I look at code diffs for packages that matter to me, and have done
code audits of certain software I rely on for security.  I do realize that
there is the ever-present time constraints, but part of the advantage
of having multiple maintainers for a distro is that this kind of work
can be spread around.

> Signed ebuilds in portage is something that is already implemented
> and supported as an experimental feature as of 2.0.51:
> 
> http://www.gentoo.org/news/20041021-portage51.xml

Given this release is only 2.5 weeks old, I hope you'll pardon my not
knowing this.  :-)  I'm quite pleased to see that this has reached the
experimental stage.

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?

> The original poster was talking about the inability to verify *eclasses*,
> not ebuilds.  eclasses are an important part of portage from a features and
> functionality perspective, but they make up a small fraction of the overall
> tree in terms of sheer number of files.  My point was and still is that
> investing the time and effort to also sign these files isn't worth it given
> the myriad of other larger holes that already exist further upstream.

Wouldn't it be sufficient to put a Manifest file in the eclass/ directory
and sign it as well?

> Or, to leverage one of the primary tenets of FOSS -- if there are folks on
> the list who truly believe this is a hole that should be fixed, provide
> patches to portage to add this functionality.  It already supports signing
> to some degree -- one could reasonably assume that adding support for
> signing of eclasses is relatively easy for a competent python programmer.

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.

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.

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.

- Chris


--
gentoo-security@g.o mailing list