From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Checking signatures on source tarballs Date: Sat, 10 Oct 2015 13:03:16 -0400 Message-ID: <871td28xm3.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> <87io6iojmf.fsf@netris.org> <87bnca2y59.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]:58862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkxYo-0007W3-O2 for guix-devel@gnu.org; Sat, 10 Oct 2015 13:03:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkxYj-00086K-UC for guix-devel@gnu.org; Sat, 10 Oct 2015 13:03:54 -0400 In-Reply-To: <87bnca2y59.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 07 Oct 2015 22:59:14 +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 ludo@gnu.org (Ludovic Court=C3=A8s) writes: > What you suggest would be perfect but, if I understand it correctly, > it=E2=80=99s far from reality. What exactly is far from reality? I did not speak about what _is_, but rather about what we _should_ do to improve things. > 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. Tor publishes a list, but I agree that it's rare. So, in practice, we would populate the list of authorized signing keys from the *.sig files we find. So, we'd replace the current practice of "trust on first file download" with "trust on first key download for each new signing key". It's obviously not perfect, but it's better than what we have now: * There would be fewer opportunities for MiTM attacks, because typically signing keys change less frequently than new upstream releases are made. * We have better tools and practices for verifying the authenticity of GPG key fingerprints, e.g. key signing parties, the web of trust, key fingerprints printed on business cards, etc. * I expect that people will be more motivated to make an effort to verify the set of authorized signing key fingerprints. Speaking for myself, I would consider it well worth my time to walk up to an upstream developer at a conference and ask them which keys are authorized to sign their releases, and to get copies of the key fingerprints. However, if I asked them instead for the SHA256 hash of their latest release, they'd probably look at me funny. They'd be unlikely to have that information handy, and frankly it would be a bad approach because we'd have to do it all over again for their next release. It seems to me that you're rejecting this proposal because you see that it's not yet practical to do the job perfectly. In my view, it is enough that it would be a significant improvement over what we have now. In my first message in this thread, I listed the following benefits: I wrote: > * 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. >=20 > * 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. >=20 > * 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. Do you disagree that my proposal would have these benefits? Thanks, Mark