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!
next prev parent 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.