all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Christopher Allan Webber <cwebber@dustycloud.org>
To: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org, Alex Kost <alezost@gmail.com>
Subject: Re: Checking signatures on source tarballs
Date: Tue, 06 Oct 2015 22:18:15 -0500	[thread overview]
Message-ID: <87r3l7s6wy.fsf@dustycloud.org> (raw)
In-Reply-To: <8737xntorr.fsf_-_@netris.org>

Mark H Weaver writes:

> Alex Kost <alezost@gmail.com> writes:
>
>> Ludovic Courtès (2015-10-05 18:55 +0300) wrote:
>>
>>> Alex Kost <alezost@gmail.com> skribis:
>>>
>>>> Ludovic Courtès (2015-10-04 19:57 +0300) wrote:
>>>>
>>>>> However, if this is “too convenient”, I’m afraid this would give an
>>>>> incentive to not check OpenPGP signatures when they are available.
>>>>
>>>> Sorry, I have no idea what it means :-(
>>>
>>> When upstream digitally signs its source code tarballs, packagers should
>>> check those signatures to authenticate the code they have.
>>>
>>> If the tool makes it too easy to fill out the ‘sha256’ field without
>>> going through the trouble of downloading the ‘.sig’ file and checking
>>> it, then people will have an incentive not to check those signatures.
>>
>> Oh, now I see what you mean.  Well, I don't know, I think if a user has
>> a habbit to check a signature, he will check it anyway; and if not, then
>> not.
>
> I share Ludovic's concern.  It is a serious problem if packagers fail to
> check signatures.  We should not provide mechanisms that encourage such
> behavior.  It jeopardizes the security of every user of those packages.
>
> IMO, we should rather be going in the other direction, to formalize and
> automate the checking of signatures.  IMO, our 'origin' objects should
> include a set of fingerprints of acceptable GPG signing keys for that
> package, as well as information on how to find the signature (in cases
> where it cannot be guessed).
>
> This would have several beneficial effects:
>
> * 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.
>
> * 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.
>
> * 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.
>
> Also, our linter should download and check the signature, so that it's
> easy for others to independently check the verification done by the
> original packager.
>
> What do you think?
>
>       Mark

This sounds great to me!

  reply	other threads:[~2015-10-07  3:18 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 [this message]
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
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=87r3l7s6wy.fsf@dustycloud.org \
    --to=cwebber@dustycloud.org \
    --cc=alezost@gmail.com \
    --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.