From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id aCR2AuB842MN3wAAbAwnHQ (envelope-from ) for ; Wed, 08 Feb 2023 11:43:44 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 6FFkAuB842MfMgAAauVa8A (envelope-from ) for ; Wed, 08 Feb 2023 11:43:44 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 2251D2C275 for ; Wed, 8 Feb 2023 11:43:43 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pPgng-000545-9W; Wed, 08 Feb 2023 04:31:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pPgne-00053x-L5 for guix-devel@gnu.org; Wed, 08 Feb 2023 04:31:34 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pPgnd-0000mU-Q8; Wed, 08 Feb 2023 04:31:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=82a3avc/jG5uUfRUOs2+Kp1cgWJ+3SWrNqLiwvllaIc=; b=Y3DzfUCW/GdTLorP4Aiy OtqS4Ozc1Aqtf9S/0DQtRldq7mJ6xnNtuAEVkT0qKzufwpIyNZOq9tlHmlANOwimDLsQj5mxR/BnD NymgHV5SNHFGOaioVD6p/yz+WMOYkMIiteJAmfK2EZ8WZeOsIuvIMLw7JwkVXCAGciW3Km29+r7i5 lI9C5+9hhnt6s85IFLfZQJdg/t5nE66s9b9Z5RhwzT47DjSrhvlgu0oNPtvGfJ2bb4jUXrpKSYeOd n9q7/HMO9YKTUO76Kd6HP4pCZhlJrBQ6gWo197uj+eGsBX5Sz1MrsMGGVAI0uENud4hJkSMiQTRQx r0D3RKuQlw9yhA==; Received: from [89.207.171.76] (helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pPgna-0004cC-6E; Wed, 08 Feb 2023 04:31:33 -0500 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Simon Josefsson via "Development of GNU Guix and the GNU System distribution." Cc: Simon Josefsson Subject: Re: Protect against 'guix pull' providing stale data References: <87cz6lzycl.fsf@kaka.sjd.se> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: =?utf-8?Q?D=C3=A9cadi?= 20 =?utf-8?Q?Pluvi=C3=B4se?= an 231 de la =?utf-8?Q?R=C3=A9volution=2C?= jour de la Serpette X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Wed, 08 Feb 2023 10:31:15 +0100 In-Reply-To: <87cz6lzycl.fsf@kaka.sjd.se> (Simon Josefsson via's message of "Tue, 07 Feb 2023 09:14:18 +0100") Message-ID: <87edr0zeos.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list 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+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=Y3DzfUCW; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org ARC-Seal: i=1; s=key1; d=yhetil.org; t=1675853023; a=rsa-sha256; cv=none; b=nOORYjEtNGNX5L5fK0DAq58cF9Qe+SfMtFbjg/DUSsJcx2kCbK9tuesZXbpEBYPbtxlx6H nd480xowaD5I5mxXmjt0C+oq2oR7D7rsT7jtvb+Y8IfkRPzByz+KVKD7AkGCbeBRlW1bTW sxKax3M0MfhHSf9U8tE7YHastHPMTEnwL9E2OF0J/0zvSMRi7ueADNbeobSB49GejpADub CH0sJgfAAvhJpMR8li1pYeDN+UXUa5OnuLbZ9MgUR+S3p5OmsvvJ/CDG10AX/+54UAA41h RCjTCTQakLtmV1l/3xHzNhWJp6jpXrHzmNj2qrC0NG75iUyaNRYkZSnRsrOx1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675853023; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=82a3avc/jG5uUfRUOs2+Kp1cgWJ+3SWrNqLiwvllaIc=; b=DOYT7zFDmVwF9n4q7fRvQuawyNdp7RorxCuREiG1B/lIIji0G6J2dWNOUpVZrAIZ37eSye Ti6LUvH/L+G8duUuPHoKO5kWu8oMR38s2GmdEPObpODXiflBPdROWjrWBUcqOoaCbvr3Nv UzfiaUwqFM2YdTuzG3491ylvzkjnSVJFH0IPf8vqShFV5+iZpBN97ZfZ8Nf69Tma24ZOIH lEVWz+FtlIgNzxOSffBKUTLGYWZrbKiyPnI57GPMeKylomhbhHPJbjj+lUY+atLlJ3du2p NkCXTF6umr/RxHnytGsnYJ+KfFRfEKVB3EKh4g57kjt0HA0CmOn3wcFomWBAFQ== X-Migadu-Spam-Score: -7.59 X-Spam-Score: -7.59 X-Migadu-Queue-Id: 2251D2C275 X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=Y3DzfUCW; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org X-TUID: tBssXUpMqRnv Hi Simon! Simon Josefsson via "Development of GNU Guix and the GNU System distribution." skribis: > I was watching > > https://fosdem.org/2023/schedule/event/security_where_does_that_code_come= _from/ > > and one concern that came up was that there is no protection or > mitigation against 'guix pull' servers providing machines old data, to > (for example) stall security updates from reaching a server. Currently > the Savannah sysadmins have the power to delay security updates for my > machine. I think this should be considered a unwanted behaviour that > warrant some action, either tooling improvement or documentation. Right, it=E2=80=99s a limitation of this model (and of Git in general). Th= is is mentioned in (Section 7 discusses that in the context of mirrors, and Related Work mentions the =E2=80=9Creference state log=E2=80=9D mechanism proposed by To= rres-Arias et al.). > There are many ways to improve the situation, even though addressing the > problem completely is difficult (most if not all GNU/Linux distributions > have similar issues). Some ideas: > > * Warn if the repository has not since a commit for > 7 days, with the > delay being configurable. This may be a bad idea: warnings are > generally not appreciated by users, security warnings specially so. Yeah. > * Have 'guix pull' show metadata for the last commit it received (e.g., > show output from: git log -1) to give users a way of noticing that it > is not seeing new data. Currently only the git commit id is shown > which does not convey enough information. Right, but commit timestamps wouldn=E2=80=99t help either: with the current backlog, we regularly push one-month-old patches. :-) Expecting users to judge freshness on their own doesn=E2=80=99t sound piratical to me anywa= y. > * Adopt a way for repositories to state the validity period of its > content to have the 7 days a bit configurable, compare for example: > https://wiki.debian.org/DebianRepository/Format#Date.2C_Valid-Until > > The idea being that 'guix pull' would fail if the repository hasn't > been touched after the specified interval end, causing the user notice > and take action. The maximum interval provided by the repository > should probably be limited by a locally configured maximum delay the > user is willing to only see old data. How would you communicate that validity period to clients though? One could use a HTTP header but I don=E2=80=99t think Git clients (libgit2 in t= his case) pay attention to that. [...] > * Have a third party, or even decentralized system, monitoring service > where each client can compare the commit data they got from 'guix > pull' with what everyone else is seeing. This provides global > consistency of what Guix machines are seeing for the Guix > repositories, similar to Certificate Transparency. This protect > against targetted stale data attacks only, but that may be sufficient: > any non-targetted stale data attack is likely to be noticed by Guix > maintainers. I think non-targeted stale data attacks (i.e., attacks on the primary Git repo) would be detected by Guix committers promptly. So in fact, I=E2=80=99m not that concerned about this one. And then there=E2=80=99s pr= otection about stale mirrors, too. As for targeted attacks, where one would essentially trick a person into talking to git.evil.com instead of git.sv.gnu.org and fetching a stale repo from there, I don=E2=80=99t know. The =E2=80=9Creference state log=E2= =80=9D mechanism can address that IIRC, but it requires modifications to Git clients and servers. Some sort of Commit Transparency log sounds interesting, but it also raises the issue of what trust to put into that log (what to do when the transparency log and the repo disagree?). > This would also protect against substitution attacks, although I'm not > sure if Guix protects against them by other means? I'm thinking a > malicious savannah could send me core-updates instead of master, but > call it master to my machine, and I'll not notic that I got a > different branch instead. Does 'guix authenticate' verify meta-data > such as git branch in a way where the server cannot fake this data? =E2=80=98guix git authenticate=E2=80=99 only checks the =E2=80=9Cauthorizat= ion invariant=E2=80=9D. The article above also mentions =E2=80=9Cteleport attacks=E2=80=9D, which a= re not addressed per se. There was a discussion with Maxime Devos describing an attack whereby the attack would change =E2=80=98master=E2=80=99 to point= to the =E2=80=98core-updates=E2=80=99 branch, which in practice could lead users t= o download stale packages, as discussed in Section 6: There=E2=80=99s no easy way to address that, but it=E2=80=99s also no very = practical in Guix. Thanks for your feedback and for organizing the devroom! Ludo=E2=80=99.