From: Richard Freeman <rich0@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] GPG Infrastructure for Gentoo (Was Council Meeting)
Date: Mon, 30 Nov 2009 16:18:21 -0500 [thread overview]
Message-ID: <4B14369D.1040608@gentoo.org> (raw)
In-Reply-To: <20091130113051.GA32489@chopin.edu.pl>
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.
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.
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.
next prev parent reply other threads:[~2009-11-30 21:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-25 21:50 [gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC Denis Dupeyron
2009-11-26 1:34 ` Brian Harring
2009-11-26 1:39 ` Zac Medico
2009-11-26 15:31 ` Ciaran McCreesh
2009-11-26 16:33 ` Brian Harring
2009-11-26 16:46 ` Ciaran McCreesh
2009-11-27 8:08 ` Brian Harring
2009-11-30 11:30 ` Antoni Grzymala
2009-11-30 11:41 ` Antoni Grzymala
2009-11-30 21:18 ` Richard Freeman [this message]
2009-11-30 22:28 ` [gentoo-dev] GPG Infrastructure for Gentoo (Was Council Meeting) Dawid Węgliński
2009-12-01 1:27 ` Robin H. Johnson
2009-12-03 10:32 ` [gentoo-dev] Individual developer signing Torsten Veller
2009-12-03 12:51 ` Thilo Bangert
2009-12-03 20:35 ` Robin H. Johnson
2009-12-11 16:32 ` [gentoo-dev] " Torsten Veller
2009-12-01 1:08 ` [gentoo-dev] Tree Integrity GLEPS for final review and council approval Robin H. Johnson
2009-11-30 17:57 ` [gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC Thomas Sachau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B14369D.1040608@gentoo.org \
--to=rich0@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox