From: ludo@gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org
Subject: Re: Checking signatures on source tarballs
Date: Sun, 11 Oct 2015 19:44:14 +0200 [thread overview]
Message-ID: <87mvvp1es1.fsf@gnu.org> (raw)
In-Reply-To: <871td28xm3.fsf@netris.org> (Mark H. Weaver's message of "Sat, 10 Oct 2015 13:03:16 -0400")
Mark H Weaver <mhw@netris.org> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> What you suggest would be perfect but, if I understand it correctly,
>> it’s far from reality.
>
> What exactly is far from reality? I did not speak about what _is_, but
> rather about what we _should_ do to improve things.
Sorry, that was poorly worded. What I meant to say is that the
practices of upstream developers are on average far more “sloppy” than
we, as downstream, would end up setting up.
A particular problem I see, is that we would end up maintaining a list
of authorized fingerprints when 90% of upstream developers do not
actually provide that information.
This is not to say we shouldn’t try. Rather, what I’m saying is that we
should make sure we don’t over-engineer a solution whose benefits would,
in effect, be significantly limited by what upstream actually does.
[...]
> It seems to me that you're rejecting this proposal because you see that
> it's not yet practical to do the job perfectly.
I’m not rejecting the proposal. My main concern is the implementation
of the proposal; I think it’s easy to over-engineer it, or end up with
something that doesn’t scale, or provides wrong assurance.
> In my view, it is enough that it would be a significant improvement
> over what we have now. In my first message in this thread, I listed
> the following benefits:
>
> I wrote:
>> * If the packager downloaded a key belonging to a man-in-the-middle
>> (quite possible given that we rarely have a validated chain of trust
>> to the developer), then that bad key will be stored in our git repo
>> for all to see, allowing someone to notice that it's the wrong key.
I agree that’s an improvement, because it provides an audit trail.
In practice it may still be hard to determine whether this is the
“wrong” key, because only upstream can tell.
>> * When the package is later updated, it will not be possible for a new
>> man-in-the-middle attack to be made on us. If a new signing key is
>> used, we cannot fail to notice it. It will raise a red flag and we
>> can investigate.
Agreed.
>> * It would strongly encourage packagers to do these checks, and make it
>> obvious to reviewers or users when the packager failed to do so. It
>> would also make it easy to find unsigned packages, so that we can
>> encourage upstream to start signing the packages, at least for the
>> most important ones.
Agreed.
> Do you disagree that my proposal would have these benefits?
No!
So, how do we do this? :-)
Something like
<http://git.savannah.gnu.org/cgit/guix.git/tree/TODO?id=3476ded934dc0beab1801d7fcdcc37b5c17bbf01#n52>,
where the signature fields are optional?
Do we force signature checks as part of the derivation builds, or do we
make it off-line (say, in ‘guix lint’), or both?
How do we handle projects that maintain a list of authorized public
keys, like GNU, Tor, and kernel.org?
Thanks,
Ludo’.
next prev parent reply other threads:[~2015-10-11 17:44 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-02 13:04 emacs: devel: Add lint/download commands Alex Kost
2015-10-02 13:04 ` [PATCH 1/4] emacs: Add 'guix-devel-with-definition' Alex Kost
2015-10-03 20:31 ` Ludovic Courtès
2015-10-02 13:04 ` [PATCH 2/4] emacs: Add 'guix-devel-download-package-source' Alex Kost
2015-10-03 20:35 ` Ludovic Courtès
2015-10-04 13:39 ` Alex Kost
2015-10-04 16:57 ` Ludovic Courtès
2015-10-04 18:28 ` Alex Kost
2015-10-05 15:55 ` Ludovic Courtès
2015-10-06 15:11 ` Alex Kost
2015-10-07 2:07 ` Checking signatures on source tarballs Mark H Weaver
2015-10-07 3:18 ` Christopher Allan Webber
2015-10-07 8:29 ` Andreas Enge
2015-10-07 12:06 ` Ludovic Courtès
2015-10-07 14:09 ` Mark H Weaver
2015-10-07 18:05 ` Leo Famulari
2015-10-07 20:59 ` Ludovic Courtès
2015-10-08 11:44 ` Ludovic Courtès
2015-10-12 8:37 ` Brandon Invergo
2015-10-12 9:18 ` [bug-gsrc] " Brandon Invergo
2015-10-12 16:38 ` Ludovic Courtès
2015-10-12 21:26 ` Brandon Invergo
2015-10-12 21:34 ` Ludovic Courtès
2015-10-12 22:06 ` Brandon Invergo
2015-10-13 9:47 ` Ludovic Courtès
2015-10-12 16:39 ` Ludovic Courtès
2016-02-22 4:20 ` Christopher Allan Webber
2015-10-10 7:22 ` Alex Vong
2015-10-10 17:03 ` Mark H Weaver
2015-10-11 17:44 ` Ludovic Courtès [this message]
2015-10-14 5:33 ` Rastus Vernon
2015-10-15 13:33 ` Mark H Weaver
2015-10-07 17:45 ` Alex Kost
2015-10-07 12:23 ` [PATCH 2/4] emacs: Add 'guix-devel-download-package-source' Ludovic Courtès
2015-10-07 17:25 ` Alex Kost
2015-10-07 19:15 ` Ian Denhardt
2015-10-09 12:14 ` Alex Kost
2015-10-07 22:10 ` Ludovic Courtès
2015-10-08 11:27 ` Alex Kost
2015-10-08 11:46 ` Ludovic Courtès
2015-10-09 12:08 ` Alex Kost
2015-10-09 12:17 ` Ludovic Courtès
2015-10-09 14:00 ` [PATCH] emacs: Add 'guix-devel-build-package-source' Alex Kost
2015-10-11 18:33 ` Ludovic Courtès
2015-10-08 14:43 ` [PATCH 2/4] emacs: Add 'guix-devel-download-package-source' Christopher Allan Webber
2015-10-08 15:03 ` Ludovic Courtès
2015-10-02 13:04 ` [PATCH 3/4] lint: Export 'run-checkers' Alex Kost
2015-10-03 20:36 ` Ludovic Courtès
2015-10-02 13:04 ` [PATCH 4/4] emacs: Add 'guix-devel-lint-package' Alex Kost
2015-10-03 20:44 ` Ludovic Courtès
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=87mvvp1es1.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=mhw@netris.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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.