Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   GPG Infrastructure for Gentoo (Was Council Meeting) (http://www.linux-archive.org/gentoo-development/288414-gpg-infrastructure-gentoo-council-meeting.html)

Dawid Węgliński 11-30-2009 09:28 PM

GPG Infrastructure for Gentoo (Was Council Meeting)
 
On Monday 30 November 2009 22:18:21 Richard Freeman wrote:
> Antoni Grzymala wrote:
> > How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort
> > a year ago to summarize the then-current state of things regarding tree
> > and package signing, however the matter seems to have lain idle and
> > untouched for more than a year since.
>
> One concern I have with the GLEP-57 is that it is a bit hazy on some of
> the implementation details, and the current implementation has some
> weaknesses.
>
> I go ahead and sign my commits. However, when I do this I'm signing the
> WHOLE manifest. So, if I stabilize foo-1.23-r5 on my arch, at best I've
> tested that one particular version of that package works fine for me.
> My signature applies to ALL versions of the package even though I
> haven't tested those.
>

I may be wrong - then please correct me. You don't sign every package versions
but Manifest. Thus you somehow prove every file checksum is correct. If there
were any changes made on server side, those checksums would be incorrect
according to your signed Manifest. Currently any change may be fixed by whoever
it is by the same command ebuild foo digest.

> Now, if we had an unbroken chain of custody then that wouldn't be a
> problem. However, repoman commit doesn't enforce this and the manifest
> file doesn't really contain any indication of what packages are assured
> to what level of confidence.

That's what should be discussed - forcing developers to sign their commits and
implementing this support in package managers.

>
> If we want to sign manifests then the only way I see it actually
> providing real security benefits is if either:
>
> 1. The distro does this in the background in some way in a secure
> manner (ensuring it happens 100% of the time).
>
> 2. Every developer signs everything 100% of the time (make it a QA
> check).
>
> The instant you have a break in the signature chain you can potentially
> have a modification. If somebody cares enough to check signatures, then
> they're going to care that the signature means something. Otherwise it
> only protects against accidental modifications, and the hashes already
> provide pretty good protection against this.
>

That's not really true. I see tips like "if you have digest incorrect, run
ebuild foo.ebuild digest" very often. Really small group of people care about
broken digests. :(

--
Cheers
Dawid Węgliński

"Robin H. Johnson" 12-01-2009 12:27 AM

GPG Infrastructure for Gentoo (Was Council Meeting)
 
On Mon, Nov 30, 2009 at 04:18:21PM -0500, Richard Freeman wrote:
> Antoni Grzymala wrote:
> >How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort
> >a year ago to summarize the then-current state of things regarding tree
> >and package signing, however the matter seems to have lain idle and
> >untouched for more than a year since.
> One concern I have with the GLEP-57 is that it is a bit hazy on some
> of the implementation details, and the current implementation has
> some weaknesses.
GLEP57 is purely informational.

The GLEP on Individual developer signing has not made it into a Draft
yet.

But you can view the very brief version here:
http://sources.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/02-developer-process-security?view=markup

> I go ahead and sign my commits. However, when I do this I'm signing
> the WHOLE manifest. So, if I stabilize foo-1.23-r5 on my arch, at
> best I've tested that one particular version of that package works
> fine for me. My signature applies to ALL versions of the package
> even though I haven't tested those.
This was covered in the draft linked above.
A larger discussion on it is welcome, as while both competing options
exist, neither has a clear advantage over the other.

> Now, if we had an unbroken chain of custody then that wouldn't be a
> problem. However, repoman commit doesn't enforce this and the
> manifest file doesn't really contain any indication of what packages
> are assured to what level of confidence.
Chain of custody from infrastructure to user is covered in GLEP58
(MetaManifest).

> If we want to sign manifests then the only way I see it actually
> providing real security benefits is if either:
>
> 1. The distro does this in the background in some way in a secure
> manner (ensuring it happens 100% of the time).
See GLEP58.

> 2. Every developer signs everything 100% of the time (make it a QA
> check).
+1 on this.

> The instant you have a break in the signature chain you can
> potentially have a modification. If somebody cares enough to check
> signatures, then they're going to care that the signature means
> something. Otherwise it only protects against accidental
> modifications, and the hashes already provide pretty good protection
> against this.
GLEP60 covers the Manifest2 filetypes and better logic on which
missing/mismatches should be considered as fatal.

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85


All times are GMT. The time now is 01:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.