From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: Checking signatures on source tarballs Date: Wed, 07 Oct 2015 14:05:32 -0400 Message-ID: <1444241132.3296193.404052897.12822DF5@webmail.messagingengine.com> 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]:39840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zjt5u-0000SU-Vp for guix-devel@gnu.org; Wed, 07 Oct 2015 14:05:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zjt5r-0001Ev-OS for guix-devel@gnu.org; Wed, 07 Oct 2015 14:05:38 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:52014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zjt5r-0001EX-G8 for guix-devel@gnu.org; Wed, 07 Oct 2015 14:05:35 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5189720C90 for ; Wed, 7 Oct 2015 14:05:33 -0400 (EDT) In-Reply-To: <87io6iojmf.fsf@netris.org> 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 , =?UTF-8?Q?Ludovic=20Court=C3=A8s?= Cc: guix-devel@gnu.org, Alex Kost On Wed, Oct 7, 2015, at 10:09, Mark H Weaver wrote: > > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > > Most of the time the authentication model is trust-on-first-download: > > The packager fetches upstream=E2=80=99s public key when they first down= load 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 pac= kager=E2=80=99s > > keyring. >=20 > 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. I have been wondering about this issue as I created package and I share Mark's concern. The current system relies on packagers to get it right for every update.