From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Checking signatures on source tarballs Date: Wed, 07 Oct 2015 22:59:14 +0200 Message-ID: <87bnca2y59.fsf@gnu.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> <87io6iojmf.fsf@netris.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]:55618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjvoG-0002JL-H7 for guix-devel@gnu.org; Wed, 07 Oct 2015 16:59:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjvoF-00073B-Ap for guix-devel@gnu.org; Wed, 07 Oct 2015 16:59:36 -0400 In-Reply-To: <87io6iojmf.fsf@netris.org> (Mark H. Weaver's message of "Wed, 07 Oct 2015 10:09:44 -0400") 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: Mark H Weaver Cc: guix-devel@gnu.org, Alex Kost Mark H Weaver skribis: > 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. I agree with the goals. I=E2=80=99m just wondering how this can be achieve= d in practice in a way that scales. I would suggest starting with GNU, because it=E2=80=99s easier. If we mana= ge to get something that works and scales to all of GNU, then let=E2=80=99s exten= d it. >> Most of the time the authentication model is trust-on-first-download: >> The packager fetches upstream=E2=80=99s public key when they first downl= oad 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 pack= ager=E2=80=99s >> keyring. > > Right, and every time the package is updated, that's another opportunity > for a MiTM attack. Not if the package is updated by the same person that retrieved the key initially (similar to TOFU with SSH.) >>> 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. How do we know which key is authorized for which package? Even for GNU, we=E2=80=99d have to ask the FSF, and obviously the set of authorized keys for each package keeps changing. So we=E2=80=99d need the = FSF to provide us with a database/server to answer questions such as =E2=80=9Cw= hich public keys could sign for GNU Foo at this date?=E2=80=9D in a secure way. >>> 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 alr= eady 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. Sure, I agree. But that=E2=80=99s what we have. When I download a package, the best I can do is to download its .sig and check it, optionally adding the corresponding public key to my keyring if it=E2=80=99s missing. And that=E2=80=99s it. There=E2=80=99s a handful of packages for which I know personally the perso= n who uploads tarballs and their associated key. For the rest, I just have to trust the .sig to originate from an =E2=80=9Cauthorized person=E2=80=9D. What you suggest would be perfect but, if I understand it correctly, it=E2=80=99s far from reality. There=E2=80=99s not a single project I know= of that publishes the list of public keys authorized to sign its tarballs. Even if they did, we=E2=80=99d need a way to authenticate that list. Does that make sense? Sounds very tricky to me! Thanks, Ludo=E2=80=99.