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: Sun, 11 Oct 2015 19:44:14 +0200 Message-ID: <87mvvp1es1.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> <87bnca2y59.fsf@gnu.org> <871td28xm3.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]:38320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlKfU-000728-Ok for guix-devel@gnu.org; Sun, 11 Oct 2015 13:44:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlKfR-0001SY-GP for guix-devel@gnu.org; Sun, 11 Oct 2015 13:44:20 -0400 In-Reply-To: <871td28xm3.fsf@netris.org> (Mark H. Weaver's message of "Sat, 10 Oct 2015 13:03:16 -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 Mark H Weaver skribis: > 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. Sorry, that was poorly worded. What I meant to say is that the practices of upstream developers are on average far more =E2=80=9Csloppy=E2= =80=9D than we, as downstream, would end up setting up. A particular problem I see, is that we would end up maintaining a list of authorized fingerprints when 90% of upstream developers do not actually provide that information. This is not to say we shouldn=E2=80=99t try. Rather, what I=E2=80=99m sayi= ng is that we should make sure we don=E2=80=99t over-engineer a solution whose benefits w= ould, in effect, be significantly limited by what upstream actually does. [...] > It seems to me that you're rejecting this proposal because you see that > it's not yet practical to do the job perfectly. I=E2=80=99m not rejecting the proposal. My main concern is the implementat= ion of the proposal; I think it=E2=80=99s easy to over-engineer it, or end up w= ith something that doesn=E2=80=99t scale, or provides wrong assurance. > 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. I agree that=E2=80=99s an improvement, because it provides an audit trail. In practice it may still be hard to determine whether this is the =E2=80=9Cwrong=E2=80=9D key, because only upstream can tell. >> * 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. Agreed. >> * 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. Agreed. > Do you disagree that my proposal would have these benefits? No! So, how do we do this? :-) Something like , where the signature fields are optional? Do we force signature checks as part of the derivation builds, or do we make it off-line (say, in =E2=80=98guix lint=E2=80=99), or both? How do we handle projects that maintain a list of authorized public keys, like GNU, Tor, and kernel.org? Thanks, Ludo=E2=80=99.