all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Nikita Karetnikov <nikita@karetnikov.org>
Cc: bug-guix@gnu.org
Subject: Re: New “guix refresh” command
Date: Wed, 08 May 2013 00:21:20 +0200	[thread overview]
Message-ID: <87d2t24ejj.fsf@gnu.org> (raw)
In-Reply-To: <87d2t2ehnp.fsf@karetnikov.org> (Nikita Karetnikov's message of "Tue, 07 May 2013 23:03:54 +0400")

Nikita Karetnikov <nikita@karetnikov.org> skribis:

>> When downloading new tarballs, it also retrieves signatures and checks
>> them with GPG, via the new (guix gnupg) module.
>
> Could you point me to this part of the source code?  I fail to find it.

See ‘download-tarball’ in gnu-maintenance.scm.

>> If the public key is missing, it attempts to get it from keys.gnupg.net,
>> and tries again; in that case, the key is added to your keyring.
>
> I haven't tried the tool yet, but I'm suspicious.

Ah, I’m glad somebody chimes in.  ;-)

> First, what if the mirror is malicious but the key is there?  You'll
> fetch a malicious tarball and a malicious key.

Objects aren’t malicious.  Perhaps you’re talking about situations where
a mirror provides a tarball along with a valid signature, but said
signature is made with a random key, and the tarball is actually not
genuine, right?

First, note that ‘download-tarball’ fetches from ftp.gnu.org directly
(or ftp.gnupg.org, etc.), not from mirrors.

Second, this is the same model as used by the OpenSSH client.  When the
client is first introduced to a host, it presents you its key
fingerprint, you type ‘y’, and that key gets added to your known hosts
file.  From there on, person-in-the-middle attacks are trivially
detected as a key mismatch.

With this approach, introduction is the weak link.  It is mitigated by
the fact that, for instance, I’ve already imported and signed keys of
several GNU maintainers, and by common sense (manually checking the
signatures on a key, the tarball contents, etc.)  Also, keep in mind
that ‘guix refresh’ is primarily a maintainer’s tool.

It’s exactly what I would do manually.  What about you?

> Is it possible to use three mirrors to check keys and tarballs?

Check against what?  What do you want to address?

> I also think that one must always check keys manually (using similar
> pages [1]).  Maybe we should manually add fingerprints to a
> licenses.scm-like file and use it along with keys.gnupg.net.  It sounds
> tedious, but it'll be necessary only when you package something for the
> first time.  What do you think?

There’s the ftp.gnu.org/gnu/gnu-keyring.gpg file, which contains all the
keys ever allowed to sign GNU uploads.

But that file is itself currently unsigned.

Ideally (I think) that file would be signed, and the Guix repo would
contain the master key used to sign gnu-keyring.gpg.  From there, it
could fetch that keyring and authenticate it anytime, which in turn
could be used to authenticate GNU source tarballs, as needed for the
on-line auto-updater (see
<http://lists.gnu.org/archive/html/bug-guix/2013-03/msg00032.html>.)

This is similar to Debian’s approach, AIUI.

I’ve made this suggestion to one of the FSF sysadmins, but it seems to
need further discussion, and probably input from crypto-savvy people.

> It also bugs me that there are a lot of packages which are not signed at
> all.  I guess I'll start to ask maintainers to add signatures (at least
> for the future versions).  I hope you'll do the same.

All the packages on gnu{,pg}.org are signed.  I think very few GNU
packages are unsigned.

For non-GNU packages, the situation is not as good, and I agree we must
spread the word, but that won’t change overnight.

> Second, is there a way not to pollute my keyring with such keys or at
> least mark them somehow (for example, as not trusted)?

They are marked as such by default.

Problem is, I want to use my default keyring because it already contains
many keys that I signed.  So I don’t see how to accommodate both needs.

Thanks for sharing your thoughts and concerns!

Ludo’.

  reply	other threads:[~2013-05-07 22:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-24 22:24 New “guix refresh” command Ludovic Courtès
2013-04-25 21:27 ` Ludovic Courtès
2013-04-26 16:16 ` Andreas Enge
2013-04-27  9:43   ` Ludovic Courtès
2013-04-27 10:11     ` Andreas Enge
2013-04-27 21:04       ` Ludovic Courtès
2013-04-27 21:14         ` Andreas Enge
2013-04-27 22:35           ` Ludovic Courtès
2013-04-29 21:27             ` Ludovic Courtès
2013-04-30 15:54               ` Andreas Enge
2013-05-07 19:03 ` Nikita Karetnikov
2013-05-07 22:21   ` Ludovic Courtès [this message]
2013-05-10  0:29     ` Nikita Karetnikov
2013-05-10 13:11       ` Ludovic Courtès
2013-05-10 22:54         ` Nikita Karetnikov
2013-05-11 10:10           ` Ludovic Courtès
2013-05-11 14:05             ` Nikita Karetnikov
2013-05-24 10:19               ` Nikita Karetnikov
2013-05-24 12:54                 ` Ludovic Courtès
2013-05-30  0:46                   ` Nikita Karetnikov
2013-06-01 15:55                     ` Ludovic Courtès
2013-06-02 22:29                       ` Ludovic Courtès
2013-06-07  5:26                       ` [PATCH] guix refresh: Add '--key-download' Nikita Karetnikov
2013-06-07 16:19                         ` Ludovic Courtès
2013-06-08 11:19                           ` Nikita Karetnikov
2013-06-08 14:48                             ` 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=87d2t24ejj.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=bug-guix@gnu.org \
    --cc=nikita@karetnikov.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.