From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Checking signatures on source tarballs Date: Wed, 07 Oct 2015 10:09:44 -0400 Message-ID: <87io6iojmf.fsf@netris.org> References: <1443791046-1015-1-git-send-email-alezost@gmail.com> <1443791046-1015-3-git-send-email-alezost@gmail.com> <87d1wvadw2.fsf@gnu.org> <87bnceah2e.fsf@gmail.com> <87r3la6077.fsf@gnu.org> <87eghalc7s.fsf@gmail.com> <87wpv1tils.fsf@gnu.org> <87a8rwf2vl.fsf@gmail.com> <8737xntorr.fsf_-_@netris.org> <87k2qy7uj7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjpQB-0007wL-T9 for guix-devel@gnu.org; Wed, 07 Oct 2015 10:10:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjpQ5-0007HW-QO for guix-devel@gnu.org; Wed, 07 Oct 2015 10:10:19 -0400 In-Reply-To: <87k2qy7uj7.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 07 Oct 2015 14:06:04 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org, Alex Kost ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Mark H Weaver skribis: > >> 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). > > I thought about it (it used to be in TODO), but this design has several > problems. One of them is that a keyring is needed if we are to verify > signatures; where do we get it? We can download the keys from a public keyserver. However, checking these signatures would be optional. The sha256 hashes would continue to be the authentication method used by default. My goal is to improve security by making it easy for others to independently verify the signatures, and to keep an institutional knowledge of which keys are authorized to sign for which packages. > Another one is that, inherently, the daemon already handles integrity > checks for fixed-output derivations, and authentication should really be > made beforehand by the packager. Agreed. My proposal would not change that. > Most of the time the authentication model is trust-on-first-download: > The packager fetches upstream=E2=80=99s public key when they first downlo= ad a > tarball (so this particular phase is subject to MiTM), and subsequent > downloads are checked against the key that=E2=80=99s already in the packa= ger=E2=80=99s > keyring. Right, and every time the package is updated, that's another opportunity for a MiTM attack. My proposal would fix that problem. It would also allow MiTM attacks to be detected later, because the bad key would be recorded in our git repository for all to see. >> 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. > > So you=E2=80=99re suggesting to put the keyring under version control in = a way, > right? No, I suggest storing only the key fingerprints. > It sounds like a good idea, provided we at least the Git commits that > add/modify the keyring are signed. There=E2=80=99s a couple of issues: u= nless > it can be stored in a plain-text format, it=E2=80=99ll be hard to audit c= hanges > that are made; it would quickly end up containing hundreds of public > keys, so there=E2=80=99s a scalability issue: how do we keep it up-to-dat= e? how > do we decide who=E2=80=99s authorized to update it, etc.? Indeed, storing the keyring would have many thorny issues, which is why I didn't suggest it. > First step would be to be able to do something meaningful with the GNU > keyring. It=E2=80=99s at ftp.gnu.org/gnu/gnu-keyring.gpg, but it=E2=80= =99s currently > unsigned; previous attempts to do something about it haven=E2=80=99t gone > anywhere, but we could try again. The GNU keyring could be useful but is not sufficient by itself, because unless we record which keys are authorized to sign which packages, and use that information during checking, the result is that _any_ key can sign _any_ package, and the security of the entire system is reduced to that of the weakest key on the GNU keyring. This is not good. >> * 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. > > As Andreas notes, outside of gnu.org, savannah.gnu.org, kernel.org, and > a few others, it=E2=80=99s very frequent for packages to not be signed at= all. That's true, but I don't see why this argues against my proposal. >> 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. > > =E2=80=98guix import gnu=E2=80=99 and =E2=80=98guix refresh=E2=80=99 alre= ady do that, but only for GNU > packages. The current mechanism is very weak. _Any_ key on your keyring could sign the package, and it will be happy with that, thus reducing the security of the check to that of the weakest key on your keyring. Also, each person who performs the check downloads the key from the keyserver independently, typically without any verification that we haven't been MiTM'd. Thanks, Mark