GNU bug report logs - #75552
Non-committers can't keep authenticated forks updated

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: guix; Reported by: 45mg <45mg.writes@HIDDEN>; dated Tue, 14 Jan 2025 04:23:02 UTC; Maintainer for guix is bug-guix@HIDDEN.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 3 Feb 2025 16:41:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 03 11:41:30 2025
Received: from localhost ([127.0.0.1]:40954 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tezVq-0000eB-9U
	for submit <at> debbugs.gnu.org; Mon, 03 Feb 2025 11:41:30 -0500
Received: from 4.mo575.mail-out.ovh.net ([46.105.59.63]:38075)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ngraves@HIDDEN>)
 id 1tezVk-0000du-CD
 for 75552 <at> debbugs.gnu.org; Mon, 03 Feb 2025 11:41:28 -0500
Received: from director6.ghost.mail-out.ovh.net (unknown [10.109.176.215])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4YmshL1yV1z1kfV
 for <75552 <at> debbugs.gnu.org>; Mon,  3 Feb 2025 16:41:22 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-7l55b (unknown [10.110.113.83])
 by director6.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 9DB301FE31;
 Mon,  3 Feb 2025 16:41:20 +0000 (UTC)
Received: from ngraves.fr ([37.59.142.101])
 by ghost-submission-5b5ff79f4f-7l55b with ESMTPSA
 id uM/7HbDxoGeGKQEAlyeZRQ
 (envelope-from <ngraves@HIDDEN>); Mon, 03 Feb 2025 16:41:20 +0000
Authentication-Results: garm.ovh; auth=pass
 (GARM-101G0046ad03e2a-589b-4799-b6d5-6de4523380e3,
 EFCE248ADE70B54210882141F0EEFFD7996FFAD9) smtp.auth=ngraves@HIDDEN
X-OVh-ClientIp: 90.92.117.144
From: Nicolas Graves <ngraves@HIDDEN>
To: Simon Tournier <zimon.toutoune@HIDDEN>
Subject: Re: bug#75552: Non-committers can't keep authenticated forks updated
In-Reply-To: <874j1b9gq5.fsf@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87v7uerjk9.fsf@HIDDEN>
 <ef18ee3dc4813b20fe40c21ec0f03e856acdb9a0.camel@HIDDEN>
 <87ed112jzp.fsf@HIDDEN> <874j1b9gq5.fsf@HIDDEN>
Date: Mon, 03 Feb 2025 17:41:19 +0100
Message-ID: <87jza7x9ow.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Ovh-Tracer-Id: 17415982709865833000
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddukeduudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfggtgesthdtredttddttdenucfhrhhomheppfhitgholhgrshcuifhrrghvvghsuceonhhgrhgrvhgvshesnhhgrhgrvhgvshdrfhhrqeenucggtffrrghtthgvrhhnpeffkedvjefhgfevffdutdeivdetleehudevtdevheeghfeutdejffdvjeefffevgeenucffohhmrghinhepshhrrdhhthenucfkphepuddvjedrtddrtddruddpledtrdelvddruddujedrudeggedpfeejrdehledrudegvddruddtudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepnhhgrhgrvhgvshesnhhgrhgrvhgvshdrfhhrpdhnsggprhgtphhtthhopedupdhrtghpthhtohepjeehheehvdesuggvsggsuhhgshdrghhnuhdrohhrghdpoffvtefjohhsthepmhhoheejhegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=c/P/4CKvpW+2MFEYtBTsramDB6J40Yjrk40Yq0lBIR0=; 
 c=relaxed/relaxed; d=ngraves.fr; h=From;
 s=ovhmo4487190-selector1; t=1738600882; v=1;
 b=3+Qum2mOR/BvIKzbi/cCZty6v7PUjmY2BXHE0esTQHh+PrdRMe5tpQDQFOvEHQFVnoAepB1N
 coZI2tN6mj7a9cbQvJ7/uGpYMnCQ6rawwoA2ew/LfUECRw4TMGDnBKzjA/z6dz16OcBQVl8B2KP
 C3M939MBe5jwwx+kzqLHIkbRJNRofL+ewLO9lsQ7haiJVb6gmmakSDTfaA7tfJRt4RCmA8PIBoA
 3Gg56d2RG/f8I93zaXiHzkZQRw0Ak2tksxESMqHKuXWJ9X0gxQTe5JAb2QWNpKeCJA75xYDgCU4
 /V17Rd8U7e9u98l5x88ZGWJzJ0KdDcZrsIbCKQ4kCNLXw==
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: 75552 <at> debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>,
 45mg <45mg.writes@HIDDEN>,
 Liliana Marie Prikler <liliana.prikler@HIDDEN>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>, guix-devel@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On 2025-02-03 16:43, Simon Tournier wrote:

> Hi,
>
> On Fri, 17 Jan 2025 at 22:44, Nicolas Graves <ngraves@HIDDEN> wrote:
>
>> I recently started a guix extension to help manage complexities of
>> maintaining guix soft-forks.
>
> [...]
>
>
>> https://git.sr.ht/~ngraves/guix-stack
>
> Oh cool!  This appears to me the right direction.  Instead of yet
> another subcommand, I think this needs should be covered by an
> extension, IMHO.

What difference do you make between both? This is indeed an extension ;)

>
> Cheers,
> simon

-- 
Best regards,
Nicolas Graves




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 3 Feb 2025 16:04:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 03 11:04:38 2025
Received: from localhost ([127.0.0.1]:40874 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1teywA-0007Gm-23
	for submit <at> debbugs.gnu.org; Mon, 03 Feb 2025 11:04:38 -0500
Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:50213)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <zimon.toutoune@HIDDEN>)
 id 1teyw6-0007Fz-Jg
 for 75552 <at> debbugs.gnu.org; Mon, 03 Feb 2025 11:04:35 -0500
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-38a25d4b9d4so2345117f8f.0
 for <75552 <at> debbugs.gnu.org>; Mon, 03 Feb 2025 08:04:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1738598668; x=1739203468; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=6Pdqx9/hwldp/61xGDdT6d+oSPWiLlYdpG7h0E/pKdU=;
 b=PO2qG4DXD0u5QoSfuqL9gMoo8JnkSsZNosX6n2mHhRhelo/148cw3B0mgbqPAy5sGS
 vItdeRtRvklLl5nmDQjKu5LdmCbmthHO4Btkl+34nHQSIu1tSVCuUAR/9TWdfVGJxTIE
 TZFgMXElOfOjHGyUidJuvqQ/v82/O+eQY2OVLZL2cE04XrrbJqK7GzyQwzASaDXvocSM
 MSJckUJAQ4NSQnJz2XUbj97MtElN4+jXgdGVqWsQW64WAOX8iM5xhQWmo0l3dPU2V9Qd
 7a1LHAqduFKScwqwSPcinFkUJjoW7ioLaJfeyCdOO3mplBSVSwt8f8FVhfUlcYOO/rlL
 T/kw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1738598668; x=1739203468;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=6Pdqx9/hwldp/61xGDdT6d+oSPWiLlYdpG7h0E/pKdU=;
 b=FxnT/4Gy5zU5CFVDHD2Rux0q6v+IZeae/UyHne/kl3BhQJIFWKSuLg1I8Num7gU7hs
 LwASM8dYqdiXEthrj/I6YmxO19weFK+NXpaLv2UcNCVhNgrqB1Sr3OW/9AfUP9nAlRRM
 3t85x//vNSKWq8BkdGZq6EW+TmPp+q514pr078iKkw4KV5nKUGVoTd8rsyBTvKW6CyB7
 zmLk9EBikB3B6ko2B7gtPtkT3bG27zTibQKW7qkdjydIfc0g8xfjUJNDmDcj5LQFtec7
 KRd239aZNO+nfj53/HdeJ2jl9GQ/HsdV9MmjIA98JcVa/HE3o5b/9sRAV0u2UoFO0xoN
 td7A==
X-Forwarded-Encrypted: i=1;
 AJvYcCWkYfBCesSxQtoETqkQAkENSYYs4U85NaEm1FjITiCJitF3KerwNffvT2dlSWR2CJtrDvce+A==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yy721D9DBIVZbp6JtA5/mctfqervwW4O62GsnNdgCIKYlgubgWf
 nDmmHX5wRumK4WziEm7shz5/h8lj4kdDy55CICOSz5DqHKcXWejN
X-Gm-Gg: ASbGncuSQnJaCdjBXA8fPt5wEFEWXv/XWXU2HPAD3Jc1/wclcJ3pN9anIZjTIaR+fCi
 R+GZLb5uyKbeHFKBDGXBE6zn+lt59bhZ5/+fdgfqwZwUovoN6an1GUdmgyisOPta8oHYQeNpYjK
 Lph8y/RqP1WeNEsHYP0KZ9CQWg38k5e4o9Vj1xmBrAGGtSWADuUkmgdDtUfxc1J2Xjhrhf99gvA
 xhDMM561kd+OnTCiHFQztXhjHdfYyCwChVPl4qCaOy43hkL4E8KkoVGK6l8XT9QamO+fGnQvUXQ
 pm+2W9FTkNDLv8Cdxy9kiGvzDrF9Md/4fiKgo+882lm6/V96yOGxUvzqcGP+S7h234g6Zq+j57+
 P
X-Google-Smtp-Source: AGHT+IG567q0s5TWMwZE3zu5zEmZEJRsg+RKzl/z4HOCGtSnBEi/dA44OnevkszWrk/EcNopRwjcBw==
X-Received: by 2002:a5d:5f44:0:b0:385:f69a:7e5f with SMTP id
 ffacd0b85a97d-38c520960ebmr22373243f8f.38.1738598666633; 
 Mon, 03 Feb 2025 08:04:26 -0800 (PST)
Received: from lili (roam-nat-fw-prg-194-254-61-44.net.univ-paris-diderot.fr.
 [194.254.61.44]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c5c0eca02sm13327653f8f.12.2025.02.03.08.04.25
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Feb 2025 08:04:26 -0800 (PST)
From: Simon Tournier <zimon.toutoune@HIDDEN>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Subject: Re: bug#75552: Non-committers can't keep authenticated forks updated
In-Reply-To: <ef18ee3dc4813b20fe40c21ec0f03e856acdb9a0.camel@HIDDEN>
 (Liliana Marie Prikler's message of "Thu, 16 Jan 2025 15:34:28 +0100")
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87v7uerjk9.fsf@HIDDEN>
 <ef18ee3dc4813b20fe40c21ec0f03e856acdb9a0.camel@HIDDEN>
Date: Mon, 03 Feb 2025 16:40:55 +0100
Message-ID: <877c679gu0.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: 75552 <at> debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>,
 45mg <45mg.writes@HIDDEN>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>, guix-devel@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi,

On Thu, 16 Jan 2025 at 15:34, Liliana Marie Prikler <liliana.prikler@gmail.=
com> wrote:

> <Rutherther>	lfam: that's interesting that there is really a merge
> commit, for example if I remember right, the core updates merge few
> months ago happened by directly appending the commits instead of a
> merge commit
> <lfam>	Yes, there are two ways to do it (rebase and merge) and it's a
> matter of taste
> <lfam>	Of course there is a correct choice, as with all questions of
> taste ;)
> <Rutherther>	I personally prefer a merge commit, since it has two
> parents, you can track where the previous master pointed to
> <lfam>	And I prefer a rebase. But ultimately it's up to whoever is in
> front of the keyboard
> <lilyp>	FWIW, a rebase is cleaner, but requires that only one person
> signs off commits on any given branch (or else you're signing commits
> that someone else signed before and have to update the trailer=E2=80=A6 n=
ot
> ideal)
> <lfam>	It doesn't matter who signs the commits as long as they are
> authorized. That's the security model we have
>
> So yeah, even for (branch-)local work at least some committers prefer
> rebasing.

To my knowledge, the (implicit) policy used by the Guix project is to
rebase or fast-forward marge and exceptionally apply merge.  This choice
easily simplifies when one digs into the history: it simplifies =E2=80=99git
bisect=E2=80=99 and also the =E2=80=9Cguix time-machine=E2=80=9D substitute=
s coverage.

Maybe, I=E2=80=99ve missed something but it=E2=80=99s not only some committ=
er=E2=80=99s
preference. :-)

Cheers,
simon




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 3 Feb 2025 16:04:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 03 11:04:38 2025
Received: from localhost ([127.0.0.1]:40872 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1teyw9-0007Gj-NP
	for submit <at> debbugs.gnu.org; Mon, 03 Feb 2025 11:04:37 -0500
Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:53719)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <zimon.toutoune@HIDDEN>)
 id 1teyw6-0007Fy-AB
 for 75552 <at> debbugs.gnu.org; Mon, 03 Feb 2025 11:04:35 -0500
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-4361f796586so54043105e9.3
 for <75552 <at> debbugs.gnu.org>; Mon, 03 Feb 2025 08:04:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1738598668; x=1739203468; darn=debbugs.gnu.org;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=kay+OGlIKV5hhOZ0mtAhayz0KZy3agds3Hv5ub59X9g=;
 b=icOFhO/lJEAxH7rmPl2f7tCkiweP2KUck3iRwLdtVfj1yN3BUxTDEV0M7TucLNnxIM
 jFFfTWxzxp9xCNpBkIjasqwZTliR4u93SYbwD+gzGDT5Y4d40I4cx2au/z32Q+vj8PzV
 Gx/ewqR086cIC1NQbwDo09968f1Fb2O3q0nYmf/rx3jOC+7ng5d2mcLWchmwxCpNRRFi
 z31xJBDpYg05SRfHegkPioyLtkECYTc7Cj7K94rmaer4xuuoo/hDpw+Fzm5pENYoLanC
 WxBFAntITa+AIcWAIH01dlnpOPCcTlv6uoFyw8HsRf8pttnAOstR+J2gQT8pDXP39MNa
 Mjdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1738598668; x=1739203468;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=kay+OGlIKV5hhOZ0mtAhayz0KZy3agds3Hv5ub59X9g=;
 b=N4pvm2szIlI6B0yVfzHstKtzo+ap9aFupQrgioDPJR8YFLWqcOxRyLampWfUUNdvyr
 XSUwoQgEcuLjPEY1dvV5aXrb5FoNn0Eejr/HiqeQmLAVD3aNsmRZ0NaCe+/IcCtGJ1Rv
 dZSvT6pCzcSMvW/I2DDQZFIw05rg1jmdtwM+X/F+bNAroZqz/5xZr6AFRiyKasjQPczc
 aT7B0XmpqI0WT8z2O5d8rlD+rptaVRaDd4J6JceBVlg42Zes160xndE6QwNIELNXbLjl
 P4TicA9muKAfwt4uqgSGK1okDqyLAJ3Y+kGSCpMFVLu9lw+AyDLzvPjJqpQPtQyyFKBt
 cpAw==
X-Forwarded-Encrypted: i=1;
 AJvYcCVrXSfJh5s+VMy8Q/Yyl/LgMV88Eskjbgv9TmMg1D0RDWlgw0qa2gQyBirmUywwQw4ipzA0sA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yz2zPzxtfzDKPmxXTuPdmnbvWCrUOHbww4uWkjC8OcsBabmiuMl
 WgMSXTIPsFMcMwtM9Tr1j70dae0o5RW/+vqPRZHvIAjpyec8NnZT
X-Gm-Gg: ASbGncszCJffmB6cWZdioKifwr/IF2TokxxEwasYI24yRi4tJOkaTMf/jMRri7WH0PY
 7eUtE7Zpbf8gI5ofm0b1y/stiP5BlQuHPXs9FwnZSUfjxfOseXBJ6MQEnGV9ulh8Eq/aZahipop
 uMlB7pRiEfohJqUNE32v+4dRyGOwzqtppmlbZKBIkACsvKexLp+lCPu1UxlwkfE1MN2ph14SgtI
 0LdC0826BDQhC9zuhPEP5ktkhzg3WhPiwxkPspD9bP6T+ar7KHssRxSJtPm1P/qBOJlNdevlfTu
 aojC23zYsEXSQHL99APXINGotx+xY/FPDC6YdeKOgcxFrGG0OpU7J/ggOEQbBHvEdaZ47ad/44z
 1
X-Google-Smtp-Source: AGHT+IFg278ebJUcQbfSUyNII+sXdWC4KuYbYqTLidCLtneMBiSmXYqURKwBt4pErZb0bTHaYMa2Sw==
X-Received: by 2002:a05:600c:5027:b0:434:a26c:8291 with SMTP id
 5b1f17b1804b1-438dc40d36emr205275585e9.24.1738598667842; 
 Mon, 03 Feb 2025 08:04:27 -0800 (PST)
Received: from lili (roam-nat-fw-prg-194-254-61-46.net.univ-paris-diderot.fr.
 [194.254.61.46]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38c5c101599sm12967196f8f.23.2025.02.03.08.04.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Feb 2025 08:04:27 -0800 (PST)
From: Simon Tournier <zimon.toutoune@HIDDEN>
To: Nicolas Graves <ngraves@HIDDEN>
Subject: Re: bug#75552: Non-committers can't keep authenticated forks updated
In-Reply-To: <87ed112jzp.fsf@HIDDEN> (Nicolas Graves's message of "Fri, 17
 Jan 2025 22:44:42 +0100")
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87v7uerjk9.fsf@HIDDEN>
 <ef18ee3dc4813b20fe40c21ec0f03e856acdb9a0.camel@HIDDEN>
 <87ed112jzp.fsf@HIDDEN>
Date: Mon, 03 Feb 2025 16:43:14 +0100
Message-ID: <874j1b9gq5.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: 75552 <at> debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>,
 45mg <45mg.writes@HIDDEN>,
 Liliana Marie Prikler <liliana.prikler@HIDDEN>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>, guix-devel@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi,

On Fri, 17 Jan 2025 at 22:44, Nicolas Graves <ngraves@HIDDEN> wrote:

> I recently started a guix extension to help manage complexities of
> maintaining guix soft-forks.

[...]


> https://git.sr.ht/~ngraves/guix-stack

Oh cool!  This appears to me the right direction.  Instead of yet
another subcommand, I think this needs should be covered by an
extension, IMHO.

Cheers,
simon




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 1 Feb 2025 12:00:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 01 07:00:36 2025
Received: from localhost ([127.0.0.1]:56811 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1teCAt-0005sw-KE
	for submit <at> debbugs.gnu.org; Sat, 01 Feb 2025 07:00:35 -0500
Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]:53730)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <45mg.writes@HIDDEN>)
 id 1teCAr-0005si-HW
 for 75552 <at> debbugs.gnu.org; Sat, 01 Feb 2025 07:00:33 -0500
Received: by mail-pl1-x642.google.com with SMTP id
 d9443c01a7336-21619108a6bso49310185ad.3
 for <75552 <at> debbugs.gnu.org>; Sat, 01 Feb 2025 04:00:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1738411227; x=1739016027; darn=debbugs.gnu.org;
 h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=6gl8AMyO+GJn9NGur9gS7Gc2uFy8zmF3hZCHfOUsz2I=;
 b=eguVtJc+C30PW3gqGxKaU+MfPTJIu0yDq4UCCnb1hLFdxb3G79YuBsIlnRte4WFAYx
 K/l55FO389NPQjySt+CbLYYkpwpQSPd6KZknqqj84Ci1PMVZ0wNLc/IgwzewRao2L9Xi
 MYma/rVH62FaSm06QGDhtJ3IYFmTqqUoaedthy0ImlwmLQRoON1VSOek446/C5zB1G3T
 8PqBO3EN2iVqlU0PnO/o4Z0bGEHeQm1Vn7INlTbPRjiuCtafuIml/7OowKkxQaehUr9f
 TEea8CrX5bjRyMErjk57J4yRoxeYvd8+Vh1mZ6u2us+HTS0b7WQd9qBgHTvXNZPNBu+m
 Awcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1738411227; x=1739016027;
 h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=6gl8AMyO+GJn9NGur9gS7Gc2uFy8zmF3hZCHfOUsz2I=;
 b=wqflKt18yU4nI2dL+/i9O4p/YUlMMUjsdMJdrGOfgJBj1XkzM1LKAN9P2TcHNKGkxP
 pWzy9142F13oDqk3MZbsNiKN0Suo4XoEVoA3yCPwX+UAdVbaX3METcR8QDwe65ucm4JG
 Kq39nJsGCpxkHh2KJM1aoh6QKHJ9xdE9yY7HvJrEFaR4nfbd2JxxBZGiEwlD9mhiQ1Ei
 PjgSprBkikKEl6s9hGcBMwIYTg78al7a9gWqw8GL4us/TffdWE8M6Va1IDDT0AMaoYnh
 nPs2LdMvVS01VjeBjUbp0tof2ZfuT54FRXnlrB4iJ9+8nOBJNSqDQ/i4iCjglNk1y3o6
 a8CQ==
X-Forwarded-Encrypted: i=1;
 AJvYcCWppFoTd78FVacLS8xQYsdATcPxMp4PWilGWJ54s22nqCoHnLaQlqWsL73mcVaIZfILC2dqPw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwwymomX3vKUz0b9/4EcuaiMMUm/hBnq3x6RwfngL/0C3/6TU69
 y51wrq1rv/9SH+t+HBar3q+eNEzfy6HBxZqWVIniHG7GzdbOuYz8HzJ4oQFX
X-Gm-Gg: ASbGncuCRuC6o0tXWu16if+NsA3Hofvgqdi/gv2KPhNUklxvIHp/+XuoxpdO0DEWI5U
 HqWWmtFn1JIuHl4BNY77IAf9LQz4rDDVasH4piJQG31ltZqSMye9+GDqBgQnlXqyV24eoupTYz+
 MqtJE35fqWR4dxQSdaBpD6t9FhxfRhS8fHJw/U47ORJsu/cY/Ouy3kwF9Q8dvu2/kGO4J1CQLip
 PferqXRpy81PemYrIc5RZDPtOmkqmBz+qK2yIDcdEUejGJoqd4mbj/FPm11rvFMc4iJJ4C0vYXE
 mdND/DQil4qJTad7
X-Google-Smtp-Source: AGHT+IES0MTn6yKO8yRMbRLIJQDfXr/h3yQD630Z/uVsVugzXE3jKV5lQqGPft3w+14ijw92JhVXTw==
X-Received: by 2002:a05:6a21:a24b:b0:1e1:ae4a:1d42 with SMTP id
 adf61e73a8af0-1ed7a5efb8emr25577236637.31.1738411227342; 
 Sat, 01 Feb 2025 04:00:27 -0800 (PST)
Received: from guix1 (utm3.nitt.edu. [14.139.162.2])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-ad0aa1f7421sm1976575a12.39.2025.02.01.04.00.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 01 Feb 2025 04:00:26 -0800 (PST)
From: 45mg <45mg.writes@HIDDEN>
To: 45mg <45mg.writes@HIDDEN>, 75552 <at> debbugs.gnu.org
Subject: Re: Non-committers can't keep authenticated forks updated
In-Reply-To: <878qrednyx.fsf@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
Date: Sat, 01 Feb 2025 12:00:29 +0000
Message-ID: <87jza9ub6q.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: Tomas Volf <~@wolfsden.cz>,
 Liliana Marie Prikler <liliana.prikler@HIDDEN>,
 Ricardo Wurmus <rekado@HIDDEN>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>, guix-devel@HIDDEN,
 Attila Lendvai <attila@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Guix,

A small update - I've implemented a `guix fork` command that should
solve this issue. I opened a new issue for it rather than spamming both
guix-devel and help-guix with patches:

https://lists.gnu.org/archive/html/guix-patches/2025-01/msg02847.html

And here is a link to v1.5 of the same series, since lists.gnu.org
splits the thread index by month:

https://lists.gnu.org/archive/html/guix-patches/2025-02/msg00024.html

It's not ready to merge, but it is ready for testing and feedback. Plus,
v1.5 is good enough to use to set up your own fork, or to convert your
existing fork into a properly authenticated one.

Hope this helps,
45mg




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 18 Jan 2025 16:25:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 18 11:25:56 2025
Received: from localhost ([127.0.0.1]:43489 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tZBe0-0008TE-HX
	for submit <at> debbugs.gnu.org; Sat, 18 Jan 2025 11:25:56 -0500
Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]:58417)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <45mg.writes@HIDDEN>)
 id 1tZBdx-0008Sy-Cr
 for 75552 <at> debbugs.gnu.org; Sat, 18 Jan 2025 11:25:54 -0500
Received: by mail-pl1-x642.google.com with SMTP id
 d9443c01a7336-218c8aca5f1so75798815ad.0
 for <75552 <at> debbugs.gnu.org>; Sat, 18 Jan 2025 08:25:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1737217547; x=1737822347; darn=debbugs.gnu.org;
 h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=trxkxfnDzulySlc5o6cGgfdf5aGA8znuoy32yUU56Us=;
 b=R+qTVJkXefv1kzbqyT8JIMEe4SNHhbaUwA/4b/iFR3LzPOk940LmTRdjJZtc5C9/1T
 dKJP8nxOJ9Ie6o+C8rym3baleajFFvE8hB6EcALvGCQEW65ZqGkzewdwXuoICgi5NUn7
 UPjIX54+pqO/04HqGF5eG+0mz374h6Hb0bpH4b4mOJBpCKSlZJIaiTb6VWSI97O8lcuO
 sEKhoPSxCMdYLGpXACBW9evh1hSTJTtwEJwL70Pci8Z3v8zmZ52GB/X+kzY30WsKA8L1
 bsFoF7n98t5OCUR86Pt/Pui9thZiR6A5N80YX6TGfwQb1XsLuevGS2xhErTdz+E9hK2u
 x/8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1737217547; x=1737822347;
 h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=trxkxfnDzulySlc5o6cGgfdf5aGA8znuoy32yUU56Us=;
 b=FUag9+kXK/wUHdvWZQZqkczTUyY/TqJ7syes7sj5LsIZP3ohhGrrksnZzFr/9hfwQk
 XFLEt7eNp1Vwry2jhI3ve4tocuiSYyAiMVuCchga8pjHx9Y78z6p/KXP9npAd18EBZ1U
 pO+3kOEapY/+JxWZV8blliuu4D8XL6JL3hpO0bxHXFT/TgfhAtH12gsTm/H9FCz3GcNm
 6ScVghW1PsHNnFiJ71r8zIE0qUNQdJzioyCABCkydEpsiDAm+bXudVnjp1niuMUNtZnu
 1DHyFxGDYorLT8TLMYpj+FRaVSANpNdyVj7A4Z19canNQNcAk/8Ewrf9iqI3V0qm7LCq
 DgNw==
X-Forwarded-Encrypted: i=1;
 AJvYcCWsnINjst1/9OjnvHkaRz2wvpIHt4rcy18a4B4Scqp7ksbTmgcY8q198tL/Z16rEZIBAzQvPg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzOcn7hiFZq6YYPOsgRAHSH/RRaO0FoopHsyLUE+vVKvPI3fXZz
 r/jJ0Z41RTWGaImjeiNXFj6p9ig+ZLCj6d2/+Ud12je1X+P+/CYu
X-Gm-Gg: ASbGncu78xRehjiadxEq5Bd0EypV2QmSfYksj55gzrJIZdZ9mOe5h4jEehS9Od0HwLl
 aBngpK73P9MGPBXE9XZBJD//Ew9kNKUnhKuxzkbQBSxnt4qB6Kad4BsflolU3VNtg6Oltmb5iSV
 LEDeE/Er0tVZEiWi1hw5RiBrepsj3Q/75X1lV8ImTaxUf7CYMnvdO+at4l+TxkybIJYr/JEEro8
 Hk0Io7x48s3DPjOfGbTFtyP2rWFIqZCpOSrh2nvimuX2cJeDmz/iUEQbQniwWZCtHYcsC0=
X-Google-Smtp-Source: AGHT+IE/4giYX5tei7JMXqBBYAbikamTUBFgcm9J0ZqwzHBVxWMEZPZkyL+IAskKtJ9bjnlSLDYdgQ==
X-Received: by 2002:a05:6a00:369a:b0:726:f7c9:7b28 with SMTP id
 d2e1a72fcca58-72daf9bec24mr11802434b3a.8.1737217546826; 
 Sat, 18 Jan 2025 08:25:46 -0800 (PST)
Received: from guix1 (utm3.nitt.edu. [14.139.162.2])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72dab9c94d0sm3912839b3a.116.2025.01.18.08.25.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 18 Jan 2025 08:25:46 -0800 (PST)
From: 45mg <45mg.writes@HIDDEN>
To: Nicolas Graves <ngraves@HIDDEN>, Liliana Marie Prikler
 <liliana.prikler@HIDDEN>, 45mg <45mg.writes@HIDDEN>,
 75552 <at> debbugs.gnu.org
Subject: Re: Non-committers can't keep authenticated forks updated
In-Reply-To: <87ed112jzp.fsf@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87v7uerjk9.fsf@HIDDEN>
 <ef18ee3dc4813b20fe40c21ec0f03e856acdb9a0.camel@HIDDEN>
 <87ed112jzp.fsf@HIDDEN>
Date: Sat, 18 Jan 2025 16:25:40 +0000
Message-ID: <87jzasgkcb.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, Tomas Volf <~@wolfsden.cz>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Nicolas!

Nicolas Graves <ngraves@HIDDEN> writes:

> A lightly-related comment :
>
> I recently started a guix extension to help manage complexities of
> maintaining guix soft-forks.  I haven't advertised it yet, and I'm fine
> authenticating locally for now.  I mainly focus on reproducibility of
> patches sent (recording where patches are sent to be able to generate a
> list of <origin> patches from a repo) and pulling from patched channels.
>
> There still some work ahead before I can even advertise it properly, but
> feel free to take a look!  There's no doc yet.  
>
> https://git.sr.ht/~ngraves/guix-stack

Sounds cool! Please let us know once you've added documentation so we
can take a look. We definitely need more tooling in this regard.




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 17 Jan 2025 21:44:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 17 16:44:51 2025
Received: from localhost ([127.0.0.1]:39089 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYu94-0000m0-ET
	for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 16:44:50 -0500
Received: from 18.mo581.mail-out.ovh.net ([188.165.56.163]:53565)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ngraves@HIDDEN>)
 id 1tYu90-0000li-VH
 for 75552 <at> debbugs.gnu.org; Fri, 17 Jan 2025 16:44:49 -0500
Received: from director2.ghost.mail-out.ovh.net (unknown [10.109.148.7])
 by mo581.mail-out.ovh.net (Postfix) with ESMTP id 4YZYDD5lbMz1RWk
 for <75552 <at> debbugs.gnu.org>; Fri, 17 Jan 2025 21:44:44 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-gjhfp (unknown [10.110.168.56])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id E6B7A1FD95;
 Fri, 17 Jan 2025 21:44:42 +0000 (UTC)
Received: from ngraves.fr ([37.59.142.96])
 by ghost-submission-5b5ff79f4f-gjhfp with ESMTPSA
 id isg1MkrPimd6nAUAruGCHQ
 (envelope-from <ngraves@HIDDEN>); Fri, 17 Jan 2025 21:44:42 +0000
Authentication-Results: garm.ovh; auth=pass
 (GARM-96R00119baf654-3062-4003-a9a7-04438efe4b7b,
 DA98F2F65837657A688ECC99C0D12415DAF04715) smtp.auth=ngraves@HIDDEN
X-OVh-ClientIp: 90.92.117.144
From: Nicolas Graves <ngraves@HIDDEN>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 45mg
 <45mg.writes@HIDDEN>, 75552 <at> debbugs.gnu.org
Subject: Re: Non-committers can't keep authenticated forks updated
In-Reply-To: <ef18ee3dc4813b20fe40c21ec0f03e856acdb9a0.camel@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87v7uerjk9.fsf@HIDDEN>
 <ef18ee3dc4813b20fe40c21ec0f03e856acdb9a0.camel@HIDDEN>
Date: Fri, 17 Jan 2025 22:44:42 +0100
Message-ID: <87ed112jzp.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Ovh-Tracer-Id: 14937314065594901032
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefuddrudeifedgudehtdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfggtgfgsehtqhertddttdejnecuhfhrohhmpefpihgtohhlrghsucfirhgrvhgvshcuoehnghhrrghvvghssehnghhrrghvvghsrdhfrheqnecuggftrfgrthhtvghrnhepleekueehkeeutdffjeekhffgjeehkefhkeetheegfffghfeffeeihfdtheeggeetnecuffhomhgrihhnpehsrhdrhhhtnecukfhppeduvdejrddtrddtrddupdeltddrledvrdduudejrddugeegpdefjedrheelrddugedvrdelieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepnhhgrhgrvhgvshesnhhgrhgrvhgvshdrfhhrpdhnsggprhgtphhtthhopedupdhrtghpthhtohepjeehheehvdesuggvsggsuhhgshdrghhnuhdrohhrghdpoffvtefjohhsthepmhhoheekudgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=aTi3YoXTTFwnKQsmyYL21qHAHejJkLAVtio1ZcVk+sc=; 
 c=relaxed/relaxed; d=ngraves.fr; h=From;
 s=ovhmo4487190-selector1; t=1737150284; v=1;
 b=2d1BiqL9Lq5ofqASkUbOAfun1afLigEgEeXJMqgQxDycPlGwYiyjmjqd9uzT5bRXJxRrtwIp
 M7FVKmcOCCdSQYExGs3URNRfeM0fcRKyyrjnKsf4FFMbya3K443ilNG/vQkSfz0Cb5/rYU3d/x9
 uwZSh6sJVllfxrti+WewmogzFn0vImJNB5mcT6ktpWkSKCukjuKbXT1ykUARst2/iSCjXfiAVli
 DbRISKr6233rKfNzepyTe9WqW6NFbyEsarweKA2cRc9NK2mdJKlB7JPPmvYi3nNDub7JBsDJhxR
 A0QpTEe0VVuUBrEm+HvkEAlqayNGmfOkEtoy7WaPalICg==
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, Tomas Volf <~@wolfsden.cz>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On 2025-01-16 15:34, Liliana Marie Prikler wrote:

>> The complexity is due to the requirements of not bumping the channel
>> introduction (to avoid the increased attack surface from having to
>> keep obtaining the updated one, as I discussed earlier), keeping fork
>> history intact (to avoid force pulls), keeping upstream history
>> intact, and being able to authenticate both upstream and fork
>> commits. If you can think of a simpler method that meets these
>> requirements, I'd love to hear it.
> Guix committers are more than happy to use work trees and rebases,
> which simplify this a lot =E2=80=93 again, it's as simple as pull,
> authenticate, rebase.
>
> W.r.t. keeping history intact, we had the following exchange on IRC
> yesterday.
>
> <Rutherther>	lfam: that's interesting that there is really a merge
> commit, for example if I remember right, the core updates merge few
> months ago happened by directly appending the commits instead of a
> merge commit
> <lfam>	Yes, there are two ways to do it (rebase and merge) and it's a
> matter of taste
> <lfam>	Of course there is a correct choice, as with all questions of
> taste ;)
> <Rutherther>	I personally prefer a merge commit, since it has two
> parents, you can track where the previous master pointed to
> <lfam>	And I prefer a rebase. But ultimately it's up to whoever is in
> front of the keyboard
> <lilyp>	FWIW, a rebase is cleaner, but requires that only one person
> signs off commits on any given branch (or else you're signing commits
> that someone else signed before and have to update the trailer=E2=80=A6 n=
ot
> ideal)
> <lfam>	It doesn't matter who signs the commits as long as they are
> authorized. That's the security model we have
>
> So yeah, even for (branch-)local work at least some committers prefer
> rebasing.
>

A lightly-related comment :

I recently started a guix extension to help manage complexities of
maintaining guix soft-forks.  I haven't advertised it yet, and I'm fine
authenticating locally for now.  I mainly focus on reproducibility of
patches sent (recording where patches are sent to be able to generate a
list of <origin> patches from a repo) and pulling from patched channels.

There still some work ahead before I can even advertise it properly, but
feel free to take a look!  There's no doc yet.=20=20

https://git.sr.ht/~ngraves/guix-stack

--=20
Best regards,
Nicolas Graves




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 17 Jan 2025 18:59:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 17 13:59:23 2025
Received: from localhost ([127.0.0.1]:38848 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYrYx-0000KP-Cv
	for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 13:59:23 -0500
Received: from wolfsden.cz ([37.205.8.62]:58268)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <~@wolfsden.cz>) id 1tYrYu-0000K8-4y
 for 75552 <at> debbugs.gnu.org; Fri, 17 Jan 2025 13:59:21 -0500
Received: by wolfsden.cz (Postfix, from userid 104)
 id 638CA35EFDF; Fri, 17 Jan 2025 18:59:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail;
 t=1737140358; bh=LsV039rTBCfpS+wxdyhVe9JZfNyg/ha2duh+8vIVJ40=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=zEf/zxOfpGfFGKAeJIDG32hRIvlaXVCWlUBX9UIFnUlA1nGyXj/IMmQX86oqzTHhn
 chryejYw+WBtKLoO5eR7bB4HKsZY40BCZHJ8ujADP8ggnF5R8U0VpexEQTM6c5Koty
 D64HIG/HgcePA85ua/AzQ/UPAywac9lljJ2dJ3aki7euKdIBYC2iqYO/EqJC/MiC8/
 VYF1pDsyPGTTDT9o33dLW5Qy/+6/bb5eKqraqyZICU8CY1fjbiexYNQYWF448NQ801
 Pq0qwQDdP4dvkYszTdq1W8hFugqc/DVGxgkfiJf0yTj8UmdJld8JV99opXHyXJ9kW6
 eaMQ+eRkL9tImpHY4MXHDRFCSIfy0Hsa7Y1qOg5aYksmk38JeFZnATMhhyEgL3GM/L
 YpI8KcXyGXR+ILiu1awQq4CbskRg8325uLBo8nKdyQ74D+smlHdnq0KDxlV66TV1WC
 s24mT/yTGaiVmdVvUC63kcimQ8qKnp5xPbYvOhV1WarXpjr3O4i2uMFn/PvdtcDTvY
 895DjPJrkm2g7r8xziHhQkXzjwfC49/vsZUmr+bfFWYx888I+gODcCcsWdPX1O2J/8
 Kg69cFHK7aGIC8W0G6pq5vac9ldqQ/AtT+HRx1ZQL74E+pWWMhIlbgSrY/HCvllY0J
 hWulbvrnx3wTqxxRasWT2F2w=
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on wolfsden
X-Spam-Level: 
X-Spam-Status: No, score=-3.1 required=5.0 tests=ALL_TRUSTED,BAYES_00,
 DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_BLOCKED
 autolearn=ham autolearn_force=no version=3.4.6
Received: from localhost (unknown [128.0.188.242])
 by wolfsden.cz (Postfix) with ESMTPSA id 1291535EE52;
 Fri, 17 Jan 2025 18:59:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail;
 t=1737140358; bh=LsV039rTBCfpS+wxdyhVe9JZfNyg/ha2duh+8vIVJ40=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=zEf/zxOfpGfFGKAeJIDG32hRIvlaXVCWlUBX9UIFnUlA1nGyXj/IMmQX86oqzTHhn
 chryejYw+WBtKLoO5eR7bB4HKsZY40BCZHJ8ujADP8ggnF5R8U0VpexEQTM6c5Koty
 D64HIG/HgcePA85ua/AzQ/UPAywac9lljJ2dJ3aki7euKdIBYC2iqYO/EqJC/MiC8/
 VYF1pDsyPGTTDT9o33dLW5Qy/+6/bb5eKqraqyZICU8CY1fjbiexYNQYWF448NQ801
 Pq0qwQDdP4dvkYszTdq1W8hFugqc/DVGxgkfiJf0yTj8UmdJld8JV99opXHyXJ9kW6
 eaMQ+eRkL9tImpHY4MXHDRFCSIfy0Hsa7Y1qOg5aYksmk38JeFZnATMhhyEgL3GM/L
 YpI8KcXyGXR+ILiu1awQq4CbskRg8325uLBo8nKdyQ74D+smlHdnq0KDxlV66TV1WC
 s24mT/yTGaiVmdVvUC63kcimQ8qKnp5xPbYvOhV1WarXpjr3O4i2uMFn/PvdtcDTvY
 895DjPJrkm2g7r8xziHhQkXzjwfC49/vsZUmr+bfFWYx888I+gODcCcsWdPX1O2J/8
 Kg69cFHK7aGIC8W0G6pq5vac9ldqQ/AtT+HRx1ZQL74E+pWWMhIlbgSrY/HCvllY0J
 hWulbvrnx3wTqxxRasWT2F2w=
From: Tomas Volf <~@wolfsden.cz>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Subject: Re: Non-committers can't keep authenticated forks updated
In-Reply-To: <75a9d78bcdab5a032814607a0e5ca58d5fbcaa2b.camel@HIDDEN>
 (Liliana Marie Prikler's message of "Thu, 16 Jan 2025 21:08:40 +0100")
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87a5brsmve.fsf@HIDDEN>
 <c3b1445d236ed95f768c218503089926788256a4.camel@HIDDEN>
 <87sepirfez.fsf@HIDDEN>
 <75a9d78bcdab5a032814607a0e5ca58d5fbcaa2b.camel@HIDDEN>
Mail-Followup-To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 45mg
 <45mg.writes@HIDDEN>, 75552 <at> debbugs.gnu.org, guix-devel@HIDDEN,
 help-guix@HIDDEN, Felix Lechner <felix.lechner@HIDDEN>
Date: Fri, 17 Jan 2025 19:59:17 +0100
Message-ID: <87ikqdqnay.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, 75552 <at> debbugs.gnu.org, 45mg <45mg.writes@HIDDEN>,
 help-guix@HIDDEN, Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Liliana Marie Prikler <liliana.prikler@HIDDEN> writes:

>> All of these things discussed in this thread are technically
>> possible.  But I think that we all agree that the friction involved,
>> compared to just using my own fork with the patch applied, is much
>> larger, at least in my opinion.
> Yes, we can agree that this is your opinion.  We can even agree that
> there is more friction, but I'm not sure whether we agree on the value
> of "much".  But honestly speaking, the friction with contributing to
> upstream is much more a social one (too few people to review) than a
> technical one, and soft forks are a band aid that will likely burn you
> out even sooner the more you commit to them.

I do not know what the future holds, but introduction of my soft-fork is
form Fri Sep 15 16:18:25 2023 +0200, and I am of the opinion that it
saved me more work that is has cost me over the time.  But yes, as you
stated, this is just my opinion.

Tomas

=2D-=20
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJCBAEBCgAsFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmeKqIUOHH5Ad29sZnNk
ZW4uY3oACgkQL7/ufbZ/wamPog//dXI2DLQOPtERLFkiMdCboX7wV/oa0DFvFmJm
2ce9UTasyUrFPlbjS1xs3p9KR3+eFWDdEUMPSFUW5Hm3AeUgiNMJUXyXX8kyLUll
2nRKBhScXk86ZxfTx3ACqLGkPNZn+PiKx4srfSV2AKNUkR+YIysSNcUawlEZ16dq
zHwcZr3YqD5pzMLliqW5bpoq0pUQhBpQH7LIb2JfLZ1yq0wqw7tYJsP56UXCmMV8
r0OXB1nSUB+07zGsP/hdKsP2dQl8hZbuR+A4HTFo3KjdTupz7YzpKzDldGFAsdEX
BDSsRYVjUNsDnat5jy4pzp4+cKB2tdFzGfxOiRu6BVUAKrD6QPe5zaObb3nIDvbu
DURBlTF3w2Tlwjx8khxPg8zgbCxIQHhc643XIIF6SWMNQnm82VoWYLKm369CSr/C
ybXXMdufqGaQOe2K6P7/vsaw/vkSj2qkq0hEvMhaDwSujXXtGedj/MC7qbm34sFA
4BrsZKSgyEK0ZGYuWTTBrws6rKexj76dMipaa3LzgG6O03G9LHfTbPnM6DbmhLeE
607YgQVCPWZfg0w2w+omxJJT2eUM2jnZ9lyp8rdThisMmzhXVBHPbd6HHECMm5Ir
MaBiMnInEwqNsNikJ8omRnHt7irjJ8Gwi8jll1YLjC/GaevNXfvOPNAJQut1GZw0
+Xi5nI8=
=qzfU
-----END PGP SIGNATURE-----
--=-=-=--




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 17 Jan 2025 18:55:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 17 13:55:57 2025
Received: from localhost ([127.0.0.1]:38841 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYrVd-0000DR-9i
	for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 13:55:57 -0500
Received: from wolfsden.cz ([37.205.8.62]:51902)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <~@wolfsden.cz>) id 1tYrVZ-0000DF-9M
 for 75552 <at> debbugs.gnu.org; Fri, 17 Jan 2025 13:55:55 -0500
Received: by wolfsden.cz (Postfix, from userid 104)
 id 5D5D635EAE3; Fri, 17 Jan 2025 18:55:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail;
 t=1737140151; bh=5MrfDTTTwvfm0GqDpO4WKv78Vym5thMUu5GMfGqzo+A=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=xSM8DJ+rz26pJazD4sAOktsfdc/v3pb+tNMjjHQZKX1jrZLEIIIIrFXTXtUCzE3Aj
 m25j2AoSX390anBklZxHSgtOjD0g6JR2Ii6Kh1B84+emalk6SPCzRtMSir2XxWCBrA
 vWIJd/SYjxklVx5kSV+JHXdgtxdewC05Xwho8egczPiBsZrlkfzmcC7t5ftMMWBM26
 cag6uaBX8oMQYGI0C3AmxrbXiVWLIk0O1UTCHKcGVia7n7ke7ck0/gx1gxEXaLL6w2
 ySUaQPKc7EFQlTZ0EIGVdEclHt+Ua+A+NzRmGsjXwY/EK10yJ7yzefpikIaasXIBD2
 mcAvTBL0dEz4yiqXN3F1Ma4XsPlBFbn8FAf7rJ8lpuvpuUKYr6iK8rNd4t8YZZlA0d
 wydBmkDEVF0lQLGXn09reVBo5Ndqz4EuyjCR0TZHh7arV3GliCjbCvVanokbq9OEy8
 qCcQRb700gPFd+VeZ8PABA/gVsLCZIH42YRnuQyRZVFOk5jq6JXnQ+uh9kbK3NoH0O
 2Wk1gv7MgAd39x8PiXTGpXh08ucNBE9ZHgCaXf4XDI2KxadKNYIyLPzj22rFjBEHu8
 yzpzbuvZQtS+BxWjpLWtNiIu+yzV3FoKU6+yOS3OWOEslO5P6RuXRCRJzM6yegVf/h
 gmRO5voqjnKt+M3kA42Upjhs=
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on wolfsden
X-Spam-Level: 
X-Spam-Status: No, score=-3.1 required=5.0 tests=ALL_TRUSTED,BAYES_00,
 DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_BLOCKED
 autolearn=ham autolearn_force=no version=3.4.6
Received: from localhost (unknown [128.0.188.242])
 by wolfsden.cz (Postfix) with ESMTPSA id 899C035EAE2;
 Fri, 17 Jan 2025 18:55:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail;
 t=1737140150; bh=5MrfDTTTwvfm0GqDpO4WKv78Vym5thMUu5GMfGqzo+A=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=uiWmch0S5ux5qR4iMVzIB/RCIgZvwUNjaGPHRQ+JoVTDXVDHFAD7t22fU+GSGmBe6
 aKJJaR1/2F9+rcRnYvAuXDDRFA0w45++PNIUdN9MhREeZCEUb13h38p+3yLqZ3RtG/
 2q/BGCUP7cMHiEtef/rmati87ps5g8eFES2+5kg3nYFtPoZozG2DIiH1erh6NbC1ZG
 CqKUeRK/5P5tySrcQUBCtewroBpKaHnMYjCG5t606SJOXbndW2WUNjeK8phsY/p3Qh
 pwUnOzCa6Y6/A5RQlTYCB0wdQap3nmmzvUtr0ZZnFtzQJyrlxocqbdnECZKRKCGgjn
 4G/4HSOmGu0vlFhsZRadiPxUFEwqtqorbuyXuODFccdFuFarU6egJL9NE33wcJYtoZ
 L9rQfXKmFYhYcluqK3rXHYFznYKIl3r1uxIHzjBmAS7MluqYq7H+ZRQLOV0spwj/01
 20rqWVEaVSjSBxadGbQtG1e8gSpA6fmNRUCEcTs0Gbr/XZWh+q7FgqO8frN3g2FP93
 f1lJ9yAzwunW9MN7beJELV7K6QaL5rLgAa6R5I2zTuqdcanr+dHEyFWXpoFMGYsMuX
 fqWoq8I7uQL02bT1ZjmF2TNPlDDLUzH7wRAWBgOCtqpW5o0aUm+Q7etXtgNW6v1fk1
 My6zETRNHOaJhgq44p48J2Xg=
From: Tomas Volf <~@wolfsden.cz>
To: Saturanya Rahjane de Lasca <saturanya@HIDDEN>
Subject: Re: Non-committers can't keep authenticated forks updated
In-Reply-To: <3938fe5cb9ce8c6c26bd24937e32bedaae4f301e.camel@HIDDEN>
 (Saturanya Rahjane de Lasca's message of "Thu, 16 Jan 2025 22:13:32
 +0100")
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87v7uerjk9.fsf@HIDDEN>
 <ef18ee3dc4813b20fe40c21ec0f03e856acdb9a0.camel@HIDDEN>
 <87cygmmzuh.fsf@HIDDEN>
 <3938fe5cb9ce8c6c26bd24937e32bedaae4f301e.camel@HIDDEN>
Mail-Followup-To: Saturanya Rahjane de Lasca <saturanya@HIDDEN>, 45mg
 <45mg.writes@HIDDEN>, 75552 <at> debbugs.gnu.org, guix-devel@HIDDEN,
 help-guix@HIDDEN, Felix Lechner <felix.lechner@HIDDEN>
Date: Fri, 17 Jan 2025 19:55:50 +0100
Message-ID: <87msfpqngp.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, 75552 <at> debbugs.gnu.org, 45mg <45mg.writes@HIDDEN>,
 help-guix@HIDDEN, Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Saturanya Rahjane de Lasca <saturanya@HIDDEN> writes:

>> Again, not disputing that things work fine for people with commit
>> access. Perhaps that is part of why this issue hasn't been addressed
>> before :P
> You may call us privileged =E2=80=93 and yes, we are =E2=80=93 but that d=
oesn't change
> the fact that weakening security weakens security.

Just to be explicit here, this whole thread was motivated by desire to
simplify soft-forks while keeping the same level of security.  No one
here is arguing for weakening it.

Tomas

=2D-=20
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJCBAEBCgAsFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmeKp7YOHH5Ad29sZnNk
ZW4uY3oACgkQL7/ufbZ/wamkBw/9FRpa4EO1u9wnxbi59zAkXlFtLZBW3aq8aZnF
jN4uhJQhW8NSBXPBWgP8Cw5CHQ8wd0rF4VCfIhnibQs4DRV7cBeFnSxR2SeFVXUA
2zbW4gS3K/t3j1b6nl0PQWWw2Mtm/u7LEtfHV+QVHMy3JtExyJ/bzh8f3Hn5goAd
6BCnz1C3q1EFoveqyhxG0Bpx4+f2sLa7uTXNLKKB9Gf1SzmjLHWRSWyJE1YTWrZ1
lK2DSepZeVQoILg/RAxKwIz2i0yabH6eH2XQZRjeEZR6aC1eZW0/zgAsC/+xAgOX
rrVxohpNxS1SgjOzr3YyIhNv85WgDZ45RuPf4htMFuHALquunvmyVTQ2IPud8cuA
5SIATS7LQ/QuMFZC9SHTZ1ei4JbwtXkZ4muDl9l99iMEGq5bmyuKciu6tn0EaYdc
nsitBUZstck7Ua94+tEfQNUIUy2UGIub9et3UML2loyZ9uMaUr4DPz0J3JB8gt0q
Fzn8b8uzF9ex/rPD0ooBkretAZI4PsqNDbBHiXZNFkHm0KG8vwVi874L7opbrz6U
ftCXJa6vscJeRR5nye+qJVe+O7LeXaOAczfzAeADCtESSlPfEANZ6fAgnz1Ep2+r
QJZ/8SQ9BqD+cgQcqAC/Vlxfe9xPpB0VV3CWpOrbBNBvD+J+r+rfwUE3ALsv7ZJc
LTlNgcM=
=Yhap
-----END PGP SIGNATURE-----
--=-=-=--




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 17 Jan 2025 05:19:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 17 00:19:25 2025
Received: from localhost ([127.0.0.1]:35683 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYelQ-00031d-8x
	for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 00:19:25 -0500
Received: from mx1.dismail.de ([78.46.223.134]:21087)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <saturanya@HIDDEN>)
 id 1tYXBJ-0004mT-E1
 for 75552 <at> debbugs.gnu.org; Thu, 16 Jan 2025 16:13:38 -0500
Received: from mx1.dismail.de (localhost [127.0.0.1])
 by mx1.dismail.de (OpenSMTPD) with ESMTP id f8de5881;
 Thu, 16 Jan 2025 22:13:29 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dismail.de; h=message-id
 :subject:from:to:cc:date:in-reply-to:references:content-type
 :content-transfer-encoding:mime-version; s=20190914; bh=pFjPAgIQ
 3ugoxYJxAKlF72fnJjylxRfeycgdf73Atig=; b=bS6UIfhwYgnwIQqS6qTH28hc
 AHaY9ketcm/erLAcp1RxDSqTS2S6N1CRzq3jo57LrPyvfhmo685gRwp43FXioP3M
 7DGW6cBsDzlyOqPtU5wVLrB4onBke2jpITZwZmfE1+7KftVLwTXlghl6Xi9oX9F+
 2hLkwgHitJywntNNiURLgH+H7rrAlPEP3uOZhJ+8CDomm9QzEkpb5spUmtlXiGQA
 gaDsfEimWET65Bevu6sIbkPvCKLGnwKZPNFmAFGfEapQYPWT4j3aQ8oyGJVIF58D
 oMOtFiwxTCi2AGa6B/FCNckfUtJuP33WExM1FK4Af7f2tadBDXkbOVJ/T1jMxw==
Received: from smtp2.dismail.de (<unknown> [10.240.26.12])
 by mx1.dismail.de (OpenSMTPD) with ESMTP id fd8f1e6f;
 Thu, 16 Jan 2025 22:13:29 +0100 (CET)
Received: from smtp2.dismail.de (localhost [127.0.0.1])
 by smtp2.dismail.de (OpenSMTPD) with ESMTP id 759c8d42;
 Thu, 16 Jan 2025 22:13:28 +0100 (CET)
Received: by dismail.de (OpenSMTPD) with ESMTPSA id cc58b980
 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); 
 Thu, 16 Jan 2025 22:13:28 +0100 (CET)
Message-ID: <3938fe5cb9ce8c6c26bd24937e32bedaae4f301e.camel@HIDDEN>
Subject: Re: Non-committers can't keep authenticated forks updated
From: Saturanya Rahjane de Lasca <saturanya@HIDDEN>
To: 45mg <45mg.writes@HIDDEN>, 75552 <at> debbugs.gnu.org
Date: Thu, 16 Jan 2025 22:13:32 +0100
In-Reply-To: <87cygmmzuh.fsf@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87v7uerjk9.fsf@HIDDEN>
 <ef18ee3dc4813b20fe40c21ec0f03e856acdb9a0.camel@HIDDEN>
 <87cygmmzuh.fsf@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 
MIME-Version: 1.0
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 75552
X-Mailman-Approved-At: Fri, 17 Jan 2025 00:19:21 -0500
Cc: guix-devel@HIDDEN, Tomas Volf <~@wolfsden.cz>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Am Donnerstag, dem 16.01.2025 um 17:29 +0000 schrieb 45mg:
> Yeah, I know I can. My point is that people who use remote forks
> shouldn't have to rely on a trusted third party. We've figured out a
> way for upstream Guix not to have to, now let's try to extend that to
> forks.
Well, the same way already works for channels and hard forks.  It
really is soft forks that experience this issue =E2=80=93 and even then the=
re's
ways around it, as discussed. =20

> > >=20
> Since most future committers will take years to attain that status,
> and many (most?) Guix contributors can't commit (heh) to being
> committers, I think it would be a good thing for them to be able to
> make use of our security mechanisms.
They already can, see above.

I don't think asking would-be committers to soft-fork Guix is
worthwhile idea even with the proposed change.  Authoring your own
channel and contributing bits back to Guix suffices =E2=80=93 and it really=
 is
the things you contribute to Guix proper rather than your channels and
soft forks that make the cut.

> > W.r.t. keeping history intact, we had the following exchange on IRC
> > yesterday.
> >=20
> > [=E2=80=A6]
> > So yeah, even for (branch-)local work at least some committers
> > prefer rebasing.
>=20
> That seems to be a discussion about a merge commit in upstream Guix,
> not about the kind of merge commits that I'm trying to allow.
It is.  I just wanted to give some context.

> Again, not disputing that things work fine for people with commit
> access. Perhaps that is part of why this issue hasn't been addressed
> before :P
You may call us privileged =E2=80=93 and yes, we are =E2=80=93 but that doe=
sn't change
the fact that weakening security weakens security. =20

> > >=20
> > > Let's imagine that the first example given there represents our
> > > fork of Guix, where the 'experiment' branch marks the beginning
> > > of our fork (and its channel introduction) and the 'master'
> > > branch tracks upstream Guix.=C2=A0 After `git rebase master`, the
> > > commit that used to be C4 is gone, and now C4' takes its place.
> > > It may contain the same changes, but it's a different commit - so
> > > it (and any commits that it's the parent of) has a different
> > > hash. So the channel introduction has changed, and so has the
> > > entire history of the `experimental` branch. So we need to force-
> > > pull.
> > Yes, that's one variant =E2=80=93 the one where you need to keep bumpin=
g
> > your channel introductions.=C2=A0 The other direction would be to rebas=
e
> > Guix changes on top of your local branch.=C2=A0 This keeps your channel
> > introduction as-is.
>=20
> Ah, I see. Actually, I think that might work... if I create a
> 'upstream-backup' branch before rebasing, and reset the 'upstream'
> branch to that branch after, I can keep the full history of upstream,
> and authenticate it separately. And thanks to Ricardo's suggestion
> [12] to compare by Change-ID, it should even be possible to find
> corresponding commits between my fork and upstream. Looks like this
> solution meets all four requirements that I stated earlier, and it
> wouldn't be TOO annoying or complicated to script either.
Yes, it's the workflow I alluded to earlier: pull, authenticate, rebase
on your branch.

> One limitation I can think of is that you can't really verify whether
> a commit ostensibly rebased from master is actually the same commit
> (imagine 100 commits in a rebase, are you going to check the diff for
> each? Versus with a merge you only have to check that the merge
> commit looks sane). Then again, this is really only a problem if
> you're using someone ELSE's fork and need to ensure they've not gone
> mad or evil, which is not my personal use-case, and perhaps not that
> common.
Yeah, it really isn't too hard to think of 9000 commits bumping rust-
whatever.  We're not yet calling that Tuesday, but only because we lag
behind the Rust ecosystem as a whole.

> > > >=20
> > > [=E2=80=A6]
> > > This led my to think of an attack that's possible with my design
> > > - if I want to screw with anyone `guix pull`ing from my fork, I
> > > can merge upstream into my fork branch, add a bunch of malicious
> > > commits, and then make the upstream branch ref point to the
> > > latest such commit.  Now anyone pulling from my fork will recieve
> > > the malicious commits as part of upstream's history - since no
> > > commit hashes needed to change, the pull is a regular fast-
> > > forward one, with no indication that anything is amiss.
> > > Authentication will succeed since the malicious merge commit has
> > > our fork as its (first) parent, and that parent has the primary
> > > introduction as its most recent ancestor.
> > >=20
> > > The takeaway here is that anyone authorized via the primary
> > > introduction can fake new upstream commits.
> > Care to state how designating one introduction as "primary" adds to
> > security here?=C2=A0=20
>=20
> The problem I'm trying to solve is that you can't merge upstream into
> your fork unless you sign the merge commit with a key authorized in
> upstream, because of the intersections-of-parent-authorizations
> design.
> Tomas's solution was to do away with the 'intersections' requirement,
> and allow a key that's authorized for any parent to sign the merge
> commit; this is vulnerable to attacks like [4]. My solution falls
> somewhere in between - we keep the 'intersections' requirement,
> /except/ when one of the parent commits is a descendant of an
> introduction designated as the 'primary introduction'.
>=20
> If you drop the 'primary introduction' designation (make all of them
> 'primary'), then you're basically dropping the intersections
> requirement. IOW, we've returned to the situation in Tomas's
> solution, where [4] is possible - anyone with even a single signed
> commit in Guix can now create a merge commit between Guix and your
> fork, even if their key was later removed from Guix.
Yeah, the point I'm trying to make here is that you still end up with
Tomas' solution as you can simply designate whatever primary you want.
The primary is not special in that sense.

> >=20
> > > So what does this all of this mean for the statement of my
> > > design? Well, it means that we need to stop thinking in terms of
> > > 'which branch can be merged into which?' and more in terms of
> > > 'which merge commits can be authenticated?'. And the answer to
> > > that question, with my design, would be:
> > >=20
> > > 1. Any merge commit signed with a key in the intersection of its
> > > =C2=A0=C2=A0 parents' .guix_authorizations. (Standard authorization
> > >    invariant.)
> > >=20
> > > 2. Any merge commit that doesn't meet the above conditions, but
> > >    has a parent whose most recent ancestor is the primary=20
> > >    introduction, and is signed by a key in the
> > >    .guix_authorizations of that parent. (My
> > > =C2=A0=C2=A0 weakened authorization invariant.)
> > That's a pretty long way of saying "Any merge commit signed with a
> > key in one of its parents' .guix_authorizations."
>=20
> Not quite. Merge commits between upstream Guix and your fork, whose
> signing key is in the .guix_authorizations of its parent in upstream
> but not in the .guix_authorizations of its parent in your fork, would
> not be authenticated. (This is the kind of merge commit that would be
> used for [4].)

So merge commits for upstream will look like=20

---X---Y---Z-\
              (M)
---A---B---C-/

whereas merge commits for your fork will look like=20

---X---Y---Z-\
              (M)
---A---B---C-/

Uhm=E2=80=A6 how does `guix git authenticate' differentiate between the two=
?
=F0=9F=A4=94=EF=B8=8F

>=20
> >=20
> > > What does "assert that this set is a subset of what we declare as
> > > introductions" mean?
> > Let's say that you work on branches B, C, and D with "primary"
> > introductions I, J , and K.=C2=A0 If you want to merge C into B, you
> > need to remember that B has I as its primary introduction, C has J,
> > and so on.
>=20
> Ah, got it. Yes, that's correct. (Except that there's only one
> primary introduction, at least as I intended it.)
When those branches tail different upstreams, they won't necessarily
have the same primary introduction =E2=80=93 at least as you intended it.

> > >=20
> > > my design does not require us to distribute any introductions
> > > besides Guix's existing one, nor will it provide any mechanism to
> > > automatically 'install' someone else's introduction.
> > Yes it will, per `%default-guix-channel'.
>=20
> Ok, technically true. And someone with the ability to make trusted
> commits upstream could modify that so that a fresh `guix pull` skips
> whatever malicious stuff they've done. But my solution doesn't make
> this situation any worse AFAICT.
As far as you can tell.  I think the scheme would be gnarly enough to
implement that an exploit =C3=A0 la [4] would be possible, even if by
accident rather than design.

This is actually a stronger argument against soft forks of Guix whether
or not your idea is implemented, but anyone using a "trusted" fork
could have their %default-guix-channel changed by someone who is not an
upstream committer.

And no, malicious trusted commits cannot be undone once done; unless
you allow downgrades, which come with their own caveats.  Thus, for a
fresh checkout, a committer who has had access to upstream and your
fork at some point in time =E2=80=93 not necessarily the same time =E2=80=
=93 can make
it so that they are the only committer whose patches get accepted on
both.  (A weaker attack is still possible if you only have access to
one repo.)

> >=20
> By that logic, we would never have gotten the ability to specify
> multiple channels, since that isn't used in upstream Guix and doesn't
> need to be.
Except that there are legitimate free software channels like Guix
Science, Guix Past or rde's Guix Home channel, which, if memory serves,
use Guix authorizations without issue.  "I want to fork Guix and I need
to worsen its security to do so" is not a good selling point, just
sayin.

>=20
Cheers




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 16 Jan 2025 20:08:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 15:08:45 2025
Received: from localhost ([127.0.0.1]:34773 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYWAW-0007J6-Vf
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 15:08:45 -0500
Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]:48411)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <liliana.prikler@HIDDEN>)
 id 1tYWAU-0007Is-MB
 for 75552 <at> debbugs.gnu.org; Thu, 16 Jan 2025 15:08:43 -0500
Received: by mail-wr1-x444.google.com with SMTP id
 ffacd0b85a97d-38789e5b6a7so768920f8f.1
 for <75552 <at> debbugs.gnu.org>; Thu, 16 Jan 2025 12:08:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1737058116; x=1737662916; darn=debbugs.gnu.org;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
 :date:message-id:reply-to;
 bh=uxFVfGXU6aEBbB2jMHrAeQiMBOMsou9+hD5wJ4BgIOA=;
 b=XUecbGc/iVKUq3bDoZTagGe2NBiDrlCzH2azqQUE9aBfP6Rwd8tOjoGycXogz7CYPC
 HltAWIbB/5MZ+2CT5zH0B9acaNpCc6eQRIxFlSBJvfeQT6ECcm72DNsT/Elv4QBTQhD4
 giC0ruwErdB2BmzHotGf9GgQqvRr+eeE8TIgpl9Lhy/VTRiYxlZQByiMWIPm8hTqZEDY
 /EGQZkGVxP2XtK776pYterdfGzHzOnRXSlYgSUfZ+kR7d0RAzFevaeFWRmlBzetLbhJW
 C3wK2vi+4xYC4UsYQTIaslg9ifV5HSEoo9Yd1WkZpb/dzOzvMYZBF9/XaDXzOFwfpBjC
 b8oQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1737058116; x=1737662916;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=uxFVfGXU6aEBbB2jMHrAeQiMBOMsou9+hD5wJ4BgIOA=;
 b=Kfmbdp89NtOMYaI9J5J/mWZCAZyAegkKEir9LihrQgL14CzwMckvm/JYxA02GvmrYP
 TE5bdyLBpyd+ZQR0ZL1jhhJ6O5ptun1xEu0K4AtMePxHcD6BaNW+gx914RS70t8fBMLD
 WJDV+nptcN5FolRCNwrGxNcptHvBTuRAb+Atv2q2XXZ7MMms2BUaFwD8Q7/FxZr37tKk
 NkrOxfE8PhSk2O1R2BA6YM78Eq0AIiT5IED2EaDmagghwOm0bAa6Pq5bU9NJmc24Xv+z
 EUXOmFuPKCHwlCjl63H3Z1CUm083ssXUqnLeO2NDE37Noi0ZM4nEiPaDwN+w2NvKRAPH
 aAdQ==
X-Forwarded-Encrypted: i=1;
 AJvYcCUC2EcWnRfO9KjLkfDGVruixoYUCE7FV7KeYTEjzcDkG8e9DM2hcGrPpyB7yluECTwQJChmwg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yxi/xOYGB/3D4WXl+s8mR89PYsNntw3InP23cGmoX6HkN1DfZuE
 DFmgOBFUcPk4FNEDwenwz/z3Spkv8vy6KTDuVTPnp4I15D6WzLYp
X-Gm-Gg: ASbGncvtFsLNkOzAPRyd8LabA8u8dqt/VoPYFJnZUOL+PD8K6Lvxn5Ch3Ataj4ytMqw
 9O/xtO6OIA12pC89muWd6lu/RmU7WLrNBvHXClBkpEyuzm9Kkqt9+CyO9eGRilt1uF4vqVVoup6
 DLFcis2ko+/dKX7Hz0ES2kBsdVPOHBRC4FexcS+ClNkPikuTBTKCvnTpg6DRj3kFBdAOx26HTm9
 AdW1E9j2U+rn0iUFIQNhlcJIpXv2UAJAOop0OVMQwwxSX4D0IlrUjYZXyqBK/kqve7w2/gWpHDH
 Xu+1LF6dCHeF9ryQe0vBImPuJNAFmI3u
X-Google-Smtp-Source: AGHT+IGVQmzFBX2APHvQIJFRLmCNbsQNf7ENIwsLAolRbpTUbYbChmPMIxW5IIigawRPMt+Lilmu4A==
X-Received: by 2002:a5d:64ec:0:b0:382:4b52:ffcc with SMTP id
 ffacd0b85a97d-38bf55bebf8mr46165f8f.0.1737058116261; 
 Thu, 16 Jan 2025 12:08:36 -0800 (PST)
Received: from lumine.fritz.box (85-127-114-32.dsl.dynamic.surfer.at.
 [85.127.114.32]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38bf3215bf2sm697664f8f.18.2025.01.16.12.08.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 12:08:35 -0800 (PST)
Message-ID: <75a9d78bcdab5a032814607a0e5ca58d5fbcaa2b.camel@HIDDEN>
Subject: Re: Non-committers can't keep authenticated forks updated
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
To: Tomas Volf <~@wolfsden.cz>
Date: Thu, 16 Jan 2025 21:08:40 +0100
In-Reply-To: <87sepirfez.fsf@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87a5brsmve.fsf@HIDDEN>
 <c3b1445d236ed95f768c218503089926788256a4.camel@HIDDEN>
 <87sepirfez.fsf@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, 75552 <at> debbugs.gnu.org, 45mg <45mg.writes@HIDDEN>,
 help-guix@HIDDEN, Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Am Donnerstag, dem 16.01.2025 um 15:39 +0100 schrieb Tomas Volf:
> Liliana Marie Prikler <liliana.prikler@HIDDEN> writes:
>=20
> > [..]
> >=20
> > > Then there is anything modifying any of the guix commands.=C2=A0
> > > #74832 is over month old, and as far as I know, I am not able to
> > > fix guix-copy from a channel.=C2=A0 #72928 took over a month to merge=
,
> > > and again, not sure how to patch guix-describe from a channel.
> > Have you considered extensions?
>=20
> Took me a while to figure out what you mean.=C2=A0 Apparently there is a
> $GUIX_EXTENSIONS_PATH environment variables that can be used to add
> sub-commands (does not seem to be documented at all in the manual?).
> Maybe I am looking into wrong place.
Good point, we do lack documentation for that.  It was mentioned in a
blog post IIRC, but newcomers won't necessarily find that.

> If I understand it correctly, I could copy&paste the current code for
> `guix describe' and add it as `guix describe*' with my modification.
> However it feels bit convoluted.
In practice, you import the module and then add your changes on top
with the minimum amount of work possible.  E.g. for `guix describe*`,
you could first run `guix describe` and then print your own output
afterwards.

> All of these things discussed in this thread are technically
> possible.  But I think that we all agree that the friction involved,
> compared to just using my own fork with the patch applied, is much
> larger, at least in my opinion.
Yes, we can agree that this is your opinion.  We can even agree that
there is more friction, but I'm not sure whether we agree on the value
of "much".  But honestly speaking, the friction with contributing to
upstream is much more a social one (too few people to review) than a
technical one, and soft forks are a band aid that will likely burn you
out even sooner the more you commit to them.

Cheers




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 16 Jan 2025 17:30:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 12:30:00 2025
Received: from localhost ([127.0.0.1]:34518 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYTgs-00004x-Tt
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 12:30:00 -0500
Received: from mail-pj1-x1043.google.com ([2607:f8b0:4864:20::1043]:56414)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <45mg.writes@HIDDEN>)
 id 1tYTgp-0008WL-OW
 for 75552 <at> debbugs.gnu.org; Thu, 16 Jan 2025 12:29:57 -0500
Received: by mail-pj1-x1043.google.com with SMTP id
 98e67ed59e1d1-2ef89dbd8eeso1714833a91.0
 for <75552 <at> debbugs.gnu.org>; Thu, 16 Jan 2025 09:29:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1737048589; x=1737653389; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
 :reply-to; bh=Y23cD3pMpwEm1WVDZpONgdBF9h1rj4MV6wCL3d/OZvY=;
 b=LDPn4xrimoUNeQmARBg6oPIpszwUMd0LGevP8EmNiYLf14egXjfWY42OM3OvHsn6Mw
 VXXLXWBl6BRTOkhK2x5aoS4q2jWqQqJrJht0sGu3p5KGkd6ZjdXElSlCzclKP6I5qVCN
 SfEvyXYJHEgco0OU0toYDEWjfCGbbHwyGNzKZI3Yn7lwldaOPgOCmaM6ct7O+zd88ITM
 65KCk22L8ADd69neT2R4lcFF9zsHJXUeE+eVk5H+hY+oWKBUYVMw4TnCrvq3LfOpwN/T
 PcFRzbJvpaIkqcESLFzImYJhK1bchMLilf+UMW0jbF0HlYDVeDa6zQBzhoZV38M8bR6P
 e7Lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1737048589; x=1737653389;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=Y23cD3pMpwEm1WVDZpONgdBF9h1rj4MV6wCL3d/OZvY=;
 b=D12THXdkKBVhDqStMtWsZFEt9oYIxDJHsjsqGpPMvzZzq4zRc2rzowFE72nvzTMslY
 ZwUYAZfpDPZx6DF55rPer7Ig1E/bokWrP3NfvIpByhkX2D8SZAWWP7ESWMr7DHKmM8Hd
 VM7d/OKYCtrRS5BF3qKx21X4aWY7kNoYYikXSJxQcSG8pElvSKnIzD7JKzgPC64ytYlb
 uvrJ9Ct0zqQfp0K+DNm37UckySbvFSTKZzxQgteNbbAIX29ExlSUfCq6/mCJY41v58Ib
 6S+snxCK0F2OfqW+zWg4cvRwpojCoc8aaOO5FFhtAUybrv1sQzTWh4spSW/4wTYsi40z
 C2tA==
X-Forwarded-Encrypted: i=1;
 AJvYcCVRerR+he6qN+Or0pPC0jfXvT91BUlF0FI+2TQ5ppxoXs504SueGIkV2nF20gFIX4yx8SPGSA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yyyp96+nEBt6S+GR7XjPNceupcrAPIERAnpNTMDpQaY2g/FUxZt
 j4msNy0FF+aLhTZExJGiMYQi32l6HEV4ymGDa3Qcp9nRRErtS6S8
X-Gm-Gg: ASbGncuTfxz5JrTMVbDL+IJDNJ20Vcg3o6yR15lSmThmxGgp+1Pa0B55oUtq1Z5yjJc
 pnBo2Fq7Fa1hR9KBX5Cda7D8wvkv+LBZQxJmuVZ7O9PaYrg9BcPgMLFVgMNdapiwSOV0SQ55lwD
 iHAx8Laf7M5UmbkauoL1XKZiNFcL+ywickr5zVzXQRGXq4QFvZvGa7BBQxMhbP/0mUbSIwJrfKN
 /ONmxn/+94vo/0q2WXoCoNy8TzPKXH0RS1q3hZzC4fm+CNuJINpEFw2Vg==
X-Google-Smtp-Source: AGHT+IFv4cp89LQqYIQhIzEseftDs5UfHkCErskg9eWAIr/8U9PF+b0yv1Wy1MmmD6I+Zz9SMgrIJw==
X-Received: by 2002:a17:90b:4d05:b0:2ee:599e:f411 with SMTP id
 98e67ed59e1d1-2f548f7d21dmr42039318a91.34.1737048589060; 
 Thu, 16 Jan 2025 09:29:49 -0800 (PST)
Received: from guix1 (utm3.nitt.edu. [14.139.162.2])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f77619317fsm386208a91.22.2025.01.16.09.29.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 09:29:48 -0800 (PST)
From: 45mg <45mg.writes@HIDDEN>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 45mg
 <45mg.writes@HIDDEN>, 75552 <at> debbugs.gnu.org
Subject: Re: Non-committers can't keep authenticated forks updated
In-Reply-To: <ef18ee3dc4813b20fe40c21ec0f03e856acdb9a0.camel@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87v7uerjk9.fsf@HIDDEN>
 <ef18ee3dc4813b20fe40c21ec0f03e856acdb9a0.camel@HIDDEN>
Date: Thu, 16 Jan 2025 17:29:42 +0000
Message-ID: <87cygmmzuh.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, Tomas Volf <~@wolfsden.cz>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@HIDDEN> writes:

> Am Donnerstag, dem 16.01.2025 um 13:10 +0000 schrieb 45mg:
>> As the 'Authenticate Your Git Checkouts'
>> blog post [9] pointed out, we wouldn't need `guix git authenticate`
>> if we were willing to delegate our security to a trusted third party,
>> like all the open source projects that sport those "fancy =E2=80=9C=E2=
=9C=85
>> verified=E2=80=9D badges as found on GitLab and on GitHub" do. We should=
n't
>> force anyone hosting a fork to do so as well.
> I mean, you can host your own fork and use the fancy =E2=80=9C=E2=9C=85 v=
erified=E2=80=9D badge
> of your host as source of trust =E2=80=93 it just won't be checked by `gu=
ix
> pull', that's all.  If you do do that, I'd recommend using a file://
> URI with a local checkout for your channel, so that you can verify that
> little check mark on your own (then you only need to trust your own
> file system).

Yeah, I know I can. My point is that people who use remote forks
shouldn't have to rely on a trusted third party. We've figured out a way
for upstream Guix not to have to, now let's try to extend that to forks.

>> > I think you're making this more complicated than it needs to be.=20
>> > checkout, authenticate, rebase*, merge*=C2=A0ought to have you covered.
>> >=20
>> > * you can authenticate after these if you're paranoid=20
>>=20
>> The complexity is due to the requirements of not bumping the channel
>> introduction (to avoid the increased attack surface from having to
>> keep obtaining the updated one, as I discussed earlier), keeping fork
>> history intact (to avoid force pulls), keeping upstream history
>> intact, and being able to authenticate both upstream and fork
>> commits. If you can think of a simpler method that meets these
>> requirements, I'd love to hear it.
> Guix committers are more than happy to use work trees and rebases,
> which simplify this a lot =E2=80=93 again, it's as simple as pull,
> authenticate, rebase.

No doubt this works for those with commit access. The title of this
issue is 'Non-committers can't keep authenticated forks updated'.

Since most future committers will take years to attain that status, and
many (most?) Guix contributors can't commit (heh) to being committers, I
think it would be a good thing for them to be able to make use of our
security mechanisms.

(Actually, if you mean the variant of rebasing you describe below, then
I see what you mean, never mind)

> W.r.t. keeping history intact, we had the following exchange on IRC
> yesterday.
>
> <Rutherther>	lfam: that's interesting that there is really a merge
> commit, for example if I remember right, the core updates merge few
> months ago happened by directly appending the commits instead of a
> merge commit
> <lfam>	Yes, there are two ways to do it (rebase and merge) and it's a
> matter of taste
> <lfam>	Of course there is a correct choice, as with all questions of
> taste ;)
> <Rutherther>	I personally prefer a merge commit, since it has two
> parents, you can track where the previous master pointed to
> <lfam>	And I prefer a rebase. But ultimately it's up to whoever is in
> front of the keyboard
> <lilyp>	FWIW, a rebase is cleaner, but requires that only one person
> signs off commits on any given branch (or else you're signing commits
> that someone else signed before and have to update the trailer=E2=80=A6 n=
ot
> ideal)
> <lfam>	It doesn't matter who signs the commits as long as they are
> authorized. That's the security model we have
>
> So yeah, even for (branch-)local work at least some committers prefer
> rebasing.

That seems to be a discussion about a merge commit in upstream Guix, not
about the kind of merge commits that I'm trying to allow.

Again, not disputing that things work fine for people with commit
access. Perhaps that is part of why this issue hasn't been addressed
before :P

>> > No, it wouldn't.=C2=A0 You would rebase those changes on top of what y=
ou
>> > already have on those respective branches.
>>=20
>> It looks like at least one of us is misunderstanding rebasing. Could
>> be me, so I'm consulting the relevant chapter from the Pro Git book
>> [11] for a refresher.
>>=20
>> Let's imagine that the first example given there represents our fork
>> of Guix, where the 'experiment' branch marks the beginning of our
>> fork (and its channel introduction) and the 'master' branch tracks
>> upstream Guix.  After `git rebase master`, the commit that used to be
>> C4 is gone, and now C4' takes its place. It may contain the same
>> changes, but it's a different commit - so it (and any commits that
>> it's the parent of) has a different hash. So the channel introduction
>> has changed, and so has the entire history of the `experimental`
>> branch. So we need to force-pull.
> Yes, that's one variant =E2=80=93 the one where you need to keep bumping =
your
> channel introductions.  The other direction would be to rebase Guix
> changes on top of your local branch.  This keeps your channel
> introduction as-is.

Ah, I see. Actually, I think that might work... if I create a
'upstream-backup' branch before rebasing, and reset the 'upstream'
branch to that branch after, I can keep the full history of upstream,
and authenticate it separately. And thanks to Ricardo's suggestion [12]
to compare by Change-ID, it should even be possible to find corresponding
commits between my fork and upstream. Looks like this solution meets all
four requirements that I stated earlier, and it wouldn't be TOO annoying
or complicated to script either.

One limitation I can think of is that you can't really verify whether a
commit ostensibly rebased from master is actually the same commit
(imagine 100 commits in a rebase, are you going to check the diff for
each? Versus with a merge you only have to check that the merge commit
looks sane). Then again, this is really only a problem if you're using
someone ELSE's fork and need to ensure they've not gone mad or evil,
which is not my personal use-case, and perhaps not that common.

You know what, I think I'll give it a try. If there aren't any unforseen
complications, then this solution may be good enough for me, and perhaps
good enough to add to the documentation as a recommendation so that
others don't have to puzzle this out themselves. Thanks for giving me
the idea!

(At any rate, feel free to reply to my points here in the meantime; If
it turns out that the rebase workflow is insufficient for some reason
then I can pick up where we left off)

>> > >=20
>> [=E2=80=A6]
>> This led my to think of an attack that's possible with my design - if
>> I want to screw with anyone `guix pull`ing from my fork, I can merge
>> upstream into my fork branch, add a bunch of malicious commits, and
>> then make the upstream branch ref point to the latest such commit.
>> Now anyone pulling from my fork will recieve the malicious commits as
>> part of upstream's history - since no commit hashes needed to change,
>> the pull is a regular fast-forward one, with no indication that
>> anything is amiss. Authentication will succeed since the malicious
>> merge commit has our fork as its (first) parent, and that parent has
>> the primary introduction as its most recent ancestor.
>>=20
>> The takeaway here is that anyone authorized via the primary
>> introduction can fake new upstream commits.
> Care to state how designating one introduction as "primary" adds to
> security here?=20=20

The problem I'm trying to solve is that you can't merge upstream into
your fork unless you sign the merge commit with a key authorized in
upstream, because of the intersections-of-parent-authorizations design.
Tomas's solution was to do away with the 'intersections' requirement,
and allow a key that's authorized for any parent to sign the merge
commit; this is vulnerable to attacks like [4]. My solution falls
somewhere in between - we keep the 'intersections' requirement, /except/
when one of the parent commits is a descendant of an introduction
designated as the 'primary introduction'.

If you drop the 'primary introduction' designation (make all of them
'primary'), then you're basically dropping the intersections
requirement. IOW, we've returned to the situation in Tomas's
solution, where [4] is possible - anyone with even a single signed
commit in Guix can now create a merge commit between Guix and your fork,
even if their key was later removed from Guix.

>> So why bother with additional introductions at all, then? Because as
>> far as I can tell, they are still the only solution mentioned so far
>> that satisfies the requirements I mentioned earlier:
>> > not bumping the channel introduction (to avoid the increased attack
>> > surface from having to keep obtaining the updated one, as I
>> > discussed earlier), keeping fork history intact (to avoid force
>> > pulls), keeping upstream history intact, and being able to
>> > authenticate both upstream and fork commits
>> ...and yes, you do have to trust the fork maintainer to not
>> deliberately mess those things up. But that's nothing new - even in
>> the existing design, we have to trust everyone who can make trusted
>> commits not to mess things up on purpose.
> You are trading one attack surface for another.  Again, all is fine
> while you only have to trust yourself, but weakening an invariant is
> weakening an invariant (:

Which attack surface am I introducing or worsening? The 'authorized
committer can mess things up' attack surface was already /there/. The
attack I described does not make it worse AFAICT - its potential impact
is to compromise the ability to easily authenticate all upstream and
fork commits in one go, but that ability is not something we previously
had in the first place.

>> So what does this all of this mean for the statement of my design?
>> Well, it means that we need to stop thinking in terms of 'which
>> branch can be merged into which?' and more in terms of 'which merge
>> commits can be authenticated?'. And the answer to that question, with
>> my design, would be:
>>=20
>> 1. Any merge commit signed with a key in the intersection of its
>> =C2=A0=C2=A0 parents' .guix_authorizations. (Standard authorization inva=
riant.)
>>=20
>> 2. Any merge commit that doesn't meet the above conditions, but has a
>> =C2=A0=C2=A0 parent whose most recent ancestor is the primary introducti=
on, and
>>    is signed by a key in the .guix_authorizations of that parent. (My
>> =C2=A0=C2=A0 weakened authorization invariant.)
> That's a pretty long way of saying "Any merge commit signed with a key
> in one of its parents' .guix_authorizations."

Not quite. Merge commits between upstream Guix and your fork, whose
signing key is in the .guix_authorizations of its parent in upstream but
not in the .guix_authorizations of its parent in your fork, would not be
authenticated. (This is the kind of merge commit that would be used for
[4].)

> It is (by your design) trivial to have the "primary introduction"
> under your control.

Yes, as long as you're using your own fork this will be the case.

>> Finally, let me restate the conditions for authenticating merge
>> commits, taking this into account:
>>=20
>> --8<---------------cut here---------------start------------->8---
>> For commits that have multiple parents - ie. merge commits - we
>> weaken the invariant as follows:
>>=20
>> 1. If all parents have the primary introduction as their most recent
>> =C2=A0=C2=A0 ancestor, then the invariant holds as usual.
>> =C2=A0=C2=A0=20
>> 2. If one or more parents has the primary introduction as its most
>> =C2=A0=C2=A0 recent ancestor (call these the 'primary parents'), and the=
 rest
>>    have any of the additional introductions, then the merge commit is
>> =C2=A0=C2=A0 authenticated if and only if it's signed by a key authorize=
d in=20
>>    all of the primary parents.
>> =C2=A0=C2=A0=20
>> 3. If all parents have the same additional introduction as their most
>> =C2=A0=C2=A0 recent ancestor, then the invariant holds as usual.
>> =C2=A0=C2=A0=20
>> 4. If none of the parents have the primary introduction as their most
>> =C2=A0=C2=A0 recent ancestor, nor do they have the same additional
>>    introduction, then the merge commit cannot be authenticated.
>> --8<---------------cut here---------------end--------------->8---
>>=20
>> I merged 2a. into 2., and removed 2b.
>>=20
>> Now let me try to respond to you:
>>=20
>> > Yeah, I think this scheme will still end up in [4].=C2=A0 As pointed o=
ut
>> > in [8], "primary" is just a convention that we can't rely on.
>>=20
>> Not really. As I discussed, [8] points out that /merge order/ is the
>> convention that we can't rely on. Introductions can be deliberately
>> specified as primary or additional, whether via command-line flags or
>> separate sections in .git/config.
>>=20
>> > So let's just talk about the idea of widening one channel
>> > introduction to any number of channel introductions =E2=80=93 we can a=
lways
>> > store a mapping of HEAD =E2=86=92 first authenticated commit and then
>> > assert that this set is a subset of what we declare as
>> > introductions. =C2=A0(This mapping will also make authentication as
>> > efficient as it currently is, since we don't need to reauthenticate
>> > everything all the time.)
>>=20
>> I'm not sure what you mean. What do you mean by "mapping of HEAD =E2=86=
=92
>> first authenticated commit"? Does this perhaps mean 'all commits
>> between the latest one and the first authenticated commit'?
> Little refresher: Guix stores a list of already authenticated commits
> so as to not redo this work all over again.  If we were to allow
> multiple introductions, we would also need to find the first
> authenticated commit among them to match against the channel
> introductions.

Ok, so I guess you meant what I thought you did.

We can cache the introduction of each commit. In fact, that could
actually help block the attack I described in my previous mail [12], as
in that attack the introduction for all the upstream commits suddenly
changes to the primary introduction; if we manage to detect this, the
conflict with the cached introduction can tell us that something is off.
It's not a real defense as it wouldn't work on a fresh clone, but it's
something, at least.

>> What does "assert that this set is a subset of what we declare as
>> introductions" mean?
> Let's say that you work on branches B, C, and D with "primary"
> introductions I, J , and K.  If you want to merge C into B, you need to
> remember that B has I as its primary introduction, C has J, and so on.

Ah, got it. Yes, that's correct. (Except that there's only one primary
introduction, at least as I intended it.)

>> > Is this good enough?=C2=A0 No: an attacker could easily add their own
>> > introduction and call it a day.=C2=A0 In fact, this scheme is even wor=
se
>> > than what was exploited in [4], because they never need commit
>> > access to the Guix repo to do so.=C2=A0 Ahh, but wait!=C2=A0 `guix pul=
l` on
>> > the user's side uses their clean set of channels for
>> > authentication.=C2=A0 Those only have upstream Guix=E2=80=A6 unless yo=
u actually
>> > pull your own fork or manage an attack as outlined below (in which
>> > case you do need commit access for some amount of time).
>>=20
>> I should point out - my design does not require us to distribute any
>> introductions besides Guix's existing one, nor will it provide any
>> mechanism to automatically 'install' someone else's introduction.
> Yes it will, per `%default-guix-channel'.

Ok, technically true. And someone with the ability to make trusted
commits upstream could modify that so that a fresh `guix pull` skips
whatever malicious stuff they've done. But my solution doesn't make this
situation any worse AFAICT.

>> An introduction is a tuple of (introductory commit, key that signs
>> it) that you specify as arguments to `guix git authenticate`. An
>> attacker would have to convince the entire Guix community to specify
>> their (the attacker's) own introduction on the command line (or
>> directly add it into .git/config). And given that there is no reason
>> to ever do so unless you're using someone's fork... that's a hard
>> sell.
> Well, another hard sell would be introducing a feature to `guix git-
> authenticate` that must not ever be used in Guix itself.  Now, since
> you are already soft-forking Guix, you can obviously add this to your
> own guix command, but do beware the dragons you're summoning with it.

By that logic, we would never have gotten the ability to specify
multiple channels, since that isn't used in upstream Guix and doesn't
need to be.

> Cheers

[12] https://lists.gnu.org/archive/html/bug-guix/2025-01/msg00130.html
[13] https://lists.gnu.org/archive/html/bug-guix/2025-01/msg00135.html




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 16 Jan 2025 14:39:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 09:39:53 2025
Received: from localhost ([127.0.0.1]:60578 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYR2H-0000CR-Fp
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 09:39:53 -0500
Received: from wolfsden.cz ([37.205.8.62]:45382)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <~@wolfsden.cz>) id 1tYR2E-0000CH-Rw
 for 75552 <at> debbugs.gnu.org; Thu, 16 Jan 2025 09:39:52 -0500
Received: by wolfsden.cz (Postfix, from userid 104)
 id 2D69334EEC2; Thu, 16 Jan 2025 14:39:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail;
 t=1737038389; bh=TugX07lGpw1KZauAAQrm2LCoV5ZTb1/ChHFTBf9z00w=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=E01x+CRavd1N6jSzIaYHkvAasIFgE701sIba8HZgVO0IXl08ELkDA7LFKt9nd0PNR
 W++RZdwaksxb75WNdgXtGL0t7Xykkhq2IiVAOxgjwxWoj6U/m74AI/MoGpMfzTsJY7
 ZGq9qNyYc6ABQJVmQR1rqRXFECyZRJD+yt+JPcwBspvpVjX+Gxci+X1Z5d6gBR6BFB
 9nbZ0RjxXq8FlR8dFJNCVsZutpblc9NMnnKRUFC6cLppGhEwOHM28Cvks2Zx42JM9U
 H4L9yXaMJmwdFmpvCvcqeAq1vN/7BhAVGSXpDqndT76uOnyAzPiPss5QzRjDvTV5ny
 yEbHiJ7dlDhJ0hrUrSN5iNR1lrqe6lx8YxkKlyE4qk1AT7NkZXVPmLcPUktZ1L83wI
 rTTqkLsgjgQCzlFj6SGOFTJlYgMWpZUmKG9vv5M8Ycs5P5BK4WUzTg08FKtbl8kl2A
 SkC2W1ZyaIwcoHQjMCK3oyuDGmrE3Yr2RtvmS+pfULA/X1mmdeUui6HKoGcZPBCejW
 ZBvuZo8L56qH/QuMuWcqL2PW1DHrHai6vsed0pHihpoalz889MoOG6fTkiY+HApXrV
 hs771t061jUcfaiett8X8IjXYhR59eRYA3x1PUFuLC62hP9Yylrlod9TakY332Uyeb
 BrLi7ZBscXj23ZzVhfqs9y2U=
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on wolfsden
X-Spam-Level: 
X-Spam-Status: No, score=-3.1 required=5.0 tests=ALL_TRUSTED,BAYES_00,
 DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_BLOCKED
 autolearn=ham autolearn_force=no version=3.4.6
Received: from localhost (unknown [128.0.188.242])
 by wolfsden.cz (Postfix) with ESMTPSA id C6B9334FDC7;
 Thu, 16 Jan 2025 14:39:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail;
 t=1737038388; bh=TugX07lGpw1KZauAAQrm2LCoV5ZTb1/ChHFTBf9z00w=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=RtC6KdrE4xUJGK/WyE4OscRQbvFVQbZaHiK1w6vfD+22THdoT36UU6NqaHcVmZtGK
 v0hulMgfuv3YMFJPjIJG31su/anAlg+oYHrh2yf8Lz+8iS+2hO02hizMUWc3zDNn9W
 MNLKsS9AQWrd4Xg3whxKruwp7pyDBJRV9ysDOx+N0ao9r8G88Sy42v/BYpq4VEM6QD
 2e6BX8DSvZaztph/QrpIjPRDKcFz1RQTcsKwxGjv8Ebjfxe3Fdr9IEm13iqoquLCHL
 bzoxzP+H1ge40w2IsRnJZsM2ByN2D0fEXu55WGzqy6E3f06AtrmROVDTnwUrKR8/N8
 HoOwfxjX15of8t4/R9NkeQxrrqAO2o9/dVi0r5A8V5VA2HleGjuBdqQ72P4PYZjxo0
 m8roNKrhMoBUIqzSf58kTm4Xc1ognU69BrDR89Z6mig5bRdX+f8mQmP6H5x3tLIeOM
 lRt1aM8uKH7ciTjPeEGgUuD14cTOz7kVzaujMn7gHjxFaqqjoi0zGONUi7wH2BQxu4
 9tgMz7zIcTH6jEB/tCtzp89iv0g3BUYdLTD8ZhJtvKot+kvuts35fw5dz3jg+vl6qs
 FdZRthAd3wnC+z7cMVCVefkfaper+zmnejcCO6x25K7aZGi24dvr6/HIeFyjQ0f/5I
 k8c7O+KzX9Z1NPeY4cAiHu3g=
From: Tomas Volf <~@wolfsden.cz>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Subject: Re: Non-committers can't keep authenticated forks updated
In-Reply-To: <c3b1445d236ed95f768c218503089926788256a4.camel@HIDDEN>
 (Liliana Marie Prikler's message of "Thu, 16 Jan 2025 08:38:59 +0100")
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87a5brsmve.fsf@HIDDEN>
 <c3b1445d236ed95f768c218503089926788256a4.camel@HIDDEN>
Mail-Followup-To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 45mg
 <45mg.writes@HIDDEN>, 75552 <at> debbugs.gnu.org, guix-devel@HIDDEN,
 help-guix@HIDDEN, Felix Lechner <felix.lechner@HIDDEN>
Date: Thu, 16 Jan 2025 15:39:48 +0100
Message-ID: <87sepirfez.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, 75552 <at> debbugs.gnu.org, 45mg <45mg.writes@HIDDEN>,
 help-guix@HIDDEN, Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Liliana Marie Prikler <liliana.prikler@HIDDEN> writes:

> [..]
>
>> Then there is anything modifying any of the guix commands.=C2=A0 #74832 =
is
>> over month old, and as far as I know, I am not able to fix guix-copy
>> from a channel.=C2=A0 #72928 took over a month to merge, and again, not
>> sure how to patch guix-describe from a channel.
> Have you considered extensions?

Took me a while to figure out what you mean.  Apparently there is a
$GUIX_EXTENSIONS_PATH environment variables that can be used to add
sub-commands (does not seem to be documented at all in the manual?).
Maybe I am looking into wrong place.

If I understand it correctly, I could copy&paste the current code for
`guix describe' and add it as `guix describe*' with my modification.
However it feels bit convoluted.

All of these things discussed in this thread are technically possible.
But I think that we all agree that the friction involved, compared to
just using my own fork with the patch applied, is much larger, at least
in my opinion.

Tomas

=2D-=20
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJCBAEBCgAsFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmeJGjQOHH5Ad29sZnNk
ZW4uY3oACgkQL7/ufbZ/wakPvxAAnJTWXpFzfV63TfdI7hVrtdka/zMQmvv994g6
Dz1yAyX+p9Xvj/uzlRnoS2o49wZMcYs4BvjErb3VO1gqRUA8iJT3NsrBjqyVq96U
vOw3Z+MnfyWmcUK+QVyI8ECzo6NdCPS2CLBC2JdvobDN+++Ha2PrT6WI5enAxAFf
Hg2z0WG4YdDqczBvZFw/4HwPDQF4eHnV2X1UV+r6qAWXP/sKGEH3hhHtNq9lIsT7
Mm8B1Totcfmvr6eTGMis9QnaUQPhXumgb6djGbutVk3pDeNVq43taJEtv0KxDvLO
sJVgv2H6lq+29D/iF94MYmcj6ig6sPHRmgvobs5VXWbbL0pP2/aOzGhtO/vZ1LBf
VBYVQC+aclQNpNglWWWr5dk05L2GC0NLYk0bSwqozpcc4jZc0ZMwUrNXymxfFU8c
6ofY9RopOg8sY86XSw94sXfInYXMg9xOAHjeNAys8H2U9uTMWuVdHrgXhuFBUyHZ
LyJOdtrbzMVdF6qTdIg5C3K4rJxW8+RRf/qQjZXqP8MAiLdboPo1LNMHB6da6lrg
QOgo3WBZ3qBWW7FwTZruQcVKMvsboxHTgWLStH14qcbvkFmqL9bxrf2MvK7XDzAC
i00Juit/94xiotGPXYYig2UQTMW/oYW1bU8u8GqRwZpTOTCxEni0t811kouv2sjb
JDBkTNk=
=XR2J
-----END PGP SIGNATURE-----
--=-=-=--




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 16 Jan 2025 14:34:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 09:34:35 2025
Received: from localhost ([127.0.0.1]:60546 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYQx8-0008OX-65
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 09:34:35 -0500
Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]:57545)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <liliana.prikler@HIDDEN>)
 id 1tYQx4-0008OD-Ak
 for 75552 <at> debbugs.gnu.org; Thu, 16 Jan 2025 09:34:32 -0500
Received: by mail-wm1-x343.google.com with SMTP id
 5b1f17b1804b1-4362f61757fso9383015e9.2
 for <75552 <at> debbugs.gnu.org>; Thu, 16 Jan 2025 06:34:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1737038064; x=1737642864; darn=debbugs.gnu.org;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
 :date:message-id:reply-to;
 bh=nn6lHE4HE5lOxvyNGG/DpKlu25Z3qsPUxTPxBXk+hf4=;
 b=XcpZ5arp72zGlaE+dp9qJacgk782oHpq76XogXwprmN0ulDwrNafo+U/dpsv9060LU
 JhLxOgH4TVi8H+0A4gZmyiLv9y2MLBZ9yWPlVzZ8t/6UrKFp3CFdnMD7DkB5JJi1xoFq
 oym5gNh3UgKqFJp9JzcQgVVeErG/HyH4X6nj4OyGKqN6o/9dYryYqGsS7sgvZSerD9+c
 fd/uEveb0uNzTmU2HYOYznEMp5GZOiQayjeKzVN74zT1vFi74gtGlN821kGpXaEQboz6
 f10xU9u2S3DEof/ocKvTRk7bad6AMl9b6yXJNf3CNeS+/7wfhtVNT+tGTfTyoplpJbSY
 +cFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1737038064; x=1737642864;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=nn6lHE4HE5lOxvyNGG/DpKlu25Z3qsPUxTPxBXk+hf4=;
 b=Yu/GTQGhjDleMaSSLwsabx0T0cXkOuqX4yAoXS8gq0XRVWvYciqVznHnzrmLO8Mi0G
 UbA4I3tI183ZKI+dpxf81OFtCOgKYLNeXKGZbqPqkcaRu/G6wdM8QMVdvGmdEzfY3cCN
 fjTpzNN42iFUhdKRukgHoZWxYFStvGnmgn8v3ssk3BHo11vJdg+VeJxwWe7aEsYBx5j3
 EQovh7oHbg0fSHyO75OBsTBrFV1tJgoqZGfO2NBrCTbBbyrOhhStMXidS7Ej2PTIXSdI
 un8pXtdoYGf1iMNN2CG4pqpbdrN0ebUHsmR8DLkPs6Lx9Hzijc3DO471fKwRwNNoSaSM
 3y4Q==
X-Forwarded-Encrypted: i=1;
 AJvYcCWQKm+0eLWhvRBiDcf6/uN+WUd1b/02ex0gw2ZjIxv4mfa/oNEEPWrqp77xdSwTJWqmoB/jtw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyvysKfqXXG9MmU9TkmZrPThr4FiIIkVps9E3TxZ178/7yO8fiK
 S9DfK9ZnKa8H/5ERFFMr/dhr+2bCa1SIOb5VwyubqhO2sJ6YCP7Iwyre4FWG
X-Gm-Gg: ASbGncsAvOabXXk7zFUH8OX2SqpTrlL8bhGlC/YEvOQyqiqtYRWeYIz7+oVo7RLKN9N
 h9e8KHvNb6CVuD1Mrcx0XNFTdaoFDtG/2RAk9oPcxfP/ZprG+ke62JSgsHPS65yg8wJL5hxuhkc
 /65RUlKTJG7Yklr8GnLnQkh1ek51ojnfl8hqRBEnyd2k81Y3lH4W4VzikLSmsICS+BMthmLbIym
 URfkpoibvt+yH065RV00LpA0Bmc1f2eAXs6TVGDbE1OaWmxiakg9jnWiVHAIXf6XiBCNlKa2HLo
 JR/5PFiwKLsxvJUyIIaskHnLLSs/wW9h
X-Google-Smtp-Source: AGHT+IFDu1Lq5daAHjNP0km+NfDa4613xO86/I54LM1rEIQ5tmeyxKg3mUX5G5qXNk7p97/rsMgpkw==
X-Received: by 2002:a05:600c:4745:b0:434:9c60:95a3 with SMTP id
 5b1f17b1804b1-436e26c4219mr102492275e9.11.1737038063511; 
 Thu, 16 Jan 2025 06:34:23 -0800 (PST)
Received: from lumine.fritz.box (85-127-114-32.dsl.dynamic.surfer.at.
 [85.127.114.32]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c74ac712sm60586175e9.12.2025.01.16.06.34.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 06:34:23 -0800 (PST)
Message-ID: <ef18ee3dc4813b20fe40c21ec0f03e856acdb9a0.camel@HIDDEN>
Subject: Re: Non-committers can't keep authenticated forks updated
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
To: 45mg <45mg.writes@HIDDEN>, 75552 <at> debbugs.gnu.org
Date: Thu, 16 Jan 2025 15:34:28 +0100
In-Reply-To: <87v7uerjk9.fsf@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87v7uerjk9.fsf@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, Tomas Volf <~@wolfsden.cz>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Am Donnerstag, dem 16.01.2025 um 13:10 +0000 schrieb 45mg:
> As the 'Authenticate Your Git Checkouts'
> blog post [9] pointed out, we wouldn't need `guix git authenticate`
> if we were willing to delegate our security to a trusted third party,
> like all the open source projects that sport those "fancy =E2=80=9C=E2=9C=
=85
> verified=E2=80=9D badges as found on GitLab and on GitHub" do. We shouldn=
't
> force anyone hosting a fork to do so as well.
I mean, you can host your own fork and use the fancy =E2=80=9C=E2=9C=85 ver=
ified=E2=80=9D badge
of your host as source of trust =E2=80=93 it just won't be checked by `guix
pull', that's all.  If you do do that, I'd recommend using a file://
URI with a local checkout for your channel, so that you can verify that
little check mark on your own (then you only need to trust your own
file system).

> >=20
> > I think you're making this more complicated than it needs to be.=20
> > checkout, authenticate, rebase*, merge*=C2=A0ought to have you covered.
> >=20
> > * you can authenticate after these if you're paranoid=20
>=20
> The complexity is due to the requirements of not bumping the channel
> introduction (to avoid the increased attack surface from having to
> keep obtaining the updated one, as I discussed earlier), keeping fork
> history intact (to avoid force pulls), keeping upstream history
> intact, and being able to authenticate both upstream and fork
> commits. If you can think of a simpler method that meets these
> requirements, I'd love to hear it.
Guix committers are more than happy to use work trees and rebases,
which simplify this a lot =E2=80=93 again, it's as simple as pull,
authenticate, rebase.

W.r.t. keeping history intact, we had the following exchange on IRC
yesterday.

<Rutherther>	lfam: that's interesting that there is really a merge
commit, for example if I remember right, the core updates merge few
months ago happened by directly appending the commits instead of a
merge commit
<lfam>	Yes, there are two ways to do it (rebase and merge) and it's a
matter of taste
<lfam>	Of course there is a correct choice, as with all questions of
taste ;)
<Rutherther>	I personally prefer a merge commit, since it has two
parents, you can track where the previous master pointed to
<lfam>	And I prefer a rebase. But ultimately it's up to whoever is in
front of the keyboard
<lilyp>	FWIW, a rebase is cleaner, but requires that only one person
signs off commits on any given branch (or else you're signing commits
that someone else signed before and have to update the trailer=E2=80=A6 not
ideal)
<lfam>	It doesn't matter who signs the commits as long as they are
authorized. That's the security model we have

So yeah, even for (branch-)local work at least some committers prefer
rebasing.

> > No, it wouldn't.=C2=A0 You would rebase those changes on top of what yo=
u
> > already have on those respective branches.
>=20
> It looks like at least one of us is misunderstanding rebasing. Could
> be me, so I'm consulting the relevant chapter from the Pro Git book
> [11] for a refresher.
>=20
> Let's imagine that the first example given there represents our fork
> of Guix, where the 'experiment' branch marks the beginning of our
> fork (and its channel introduction) and the 'master' branch tracks
> upstream Guix.  After `git rebase master`, the commit that used to be
> C4 is gone, and now C4' takes its place. It may contain the same
> changes, but it's a different commit - so it (and any commits that
> it's the parent of) has a different hash. So the channel introduction
> has changed, and so has the entire history of the `experimental`
> branch. So we need to force-pull.
Yes, that's one variant =E2=80=93 the one where you need to keep bumping yo=
ur
channel introductions.  The other direction would be to rebase Guix
changes on top of your local branch.  This keeps your channel
introduction as-is.

> > >=20
> [=E2=80=A6]
> This led my to think of an attack that's possible with my design - if
> I want to screw with anyone `guix pull`ing from my fork, I can merge
> upstream into my fork branch, add a bunch of malicious commits, and
> then make the upstream branch ref point to the latest such commit.
> Now anyone pulling from my fork will recieve the malicious commits as
> part of upstream's history - since no commit hashes needed to change,
> the pull is a regular fast-forward one, with no indication that
> anything is amiss. Authentication will succeed since the malicious
> merge commit has our fork as its (first) parent, and that parent has
> the primary introduction as its most recent ancestor.
>=20
> The takeaway here is that anyone authorized via the primary
> introduction can fake new upstream commits.
Care to state how designating one introduction as "primary" adds to
security here? =20

> So why bother with additional introductions at all, then? Because as
> far as I can tell, they are still the only solution mentioned so far
> that satisfies the requirements I mentioned earlier:
> > not bumping the channel introduction (to avoid the increased attack
> > surface from having to keep obtaining the updated one, as I
> > discussed earlier), keeping fork history intact (to avoid force
> > pulls), keeping upstream history intact, and being able to
> > authenticate both upstream and fork commits
> ...and yes, you do have to trust the fork maintainer to not
> deliberately mess those things up. But that's nothing new - even in
> the existing design, we have to trust everyone who can make trusted
> commits not to mess things up on purpose.
You are trading one attack surface for another.  Again, all is fine
while you only have to trust yourself, but weakening an invariant is
weakening an invariant (:

> So what does this all of this mean for the statement of my design?
> Well, it means that we need to stop thinking in terms of 'which
> branch can be merged into which?' and more in terms of 'which merge
> commits can be authenticated?'. And the answer to that question, with
> my design, would be:
>=20
> 1. Any merge commit signed with a key in the intersection of its
> =C2=A0=C2=A0 parents' .guix_authorizations. (Standard authorization invar=
iant.)
>=20
> 2. Any merge commit that doesn't meet the above conditions, but has a
> =C2=A0=C2=A0 parent whose most recent ancestor is the primary introductio=
n, and
>    is signed by a key in the .guix_authorizations of that parent. (My
> =C2=A0=C2=A0 weakened authorization invariant.)
That's a pretty long way of saying "Any merge commit signed with a key
in one of its parents' .guix_authorizations."  It is (by your design)
trivial to have the "primary introduction" under your control.

> Finally, let me restate the conditions for authenticating merge
> commits, taking this into account:
>=20
> --8<---------------cut here---------------start------------->8---
> For commits that have multiple parents - ie. merge commits - we
> weaken the invariant as follows:
>=20
> 1. If all parents have the primary introduction as their most recent
> =C2=A0=C2=A0 ancestor, then the invariant holds as usual.
> =C2=A0=C2=A0=20
> 2. If one or more parents has the primary introduction as its most
> =C2=A0=C2=A0 recent ancestor (call these the 'primary parents'), and the =
rest
>    have any of the additional introductions, then the merge commit is
> =C2=A0=C2=A0 authenticated if and only if it's signed by a key authorized=
 in=20
>    all of the primary parents.
> =C2=A0=C2=A0=20
> 3. If all parents have the same additional introduction as their most
> =C2=A0=C2=A0 recent ancestor, then the invariant holds as usual.
> =C2=A0=C2=A0=20
> 4. If none of the parents have the primary introduction as their most
> =C2=A0=C2=A0 recent ancestor, nor do they have the same additional
>    introduction, then the merge commit cannot be authenticated.
> --8<---------------cut here---------------end--------------->8---
>=20
> I merged 2a. into 2., and removed 2b.
>=20
> Now let me try to respond to you:
>=20
> > Yeah, I think this scheme will still end up in [4].=C2=A0 As pointed ou=
t
> > in [8], "primary" is just a convention that we can't rely on.
>=20
> Not really. As I discussed, [8] points out that /merge order/ is the
> convention that we can't rely on. Introductions can be deliberately
> specified as primary or additional, whether via command-line flags or
> separate sections in .git/config.
>=20
> > So let's just talk about the idea of widening one channel
> > introduction to any number of channel introductions =E2=80=93 we can al=
ways
> > store a mapping of HEAD =E2=86=92 first authenticated commit and then
> > assert that this set is a subset of what we declare as
> > introductions. =C2=A0(This mapping will also make authentication as
> > efficient as it currently is, since we don't need to reauthenticate
> > everything all the time.)
>=20
> I'm not sure what you mean. What do you mean by "mapping of HEAD =E2=86=
=92
> first authenticated commit"? Does this perhaps mean 'all commits
> between the latest one and the first authenticated commit'?
Little refresher: Guix stores a list of already authenticated commits
so as to not redo this work all over again.  If we were to allow
multiple introductions, we would also need to find the first
authenticated commit among them to match against the channel
introductions.

> What does "assert that this set is a subset of what we declare as
> introductions" mean?
Let's say that you work on branches B, C, and D with "primary"
introductions I, J , and K.  If you want to merge C into B, you need to
remember that B has I as its primary introduction, C has J, and so on.

> > Is this good enough?=C2=A0 No: an attacker could easily add their own
> > introduction and call it a day.=C2=A0 In fact, this scheme is even wors=
e
> > than what was exploited in [4], because they never need commit
> > access to the Guix repo to do so.=C2=A0 Ahh, but wait!=C2=A0 `guix pull=
` on
> > the user's side uses their clean set of channels for
> > authentication.=C2=A0 Those only have upstream Guix=E2=80=A6 unless you=
 actually
> > pull your own fork or manage an attack as outlined below (in which
> > case you do need commit access for some amount of time).
>=20
> I should point out - my design does not require us to distribute any
> introductions besides Guix's existing one, nor will it provide any
> mechanism to automatically 'install' someone else's introduction.
Yes it will, per `%default-guix-channel'.

> An introduction is a tuple of (introductory commit, key that signs
> it) that you specify as arguments to `guix git authenticate`. An
> attacker would have to convince the entire Guix community to specify
> their (the attacker's) own introduction on the command line (or
> directly add it into .git/config). And given that there is no reason
> to ever do so unless you're using someone's fork... that's a hard
> sell.
Well, another hard sell would be introducing a feature to `guix git-
authenticate` that must not ever be used in Guix itself.  Now, since
you are already soft-forking Guix, you can obviously add this to your
own guix command, but do beware the dragons you're summoning with it.

Cheers





Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 16 Jan 2025 14:15:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 09:15:24 2025
Received: from localhost ([127.0.0.1]:60514 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYQeZ-0007Jk-Dv
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 09:15:23 -0500
Received: from wolfsden.cz ([37.205.8.62]:39938)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <~@wolfsden.cz>) id 1tYQeV-0007JW-Vn
 for 75552 <at> debbugs.gnu.org; Thu, 16 Jan 2025 09:15:21 -0500
Received: by wolfsden.cz (Postfix, from userid 104)
 id AC931358E16; Thu, 16 Jan 2025 14:15:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail;
 t=1737036917; bh=qR58mMTSvreoIhz550q2otVW3ewLIYTE9aBB21Ehz4E=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=n2Vjma4zRBaDj0AfRZku0JDL7ODJTQWw4pvtvI7iqPtYbNNLypAwckNEZxmH8eKNf
 E4WzC72Q5s1CS6vLeNvD/5P+U+ouSX7OITVU6ygqFEEmbX4SxUdCOdpG2ZXZmbn3MT
 j0EsUZ+vZFTiAlpQ5Amqngaup9DtjWhaE86lmGqYjH2nTsBupy66OqZaZscx1PKZT2
 ClN5A+J4mDQ2wW2nfaFF76VDN6N8ZgTb74URsAWwLhQ3hmmIIfflzf+5dqL8ulCgVv
 Wc96dvx1Sve9FfOPHpnp7B9F9M4oEP9jGWgafluM74Z1u7romO/0Kl4o2d6v6cPuhy
 VBSg3dPNEr5YGKGnYi139qaugzCcqlB6eFKorTCuv3kEzqvtCHRFzW3jSFjVTAu64h
 sVYsq68lSJ2NpLB2oOD37Wta7QWmn1RISZVvLNoRwV4t9oBOnj6PZ/E8IJMPwNmijG
 0h34ojS+l6w8Qr5p6E5pvggsflwhG807c33di/HDEu1bFIPyrIiOO8WxXw3S4zE9+k
 gnuSfQ5lrvRigGqLStcEviYuW1V4AEYtdLEUB3oGYdgJ3cjBjh4f8kX+7FBOqQBP7N
 6epfxFkV/23tzVqC16duBajcZIc8m+UO0CRqM59YmXXHE2zYvGGfy1LLV0Mw6bsTOm
 NHMhE2bq50dOAaDCNIyHcOFA=
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on wolfsden
X-Spam-Level: 
X-Spam-Status: No, score=-3.1 required=5.0 tests=ALL_TRUSTED,BAYES_00,
 DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_BLOCKED
 autolearn=ham autolearn_force=no version=3.4.6
Received: from localhost (unknown [128.0.188.242])
 by wolfsden.cz (Postfix) with ESMTPSA id D0C1734EBD1;
 Thu, 16 Jan 2025 14:15:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail;
 t=1737036916; bh=qR58mMTSvreoIhz550q2otVW3ewLIYTE9aBB21Ehz4E=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=yjvn0dsx7H2wnzk3Z5+3D0akFi9NVKyjx4UXOVXzVd3bXbGoHqgl03dCsoUF62doh
 no25mju9kXOdV9r+4sx3TMpiV1pD2iYxjaqnERi/4zddCa69yMZARvTcHsvC58Thnq
 Sqd11KsjE95I9PfZgXV7YzE/9nen+xNlLL7obDt3wC00paigBGMj8C6h4Kw9b5V7n/
 Zb+YoRQiuZ59Ry/btlEEFi40QIbC21HQUz8mewVmdOyDrNFv9xu6gAWsaxZruVyHob
 ujUHUZvZEsrtFFgashMFyzOi6o4TzdMIUMAdCoLveFBztIyRREoiAQrS0GXGF3v6r3
 fhCRUbi4fM1YJZCPddubdfMHeFZSNIAS9eXPBIYb8Y2xKKfn/tGO5PK5GUTjevo/SW
 vtmHNjBddWskLLCD0abJfK/5eBiROeCdgNla5d7zrQkpv/86mlk7TzzcZa1g37w/4L
 CXVgLgYqptfutMTw3l0+e9XkZ6su6HtZHbry5tkoVDes/zIgxJ4OmYZTfL3esNUOZR
 FZKFEVTxYyCAk7tmz8ny6/pvWVMOWsEYtnMNV2tz8wcL5S9TrsLdWAIFeh2pN2C8X9
 bwxs02Hr5IcTGRkB0dh/kJSj5CrY1UBMN4I5BpRseVTpHtqVy32BVeamY1mhE4CyFW
 s7yxYTEy6bv8yysRd5SwxlKw=
From: Tomas Volf <~@wolfsden.cz>
To: Ricardo Wurmus <rekado@HIDDEN>
Subject: Re: Non-committers can't keep authenticated forks updated
In-Reply-To: <87frlji1j4.fsf@HIDDEN> (Ricardo Wurmus's message of "Thu,
 16 Jan 2025 09:52:15 +0100")
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87a5brsmve.fsf@HIDDEN>
 <c3b1445d236ed95f768c218503089926788256a4.camel@HIDDEN>
 <87frlji1j4.fsf@HIDDEN>
Mail-Followup-To: Ricardo Wurmus <rekado@HIDDEN>, Liliana Marie Prikler
 <liliana.prikler@HIDDEN>, 45mg <45mg.writes@HIDDEN>,
 75552 <at> debbugs.gnu.org, guix-devel@HIDDEN, help-guix@HIDDEN, Felix
 Lechner <felix.lechner@HIDDEN>
Date: Thu, 16 Jan 2025 15:15:16 +0100
Message-ID: <87wmeurgjv.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: 75552 <at> debbugs.gnu.org, 45mg <45mg.writes@HIDDEN>,
 Liliana Marie Prikler <liliana.prikler@HIDDEN>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>, guix-devel@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Ricardo Wurmus <rekado@HIDDEN> writes:

> Liliana Marie Prikler <liliana.prikler@HIDDEN> writes:
>
>>> This has the slight issue that I can no longer easily answer a
>>> question "is this commit in my fork", since I cannot search by the
>>> commit hash. I admit it is not a question I need to answer often
>>> (last time was on 21st of October, CVE-2024-52867).
>> You could solve this by embedding an "upstream-commit:" trailer, but
>> that is an admittedly cursed transformation that no longer maps to a
>> single rebase, I admit.
>
> You can use the Change-Id tag for this.  Our local hooks create them and
> they stay intact after rebase.

Oh, right.  That was not a thing yet when I started my tree, but these
days it would work (with the obvious detail that people use commit
hashes, not change-ids, in emails, so I would need to translate first).

But yes, it still is large improvement over matching commit messages.

Tomas

=2D-=20
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJCBAEBCgAsFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmeJFHQOHH5Ad29sZnNk
ZW4uY3oACgkQL7/ufbZ/wamBFg//UMnjKuBBW30j7j4VRK5Fyhn+oE86GGm8OsGf
8wzEYEBV5uReYk1pFLlol6FfDgtQ5l4dc1e85v0Zaup/4QtuoE/MIqsZ974B6Wcm
7aq3xYfUSHa1aggJNMR/+HpueeXYxAIXtwibgwgznV8nO26qIf9oTi0f9Qsyx5jj
ddzcMaLSmpX8ojCTmCMcvzF7/iehZGjmVNCJteOIuu5JPkGqes0yalgTfa/Mo3YP
W5yzpM9323sH8HTvBGbpHlKsNpJQC7nX8sZtbFUUVUBTYQ7lHBGlFsj+FU26J2mE
RI6grB24jcGQv/4/AXFnrhYs9myzGu3VQIhckg+AMOq+NaEHzwwuk6HwUfsbTUo8
/sxKQTobRYbqRGgDWzm/MMlptghZ0KD4BAAZKXBM8a5eDm8uTBOYICRT3rYOb4q8
XpubfEGqLtnc4nbUjK2aQ4tqnNwmgrm88RC4U10ilCmOZlP9lncwAspdhe3hhdmf
5FmbGIdrMN6xIz/vKLvfJCRNPOhNzfDU1tj9PHt0VirAL+8deC4yDw6cYgDnUh87
4UyOcW5SStVhAxQR5jWjoU4NLVc/Uuw3VSUqZm1Q5oBYVIhiUC3Mb+zQKDVmIZFX
PnJXoC5IGDQBut/OtsSE5NxzoeZFSJibkDQvP1kDlypGvyy23VZGNVuj14r2T7aU
8jxZ4m0=
=J8ch
-----END PGP SIGNATURE-----
--=-=-=--




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 16 Jan 2025 13:30:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 08:30:30 2025
Received: from localhost ([127.0.0.1]:60463 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYPx7-0005H9-Qo
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 08:30:30 -0500
Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]:50626)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <45mg.writes@HIDDEN>)
 id 1tYPx4-0005Gr-7P
 for 75552 <at> debbugs.gnu.org; Thu, 16 Jan 2025 08:30:27 -0500
Received: by mail-pl1-x642.google.com with SMTP id
 d9443c01a7336-2161eb95317so15826015ad.1
 for <75552 <at> debbugs.gnu.org>; Thu, 16 Jan 2025 05:30:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1737034220; x=1737639020; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=qRX766iVG7NTJC4XqVTjLTYCgR+Hj1Siy8iPgCUyJic=;
 b=Q2wuOIf1gyfYrNCWr/oSY6yMLhtZu7LaCxjnNb09LDUqW337W/DIBZnSWjbN06V4ni
 pXV1jCfVR3XtLHba4AI4/jGMVrBPp6pyi3kBa1n5KjiPmR+LzSzq4lKdZbyeEvaqme3A
 kf4N62Nti3SI5YOyD+6ZD3IJeFulmTriJuwjSzMHrWEFX108SNOObQX+zsYWSEKlrEP7
 hiZr/5DyMQXFoqE4LFiCde48dcKETGPQScM4mIsu7zYtYANWRzfrS9whaJsuDV5iJnP+
 eQFW666ds7oOXsvl7/NDbYi0MnvsSgdABMbafxpsd0q22IrAPB7UkMP9Lm6WbtT1gdUS
 42Rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1737034220; x=1737639020;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=qRX766iVG7NTJC4XqVTjLTYCgR+Hj1Siy8iPgCUyJic=;
 b=YzPvEonxWDZDKLrhtSml2y1MTiopApNOgVdXj3kMVRjclCZleeAoIG0GnSsiT4MCcG
 jRVOI3RC0fauurV9CVJvTCSMa0KytVhSvVEKH7NR5fRhOWCMclRfmzeRI1l9IVXUcEDI
 w+gJOUl+7Ci8oObKgekvsyknxHaJhRFWFClcg4nF4VMfGVvIxG3Gy8WPBw+KTh/mq3dD
 /4W8INgB30UMmWTs41BlFUNgUZFj7yeDa1RJpbmJeMLM9Z3LGWAuPt8vDTtYvGnAnBob
 ALizA4IZj4nMlPq0izfIyLahEdfn939SB3W/7aDYoDEytry1hhe5bMrxaaUVVKOPJYsV
 jKuQ==
X-Gm-Message-State: AOJu0YxGZJv6FYfoIznBp775TNgwdJViR24OPUNOngWBvlNLcs3JZR5Z
 fIphCZLaK4RQ0SqCzYuY1L1gAH+1/A8QJQsTxtd1/1PBkYhDyrunn3WZjxO7
X-Gm-Gg: ASbGnctfoyQyeVjr79v/MHjL8jdlZsdHD1pGP9rDA4Dw/U7smssu+O7UmZHWTvmnnNT
 dzkXhHlvzcn0v1Rah2XM7iNMrG9XY5Q0s8PZa/wOmRngMCyH+NaTr60UzMDzKp/Epw985WTAdR0
 gztRyMhjpFoCQO9LrU/FvBzLNsbqB8iqQzALRit7DEE0S0lQvLzr7z+mmJvHL1e2vL8OlFOw2WL
 QmhD97KoWJ5auU5cC0J0Q+4SB8hmaJnfNDGGlE+JEMdjPk4SnB2rK0vZw==
X-Google-Smtp-Source: AGHT+IHL2MZR+Psbyv4W2qS/9BJfmc2fVtCVnekl2X43EpFQKq8cOP2JRgMEIIfYRM3CoUr6/zdsqA==
X-Received: by 2002:a05:6a20:a10c:b0:1db:ec0f:5cf4 with SMTP id
 adf61e73a8af0-1e88d0d9c40mr51117727637.39.1737034220218; 
 Thu, 16 Jan 2025 05:30:20 -0800 (PST)
Received: from guix1 (utm3.nitt.edu. [14.139.162.2])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72d406a5684sm10872762b3a.165.2025.01.16.05.30.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 05:30:19 -0800 (PST)
From: 45mg <45mg.writes@HIDDEN>
To: 75552 <at> debbugs.gnu.org
Subject: [Attila Lendvai] Re: Non-committers can't keep authenticated forks
 updated
References: <tIveR-LcF8Stf4VlcgUaEW0oHgUPw3UDWcK6n04pdf2JGjOnMqV3i1gV4M0s0HnyCHbW8rL36E1fo4ckbqHFTI8wO01ilXD5H4TZ80M2isE=@lendvai.name>
Date: Thu, 16 Jan 2025 13:30:18 +0000
Message-ID: <87ikqerimt.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, help-guix@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


Forwarding Attila's message here, because it wasn't sent to bug-guix, so
it may not have reached some of you and won't show up in the issue
tracker.

As far as I can tell, this is exactly what the 'rebase' approach
mentioned upthread would look like in practice. As mentioned, it has the
problem of having to bump the introduction every time, and I've written
about the security aspects of this (beginning of [1]). Also, as Attila
notes, it's burdensome.

[1] https://lists.gnu.org/archive/html/bug-guix/2025-01/msg00135.html

-------------------- Start of forwarded message --------------------
Date: Wed, 15 Jan 2025 17:15:44 +0000
To: 45mg <45mg.writes@HIDDEN>
From: Attila Lendvai <attila@HIDDEN>
Cc: Felix Lechner <felix.lechner@HIDDEN>, Tomas Volf <~@wolfsden.cz>,=
 help-guix@HIDDEN, guix-devel@HIDDEN
Subject: Re: Non-committers can't keep authenticated forks updated

i haven't read the entire thread [sorry], but with that in mind here's how =
i'm solving this:

i have various branches where i keep my not-yet-merged work. i also have a =
script that creates/overwrites a branch (called 'attila', starting at the t=
ag 'attila-baseline') and cherry picks everything into it. i sometimes `git=
 tag -f` the 'attila-baseline' tag to pick a new baseline.

then i update my intro commit hash wherever i want to pull my rebased/cherr=
y-picked changes (this is a several machines setup, and yes, it's burdensom=
e).

when a cherry pick fails, then i cancel the script, rebase the problematic =
branch on 'attila-baseline', and restart the script pasted below.

--=20
=E2=80=A2 attila lendvai
=E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39
--
=E2=80=9CIs there an idea more radical in the history of the human race tha=
n turning your children over to total strangers whom you know nothing about=
, and having those strangers work on your child's mind, out of your sight, =
for a period of twelve years? [=E2=80=A6] Back in Colonial days in America,=
 if you proposed that kind of idea, they'd burn you at the stake, you mad p=
erson! It's a mad idea!=E2=80=9D
	=E2=80=94 John Taylor Gatto (1935=E2=80=932018), Teacher of the Year, both=
 in New York City and State, multiple times


#!/usr/bin/env bash

BRANCHES=3D"kludges ui-warnings print-branch-name"
BRANCHES+=3D" shepherd-guix-side"

set -e

initial_branch=3D$(git branch --show-current)

git rebase attila-baseline attila-initial-commit

git checkout attila
git reset --hard attila-baseline
git pull . attila-initial-commit

for branch in ${BRANCHES}; do
    echo "*** Processing branch ${branch}"
    #git rebase attila-baseline $branch
    git cherry-pick attila-baseline..$branch
done

#git checkout $initial_branch

git -c pager.log=3Dfalse log --pretty=3Doneline attila-initial-commit~1..at=
tila-initial-commit

-------------------- End of forwarded message --------------------




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 16 Jan 2025 13:22:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 08:22:58 2025
Received: from localhost ([127.0.0.1]:60452 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYPpq-0004rO-2e
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 08:22:58 -0500
Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]:51329)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <45mg.writes@HIDDEN>)
 id 1tYPpn-0004r4-JL
 for 75552 <at> debbugs.gnu.org; Thu, 16 Jan 2025 08:22:56 -0500
Received: by mail-pl1-x642.google.com with SMTP id
 d9443c01a7336-216634dd574so9841925ad.2
 for <75552 <at> debbugs.gnu.org>; Thu, 16 Jan 2025 05:22:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1737033769; x=1737638569; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
 :reply-to; bh=UR580h6//N4R5ki4XglF5YvWNkGXpZy8KmPsjDmw6+U=;
 b=bxloiRX6Nai0ZohxKGfYZ05+Z8lc2GnMyTv4GeZ5Quy1cyIKvQTqc9/fmpayAWuc85
 wyqkBv5iFw3EoePPEY1lwIJHqesfZx9I79MA/O3gmGutONoIBConsGYMqMTNcXJkEyXz
 9Cqwkt9PlxNroLIT3AH3Sca4Iv9jlHrblxFM7UvNy0Vz5SCG/Uw0of0+W+2/1AC0yXOm
 SCzr6tIwJDhxm+RMYi5Ov2GVtTWTd75/W2bAq/XyRwU+f+PMsn+4xo8ZNbyRRz/WfFeb
 dhr7YIWEaG1UPIArsvRCokfpSa8tRiawMG2kAQ4Z/84qbiKWojOkK8hCzliasc6bFpt1
 VkvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1737033769; x=1737638569;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=UR580h6//N4R5ki4XglF5YvWNkGXpZy8KmPsjDmw6+U=;
 b=XlMlbfmg47QEpjrtejzOxBqcoeDEn1GTn91lLo0bFjT6iQONjBDsS7/QBS40XqM43c
 jwlSxKMddFu2PqDE01Z1GzM2PrjwcdspT/i+28vLRuk/b1KFBbv402rbw23VbRWapCvd
 scXTiKTNzgZsHSPpY1dE1cm3KmVa5IGcVaDMVSVfzGYAZKjORXB7kInioNWJq/IXxdup
 eEAaRQOkXybnvhYdH8nZJSTkjf/ONWu8f0DbTPi1pK00DhY/wpZUigr5x6NQnQXTupom
 7fGUdlouyAdEW8p0a3Qll9vNjfDw/sdLa7rAVHpySrGT8NYMY8yijQbmzwDvh8l4sns0
 o6KQ==
X-Forwarded-Encrypted: i=1;
 AJvYcCWY9yRLegk2n2FzI2AfsPRQsRHvkYkv8zKdd0fFJY6mP48Vlj6C+Xz+9FzEZfe0iVP6udB5ng==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyJVnAtKntf9rgq7sg/UAMr5zFYtMULUSYoXFOcjaKqfuM21S3r
 tZFtPls+57hnDI/sm7loJQWhMy1T/ks6jUA5ytxqNdONL5cDfJpP
X-Gm-Gg: ASbGncteXvGksqYHNwf59zCNP63ykg3+xzAa1SSYnfG1JSznMC6xF/ioxsTjAieFafK
 NrKQwpVVBzVciWnNN+ixewJbPqoO5Ub3q/Ekyym64D/m4hXe8mz71xBOHonl/CkQD/AXyl7Blde
 oLbv+VIrkrpk0pIssUKhffWYJiuOLAwGnST040dpYJ1DxGPVP1FI+pEcFnQBDnYUvSB7eKsEIvc
 /FJEzMh7yyWpVdSeGan1DVJBGNZAkavIkIMuo8xF6bu2YwK9bDYyeFGuA==
X-Google-Smtp-Source: AGHT+IE08UyX63IBs9vS5L8N2eKVFTl/v4ek8nnZyP2RxEb47ovQPNcGroNh1uWyutnYcw86wchahg==
X-Received: by 2002:a05:6a00:2406:b0:72d:8fa2:99ac with SMTP id
 d2e1a72fcca58-72d8fa2a067mr9025883b3a.13.1737033767903; 
 Thu, 16 Jan 2025 05:22:47 -0800 (PST)
Received: from guix1 (utm3.nitt.edu. [14.139.162.2])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72d406a5299sm10921904b3a.162.2025.01.16.05.22.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 05:22:47 -0800 (PST)
From: 45mg <45mg.writes@HIDDEN>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, Tomas Volf
 <~@wolfsden.cz>
Subject: Re: Non-committers can't keep authenticated forks updated
In-Reply-To: <c3b1445d236ed95f768c218503089926788256a4.camel@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87a5brsmve.fsf@HIDDEN>
 <c3b1445d236ed95f768c218503089926788256a4.camel@HIDDEN>
Date: Thu, 16 Jan 2025 13:22:44 +0000
Message-ID: <87o706rizf.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, 75552 <at> debbugs.gnu.org, 45mg <45mg.writes@HIDDEN>,
 help-guix@HIDDEN, Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Liliana Marie Prikler <liliana.prikler@HIDDEN> writes:

[...]

> You can roll your own service definitions, but it does become harder
> when you want to keep all changes to that service from master as well.
> But `(use-modules (my-channel services nftables))` should pull that
> nftables code :)

[...]

>> Then there is anything modifying any of the guix commands.=C2=A0 #74832 =
is
>> over month old, and as far as I know, I am not able to fix guix-copy
>> from a channel.=C2=A0 #72928 took over a month to merge, and again, not
>> sure how to patch guix-describe from a channel.
> Have you considered extensions?

[...]

>> (Yes, I am aware I can just copy&paste the service code into my
>> channel.  But at that point I am again just "replicating Guix", just
>> by more manual and error-prone means.=C2=A0 And even for packages,
>> adjusting system configuration to use package from my channel,
>> getting it merged and then adjusting back to upstream is annoying
>> chore.)
> You could code your channel in a way that it serves upstream stuff
> either silently or with a deprecation warning if a particular package
> is requested.  Not a channel, but [1] illustrates my point.

You could probably get all these ideas to work. But try to put yourself
in the shoes of someone who's just sent any of these patches. After
putting in the hard work to fix an issue by modifying the upstream code,
they now need to fix it AGAIN in a different way (via their channel).
Imagine trying to reimplement something as complex as the bootloader
subsystem rewrite [2] in your channel.

If you're going to have to incorporate every contribution into your
channel, you're heavily incentivized to only ever work on your channel,
and never bother sending any patches to upstream.

> Cheers
>
> [1] https://git.ist.tugraz.at/clingabomino/clingabomino/-/blob/0.2.0/pkg/=
guix.scm?ref_type=3Dtags#L30




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 16 Jan 2025 13:10:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 08:10:30 2025
Received: from localhost ([127.0.0.1]:60435 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYPdk-0004Ja-O5
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 08:10:30 -0500
Received: from mail-pj1-x1041.google.com ([2607:f8b0:4864:20::1041]:49389)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <45mg.writes@HIDDEN>)
 id 1tYPdh-0004Hw-03
 for 75552 <at> debbugs.gnu.org; Thu, 16 Jan 2025 08:10:26 -0500
Received: by mail-pj1-x1041.google.com with SMTP id
 98e67ed59e1d1-2eed82ca5b4so1596966a91.2
 for <75552 <at> debbugs.gnu.org>; Thu, 16 Jan 2025 05:10:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1737033019; x=1737637819; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
 :reply-to; bh=MN8g3aQK2J8w1Ufzzz+aoBK7kRRpAMyQR0M+SDdJfLc=;
 b=TZ939BvnGE66jOd0dP9Bz6aFfFYqbU2al9XnFjZ+6Y72Y9poyZu3BIAboi3FW9sGdj
 xg3B2ZHSNHgHv2N/UFB9WB45JR21AZSHY6kzHESeUNy2dzZZI0o+5ofvGRRSAxlC3+3C
 POh/enKzL5go8ND/yPRHcjkDApnAmM45pRl2Ax+2LdtydFFIFcKtZ3XK+aGCHT6xlRUv
 l3TrnQAHzFALgMkcboa7LovL/Ga0uwKKeWTzbOww+8mBGUpAiYdyt4eX8VBJkl+WtiTc
 OWh5+wg5r1A62dcI4XNRMjtRTErdEOlDsgffFRf56jfCeJh7sEensWtHm9b0f2RithTR
 BMjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1737033019; x=1737637819;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=MN8g3aQK2J8w1Ufzzz+aoBK7kRRpAMyQR0M+SDdJfLc=;
 b=SOxoJll/0v0OWc0Ux7AZJrrj9PbUS7dEsGdNdr/CEYirN+L+FDYKOGX1RAN9el1gSQ
 1X+2eWkhdW0cJXEG16sXI5v65r7P+oy5aCkaryKvdZWAJYsZxyvqtnxVFp3umRLLPXNx
 oaLEtIacG739G4xE/E2WgnPBL1MPPOcLMgjLTgmvDpwJIHtJKGf7BmKeTRpCpn1980Kx
 laK4wBbgf1N8k9KqqHx194v7AdQ+HvU6VaD1k7rkJkYTD+bQtTppj1R9eHuxSxe+8xQp
 awmWHPXp4LpXeJMfcR7ySvbF2Kri2883qMuiH4JQ5NVFqJ6ddsnURKQJUAYpnPgiCacq
 chDw==
X-Forwarded-Encrypted: i=1;
 AJvYcCXBzeMSAoOAVq2WOFmJ3fKTJv8ExNq4Vi9OjmL3qV2CAJJSn4g+c7TVEfmGEhOAZ8g9F1uvUQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyEagH10j7q3QyMnj4i8eA2GaHN9QmefhGHBvP6ilC1W2MUbRqq
 EMHYpSN+k+lobv2gxfRqj2jIE2BxTnLTpCz/QnGPAWVgf1xC/ryo
X-Gm-Gg: ASbGncvsKXz+5MxpltHLgnRY4Z1BlUdnjroQWaNsK3Ng8YAb59lpfRIepbwejOjf68+
 DX40TELxxPAd/C5xA/SWm60gcOpPMf9RcboZ7QAf9jatFYayZfpLiK7MvNtvAjdi2tVA3S+seNa
 2JAzC9kpWDAY2TXTEYIvtKCgzNAK7xf1UaYZDI/w8ggun4DDemWGolvSFyMaRRn8ParG2wT7iIY
 A9mG2J18W04MclTGotEipQ+wDifaLhhEFhe7QTOLpEzQQRHiPcYj9adqg==
X-Google-Smtp-Source: AGHT+IGBZ8Ddb9W4TqxxoIQmgmJzEZn2bWoDHXdRbQEiCSbCPhI0C3zzGc10uUWnSXqjFHtJsvunkw==
X-Received: by 2002:a17:90b:4c88:b0:2ee:5958:828 with SMTP id
 98e67ed59e1d1-2f548f2a01emr50177579a91.9.1737033018216; 
 Thu, 16 Jan 2025 05:10:18 -0800 (PST)
Received: from guix1 (utm3.nitt.edu. [14.139.162.2])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-21a9f25a1cbsm97568965ad.241.2025.01.16.05.10.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 16 Jan 2025 05:10:17 -0800 (PST)
From: 45mg <45mg.writes@HIDDEN>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 45mg
 <45mg.writes@HIDDEN>, 75552 <at> debbugs.gnu.org
Subject: Re: Non-committers can't keep authenticated forks updated
In-Reply-To: <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
Date: Thu, 16 Jan 2025 13:10:14 +0000
Message-ID: <87v7uerjk9.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, Tomas Volf <~@wolfsden.cz>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@HIDDEN> writes:

> Hi,
>
> Am Mittwoch, dem 15.01.2025 um 15:48 +0000 schrieb 45mg:
>> The idea of authentication is that once you trust the channel
>> introduction, you can be sure that everything you pull after that is
>> authentic. The introduction only needs to be trusted once. If you're
>> bumping the introduction every time, then you need to obtain and
>> verify the introduction every time. You're going from 'Trust On First
>> Use' to 'Trust On Every Use'. Not ideal IMO.
> Let's recall that the entity you need to trust is still yourself in
> most of those cases.=20=20

If you host your repo unauthenticated on a server, you need to fully
trust the server, as well as the connection between you and the server.
Regarding the former, none of the most popular ways to host a git repo
(eg. GitHub, Codeberg, your own forge instance on a VPS) allow you to
know much about the underlying server, so you can't really assume it to
be secure. The latter is a ridiculously complicated topic that I'm not
qualified to go into. To avoid trusting all these intermediaries more
than once if at all, we have authentication.

I realise it may seem silly to worry about your own little fork being
directly targeted in ways like this, but the main reason I chose Guix in
the first place is the focus on getting the fundamentals right -
reproducibility, bootstrappability, free software, etc. - even though
most projects don't put in as much effort towards them, and even though
a lot of users may not be directly affected by these things. I think
security is one such thing. As the 'Authenticate Your Git Checkouts'
blog post [9] pointed out, we wouldn't need `guix git authenticate` if
we were willing to delegate our security to a trusted third party, like
all the open source projects that sport those "fancy =E2=80=9C=E2=9C=85 ver=
ified=E2=80=9D
badges as found on GitLab and on GitHub" do. We shouldn't force anyone
hosting a fork to do so as well.

>> You could do it like this:
>> 0) Before creating your fork, authenticate every commit in the Guix
>> =C2=A0=C2=A0 checkout (as described in the manual).
>> 1) Switch to your branch that tracks upstream.
>> 2) Pull from upstream.
>> 3) Run `guix git authenticate`, supplying Guix's channel introduction
>> as
>> =C2=A0=C2=A0 arguments.
>> 4) After this succeeds, create and switch to a branch from the
>> current
>> =C2=A0=C2=A0 tip of your upstream-tracking branch. Edit .guix_authorizat=
ions to
>> =C2=A0=C2=A0 add your key, and create a signed commit.
>> 5) Merge this branch into your fork branch.
>> 6) Switch back to your fork branch.
>> 7) Delete the [guix "authentication"] section from .git/config.
>> 8) Run `guix git authenticate` with the introduction of your fork
>> =C2=A0=C2=A0 branch, to authenticate the merge commit.
>>=20
>> That's a lot of manual steps for every pull from upstream! While I do
>> have to give you credit for this idea - at least we now have a
>> workaround for people who are determined enough - I'm guessing a lot
>> of people will probably just skip authentication if it's going to be
>> this annoying. Authenticating a fresh clone from scratch will be even
>> more annoying, especially if you have multiple fork branches (eg.
>> you're tracking someone else's fork).
> I think you're making this more complicated than it needs to be.=20
> checkout, authenticate, rebase*, merge*=C2=A0ought to have you covered.
>
> * you can authenticate after these if you're paranoid=20

The complexity is due to the requirements of not bumping the channel
introduction (to avoid the increased attack surface from having to keep
obtaining the updated one, as I discussed earlier), keeping fork history
intact (to avoid force pulls), keeping upstream history intact, and
being able to authenticate both upstream and fork commits. If you can
think of a simpler method that meets these requirements, I'd love to
hear it.

Also, I just realised that this one won't even work. The commit created
in step 4 cannot be authenticated, as it's signed with your key, which
is not in its parent's .guix_authorizations.

>> We could create a script to do all the steps for us, but if and when
>> it fails on whatever insane edge cases people are able to come up
>> with, they're going to need to understand all the steps involved
>> anyway. Abstraction is not a substitute for a clean underlying
>> design.
>>=20
>> Also I just want to point out that rebasing /will/ change the
>> history.
>> The `guix pull` after every time you update your fork will need to be
>> a force-pull (--allow-downgrades [1]).
> No, it wouldn't.  You would rebase those changes on top of what you
> already have on those respective branches.

It looks like at least one of us is misunderstanding rebasing. Could be
me, so I'm consulting the relevant chapter from the Pro Git book [11]
for a refresher.

Let's imagine that the first example given there represents our fork of
Guix, where the 'experiment' branch marks the beginning of our fork (and
its channel introduction) and the 'master' branch tracks upstream Guix.
After `git rebase master`, the commit that used to be C4 is gone, and
now C4' takes its place. It may contain the same changes, but it's a
different commit - so it (and any commits that it's the parent of) has a
different hash. So the channel introduction has changed, and so has the
entire history of the `experimental` branch. So we need to force-pull.

>> > Of course, you can also keep your own fork unauthenticated, which
>> > might be preferable if you only do local work anyway, but that's
>> > besides the issue here.
>>=20
>> Yes, to be clear, I'm talking about the use-case where your fork is
>> hosted remotely, and you or someone else needs to pull changes from
>> it.  For example, my prospective use case would be quickly
>> bootstrapping Guix on a new machine - I build my own installation
>> image, and I'd want it to pull from my fork. I can include my
>> introduction into my installer, just like the official one. But if
>> the introduction changes before I use my installer, then the first
>> pull can't be authenticated.
> I don't see why in your particular use case you can not use a channel
> on top of Guix rather than replicating Guix itself.  Now there might be
> some weird edge case I'm overlooking where you cut deep into the
> dependency graph and that makes sense, but I sure hope that's a rare
> edge case in and of itself.

See Tomas's reply [10]. I'll continue this particular tangent in that
sub-thread.

>> The purpose of the additional introductions is to make it so that
>> signed commits from upstream Guix, or commits from other people's
>> forks, can still be authenticated. As I mentioned above, the current
>> design is not suited to this.
>>=20
>> To go a bit more into detail - we will accomplish authentication by
>> doing a postorder traversal of the commit tree, considering the
>> latest commit as the root node. We traverse its parents recursively
>> until we reach a commit whose parent is one of the channel
>> introductions (primary or additional). Then that commit and all its
>> children are authenticated from the introduction that we encountered.
>> In this way, every commit is authenticated from the introduction that
>> is its most recent ancestor.
> Yeah, I think this scheme will still end up in [4].  As pointed out in
> [8], "primary" is just a convention that we can't rely on.  So let's
> just talk about the idea of widening one channel introduction to any
> number of channel introductions =E2=80=93 we can always store a mapping o=
f HEAD
> =E2=86=92 first authenticated commit and then assert that this set is a s=
ubset
> of what we declare as introductions. =C2=A0(This mapping will also make
> authentication as efficient as it currently is, since we don't need to
> reauthenticate everything all the time.)
>
> Is this good enough?  No: an attacker could easily add their own
> introduction and call it a day.  In fact, this scheme is even worse
> than what was exploited in [4], because they never need commit access
> to the Guix repo to do so.  Ahh, but wait!  `guix pull` on the user's
> side uses their clean set of channels for authentication.  Those only
> have upstream Guix=E2=80=A6 unless you actually pull your own fork or man=
age an
> attack as outlined below (in which case you do need commit access for
> some amount of time).

Whew. Ok, before I can reply directly to this, I need to discuss a few
related things.

First of all, let's talk about [8]. It isn't part of this thread so I'll
quote the relevant part here:
> Problem here is that this (which parent is first) is just a convention
> that the attacker does not have to follow.  Example:
>=20
> --8<---------------cut here---------------start------------->8---
> /tmp/xx $ git commit-tree -p HEAD -p HEAD~1 -m M HEAD^{tree}
> c040e61bc184b5971f68c4b794c3158350b5d5e9
> /tmp/xx $ g show c040e61bc184b5971f68c4b794c3158350b5d5e9
> commit c040e61bc184b5971f68c4b794c3158350b5d5e9
> Merge: 40ef875 17451b8
> Author: Tomas Volf <~@wolfsden.cz>
> Date:   Tue Jan 14 23:12:17 2025 +0100
>=20
>     M
>=20
> /tmp/xx $ git commit-tree -p HEAD~1 -p HEAD -m M HEAD^{tree}
> ec74e368519b667d8d280639db6642b28d37eb53
> /tmp/xx $ g show ec74e368519b667d8d280639db6642b28d37eb53
> commit ec74e368519b667d8d280639db6642b28d37eb53
> Merge: 17451b8 40ef875
> Author: Tomas Volf <~@wolfsden.cz>
> Date:   Tue Jan 14 23:12:32 2025 +0100
>=20
>     M
> --8<---------------cut here---------------end--------------->8---
>=20
> Notice that I have created two commits, and they have the same parents,
> just in swapped order.

Here, Tomas is presumably reacting to Condition 2b in my procedure for
authenticating merge commits, which I will quote here again:
> For commits that have multiple parents - ie. merge commits - we weaken
> the invariant as follows:
>
> 1. If all parents have the primary introduction as their most recent
>    ancestor, then the invariant holds as usual.
>=20=20=20=20
> 2. If one or more parents has the primary introduction as its most
>    recent ancestor (call these the 'primary parents'), and the rest have
>    any of the additional introductions, then the merge commit is
>    authenticated if and only if:
>    a) it's signed by a key authorized in all of the primary parents, AND
>    b) the /first parent/ [^] of the merge commit is a primary parent.
>=20=20=20=20
> 3. If all parents have the same additional introduction as their most
>    recent ancestor, then the invariant holds as usual.
>
> 4. If none of the parents have the primary introduction as their most
>    recent ancestor, nor do they have the same additional introduction,
>    then the merge commit cannot be authenticated.

Now, it turns out that the parent order in a merge commit isn't actually
the relevant detail here. The parent order is a /UI detail/: it's a
convention that helps indicate in which direction a branch was merged
(and possibly other things), so that `git log` can show this to us, but
it doesn't actually affect the internal representation of the commit
graph.

The relevant detail is the fact that Tomas's observation should lead us
to remember - a Git commit graph doesn't include any information about
'merge order', ie. 'which branch was merged into which'. In fact it
doesn't include any information about /branches/ - those are just refs
that can be made to point to whatever commit you want, they are not part
of the commit graph.

Once we realise this, we can see that trying to control which branch can
be merged into which doesn't make sense.

This led my to think of an attack that's possible with my design - if I
want to screw with anyone `guix pull`ing from my fork, I can merge
upstream into my fork branch, add a bunch of malicious commits, and then
make the upstream branch ref point to the latest such commit. Now anyone
pulling from my fork will recieve the malicious commits as part of
upstream's history - since no commit hashes needed to change, the pull
is a regular fast-forward one, with no indication that anything is
amiss. Authentication will succeed since the malicious merge commit has
our fork as its (first) parent, and that parent has the primary
introduction as its most recent ancestor.

The takeaway here is that anyone authorized via the primary introduction
can fake new upstream commits.

So why bother with additional introductions at all, then? Because as far
as I can tell, they are still the only solution mentioned so far that
satisfies the requirements I mentioned earlier:
> not bumping the channel introduction (to avoid the increased attack
> surface from having to keep obtaining the updated one, as I discussed
> earlier), keeping fork history intact (to avoid force pulls), keeping
> upstream history intact, and being able to authenticate both upstream
> and fork commits
...and yes, you do have to trust the fork maintainer to not deliberately
mess those things up. But that's nothing new - even in the existing
design, we have to trust everyone who can make trusted commits not to
mess things up on purpose.

So what does this all of this mean for the statement of my design? Well,
it means that we need to stop thinking in terms of 'which branch can be
merged into which?' and more in terms of 'which merge commits can be
authenticated?'. And the answer to that question, with my design, would
be:

1. Any merge commit signed with a key in the intersection of its
   parents' .guix_authorizations. (Standard authorization invariant.)

2. Any merge commit that doesn't meet the above conditions, but has a
   parent whose most recent ancestor is the primary introduction, and is
   signed by a key in the .guix_authorizations of that parent. (My
   weakened authorization invariant.)

Finally, let me restate the conditions for authenticating merge commits,
taking this into account:

--8<---------------cut here---------------start------------->8---
For commits that have multiple parents - ie. merge commits - we weaken
the invariant as follows:

1. If all parents have the primary introduction as their most recent
   ancestor, then the invariant holds as usual.
=20=20=20
2. If one or more parents has the primary introduction as its most
   recent ancestor (call these the 'primary parents'), and the rest have
   any of the additional introductions, then the merge commit is
   authenticated if and only if it's signed by a key authorized in all
   of the primary parents.
=20=20=20
3. If all parents have the same additional introduction as their most
   recent ancestor, then the invariant holds as usual.
=20=20=20
4. If none of the parents have the primary introduction as their most
   recent ancestor, nor do they have the same additional introduction,
   then the merge commit cannot be authenticated.
--8<---------------cut here---------------end--------------->8---

I merged 2a. into 2., and removed 2b.

Now let me try to respond to you:

> Yeah, I think this scheme will still end up in [4].  As pointed out in
> [8], "primary" is just a convention that we can't rely on.

Not really. As I discussed, [8] points out that /merge order/ is the
convention that we can't rely on. Introductions can be deliberately
specified as primary or additional, whether via command-line flags or
separate sections in .git/config.

> So let's just talk about the idea of widening one channel introduction
> to any number of channel introductions =E2=80=93 we can always store a ma=
pping
> of HEAD =E2=86=92 first authenticated commit and then assert that this se=
t is
> a subset of what we declare as introductions. =C2=A0(This mapping will al=
so
> make authentication as efficient as it currently is, since we don't
> need to reauthenticate everything all the time.)

I'm not sure what you mean. What do you mean by "mapping of HEAD =E2=86=92 =
first
authenticated commit"? Does this perhaps mean 'all commits between the
latest one and the first authenticated commit'?

What does "assert that this set is a subset of what we declare as
introductions" mean?

> Is this good enough?  No: an attacker could easily add their own
> introduction and call it a day.  In fact, this scheme is even worse
> than what was exploited in [4], because they never need commit access
> to the Guix repo to do so.  Ahh, but wait!  `guix pull` on the user's
> side uses their clean set of channels for authentication.  Those only
> have upstream Guix=E2=80=A6 unless you actually pull your own fork or man=
age an
> attack as outlined below (in which case you do need commit access for
> some amount of time).

I should point out - my design does not require us to distribute any
introductions besides Guix's existing one, nor will it provide any
mechanism to automatically 'install' someone else's introduction. An
introduction is a tuple of (introductory commit, key that signs it) that
you specify as arguments to `guix git authenticate`. An attacker would
have to convince the entire Guix community to specify their (the
attacker's) own introduction on the command line (or directly add it
into .git/config). And given that there is no reason to ever do so
unless you're using someone's fork... that's a hard sell.

Perhaps I should have mentioned this when you suggested the attack below
in the first place.

>> > I think this might still hide a serious flaw.=C2=A0 With the way
>> > *upstream* authentication works.=C2=A0 Let's flip the example in [6]
>> > around a little bit and construct the following:
>> >=20
>> > -A---B---C---D
>> > =C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
>> > =C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \-E---F---=F0=9F=92=
=80
>> > =C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /
>> > =C2=A0=C2=A0=C2=A0=C2=A0 \----G--H--I*-/
>> > =C2=A0=20
>> > Both A and I* are introductory commits on their various branches.=C2=A0
>> > In =F0=9F=92=80, any committer who has valid keys in both F and I* can=
 merge
>> > a branch with unsigned commits, effectively voiding the invariant
>> > of BCEF, e.g. by undoing any changes that happened there.=C2=A0 Of
>> > course, they can do so with signed commits as well, given that they
>> > have commit access to the main repository, but the point still
>> > holds that they may introduce unsigned commits to any fork where
>> > their key is valid in.
>>=20
>> So, my design enables an attacker who can make authorized signed
>> commits to also introduce changes made in unsigned commits. Hmm.
>>=20
>> I don't think this compromises our current security guarantees,
>> though?
> I mean, the promise we do make is that all commits starting from a
> certain commit are signed.  So IMHO, this effectively breaks that :)

Again, you need to deliberately use the attacker's introduction for this
to work. Unless you're pulling from their fork (in which case you
already trust them), there's no reason for them to ask you do so.

>>   If the attacker can already make trusted commits, then any attack
>> they can perform in the way you described can also be done directly
>> with signed commits onto F, as you pointed out. And the latter way
>> would be far simpler for them.
> Simpler, yes, but less stealthy.  Most contributors don't concern
> themselves with the specifics of any particular branch, and you may
> even be able to dress up your evil branch as a good branch until the
> point where you finally merge it.

See above. We will never need to specify more than one introduction for
the main Guix repo, so this doesn't come up. We're not trying to enable
pull-request-style workflows within Guix; we're just trying to permit
authenticated forks.

>> Also, the branch they merged into would not contain any unsigned
>> commits; the commit '=F0=9F=92=80' is still signed with a key authorized=
 for
>> F's branch. So at most, we can say that the attacker can introduce
>> /changes made in/ unsigned commits, not 'introduce unsigned commits'.
> They can make an arbitrary number of unsigned commits before needing to
> sign off one commit that will be merged.  If they follow the style of
> merging master into their branch and then their branch into master,
> said commit can even be empty, though that would no longer be stealthy.
> Now if they were to I don't know, bump 9000 Rust packages or something
> like that, they have a lot of space to exploit the as-of-yet in this
> manner unexploited, but still weak SHA-1 hashes Git uses.
>
>> Once you manage to revoke their commit access, you'd just revert the
>> '=F0=9F=92=80' commit and delete the GHI branch (which is the one that c=
ontains
>> unsigned commits). The same way you'd recover from them directly
>> making malicious changes on master.
> Reverting this change could land you in early 2025.  And worse, your
> attacker could lure you onto their branch if you happen to land on any
> bad commit in the meantime.
>
> Cheers
>
> [8] https://lists.gnu.org/archive/html/help-guix/2025-01/msg00116.html

Thanks for sticking with me this far,
45mg

[9] https://guix.gnu.org/blog/2024/authenticate-your-git-checkouts/
[10] https://lists.gnu.org/archive/html/bug-guix/2025-01/msg00123.html
[11] https://git-scm.com/book/en/v2/Git-Branching-Rebasing




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 16 Jan 2025 08:52:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 03:52:37 2025
Received: from localhost ([127.0.0.1]:59965 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYLcD-0005hJ-4M
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 03:52:37 -0500
Received: from sender4-of-o51.zoho.com ([136.143.188.51]:21101)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <rekado@HIDDEN>)
 id 1tYLcB-0005h9-2a
 for 75552 <at> debbugs.gnu.org; Thu, 16 Jan 2025 03:52:35 -0500
ARC-Seal: i=1; a=rsa-sha256; t=1737017540; cv=none; 
 d=zohomail.com; s=zohoarc; 
 b=BQB7MKvSB4b4wDu7FuuFNbBrN3l6eb1mgXYvbn8nUlOzo/3Fk/6iEEhNlgBUPwKA4j77FG9T+E3E7RZiXerEuqcEOjf+D3TlFJngZOlBl1GKcLW3Mh4pOUiqCY8qU97MY+f/fn1528q9woK5GhbXqkm9d4CUpQWNRgRACu89/Qc=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com;
 s=zohoarc; t=1737017540;
 h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To;
 bh=MGoyvN7DGrN4wifaPLSGcXXgsE4WfcUPnJgGwWA77gc=; 
 b=Ee8ayTPLa3YqBJvOh0q/qfdmsbleAgW3hytLeQ3+XrQIwpPJSzhG2/uSWi5x+n0RDHvA3C0WDMOJGVsgqH6GPddboWyxu6Z9sM8ztms1bFy38D68BrMCtOJbEYOSPhNYhGS1quDR6qwV+NmZOfpd9ttZYm8+K4Vi3yJN7jNpt4c=
ARC-Authentication-Results: i=1; mx.zohomail.com;
 dkim=pass  header.i=elephly.net;
 spf=pass  smtp.mailfrom=rekado@HIDDEN;
 dmarc=pass header.from=<rekado@HIDDEN>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1737017540; 
 s=zoho; d=elephly.net; i=rekado@HIDDEN;
 h=From:From:To:To:Cc:Cc:Subject:Subject:In-Reply-To:References:Date:Date:Message-ID:MIME-Version:Content-Type:Message-Id:Reply-To;
 bh=MGoyvN7DGrN4wifaPLSGcXXgsE4WfcUPnJgGwWA77gc=;
 b=EkwHoSDNIwLeu99YTU0lTPydwSK40oePgqTWXkZecZ1zZt76koYIiJatZQx3dU60
 GzWs0Ry45f7yZOFIWPIkTXfiWkkNjEbWmtGjf7dSYPTATw0sNuKCbV5l100/dgnUZSn
 FZDbD1JTa+3K+O7M2kwNcaprtwlGjsSFgnThEu+4=
Received: by mx.zohomail.com with SMTPS id 1737017538076225.433973742097;
 Thu, 16 Jan 2025 00:52:18 -0800 (PST)
From: Ricardo Wurmus <rekado@HIDDEN>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Subject: Re: Non-committers can't keep authenticated forks updated
In-Reply-To: <c3b1445d236ed95f768c218503089926788256a4.camel@HIDDEN>
 (Liliana Marie Prikler's message of "Thu, 16 Jan 2025 08:38:59 +0100")
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87a5brsmve.fsf@HIDDEN>
 <c3b1445d236ed95f768c218503089926788256a4.camel@HIDDEN>
User-Agent: mu4e 1.12.7; emacs 29.4
Date: Thu, 16 Jan 2025 09:52:15 +0100
Message-ID: <87frlji1j4.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-ZohoMailClient: External
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: 75552 <at> debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>,
 45mg <45mg.writes@HIDDEN>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>, guix-devel@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Liliana Marie Prikler <liliana.prikler@HIDDEN> writes:

>> This has the slight issue that I can no longer easily answer a
>> question "is this commit in my fork", since I cannot search by the
>> commit hash. I admit it is not a question I need to answer often
>> (last time was on 21st of October, CVE-2024-52867).
> You could solve this by embedding an "upstream-commit:" trailer, but
> that is an admittedly cursed transformation that no longer maps to a
> single rebase, I admit.

You can use the Change-Id tag for this.  Our local hooks create them and
they stay intact after rebase.

-- 
Ricardo




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 16 Jan 2025 07:39:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 02:39:18 2025
Received: from localhost ([127.0.0.1]:59812 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYKTF-0004Wy-DS
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 02:39:17 -0500
Received: from mail-wr1-x441.google.com ([2a00:1450:4864:20::441]:53627)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <liliana.prikler@HIDDEN>)
 id 1tYKTB-0004Wi-FJ
 for 75552 <at> debbugs.gnu.org; Thu, 16 Jan 2025 02:39:15 -0500
Received: by mail-wr1-x441.google.com with SMTP id
 ffacd0b85a97d-38a88ba968aso555346f8f.3
 for <75552 <at> debbugs.gnu.org>; Wed, 15 Jan 2025 23:39:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1737013147; x=1737617947; darn=debbugs.gnu.org;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
 :date:message-id:reply-to;
 bh=/j+N9h/THXhDWij+p+iXLHSuN6cvkr8VDxnlgKBgfpY=;
 b=Lv1sjSeFoAok4Ftjp5w9NMzsz+W1erIc7JF0IEp8vDzEvbrPoBpFOUv0y2pFq6oJCf
 LdUIO1wExaD9ydWSAAO8i6xbB3/kk2rUGfqF2jMw0RQfCrwPG1pZ4/dRMPfIG7wYUBRr
 2R6xvIMpXn0Cw3RRlmgxxHhCj6Z/mlRO0ggq2lpW9z7H+6Gk2xANW7PxnRYX7GsOWEZk
 UQ4Hh7oXBGDZpQz54bOltkGcHxTUxUdoxD7Z/+sLlzJVckSfavCzzteTcvEnqCGTsoOC
 esglqsNVxp2IM2c7NemhKJufJkohCtDEsNoonJHtp2GU6EN2rO10y1h2L18DNGH4PVWQ
 Arpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1737013147; x=1737617947;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=/j+N9h/THXhDWij+p+iXLHSuN6cvkr8VDxnlgKBgfpY=;
 b=dQOgoCaBi0JTyVDkXVpS/awmjchj8xKiSR94KkK/C0gZs03pRsYYhBHkYWzqWODG0S
 350i255UoLRjGAuNQGnLzf/AB1hkliecDgQyV+uXqy9UAGXjJjOfTj5Gv7YSOmG7/8A+
 0JYP3ZRCoBRR+g2B9QvHN0Nzg7oRGPmzhdC/pYB7x5PpnTAkKKwLBHLgBe+WTcqlroEb
 LBC2/SuHOA9y77qHqyAdMd5jjSPXzqENT3gr0xchB10i0f6Xat6Ut1P7Pfoh6Kesm5Ye
 iqYHffBTnV1pAYz/KtiVpyoy98sBH8aS12KjTRJwzlGtRreWq6Ae18QOg2iqRljnvPxV
 3HrQ==
X-Forwarded-Encrypted: i=1;
 AJvYcCVCChmX4o2Rz6oPrHuxddwTqkx2Phl4KU+RZzdXp9ugOLKH3wH9qAA12+PxBEPslkSUHXZZQQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yzznl3wY5g1ZrIbOirKJVUwFihrl4ANoCXGqRO17v+s39a/n03u
 6jsny3bkKZD5d1tUONfTOFows79GVaZVAbpaACYgspFRxE8apffZ
X-Gm-Gg: ASbGncu8WV2mVOu8nRxiQ/uQ0brvh/eqzjquImQhZpwdyOMmbQjQn/As3xvnyYBDi9o
 +ERaXvtR0KlO1EVgnVY3GYRvlt6G1m5JWfWWyEuy1YV4eTvdLalSRIdNQUiwFIEEIUEA0Xu9Shi
 qSw9XGPlVkfl6Foych2T1oD+6hhj770T6EHCIS477cdwkJuwuWBkwDk6PRo9+5B9T/Tqr28nYQz
 kX+1TmcNxTxDvSCBMp7sosc7xfChtsvbobPOSDShOxZUu4c9j0OfEpC3m4lQN8AYVyOgrnmmSLI
 AcixLVJTGwWRdbBTVxjPxuPQ/tfwunsk
X-Google-Smtp-Source: AGHT+IHdVX6RQAcEL1RXN1nFjHb+tOAM6QdyvuGCEjrLd8rr6/9xMj7Fl/mO0yCc1wiP+uBDp4y45g==
X-Received: by 2002:a5d:47c9:0:b0:385:f66a:4271 with SMTP id
 ffacd0b85a97d-38a872fbcefmr22993949f8f.4.1737013147037; 
 Wed, 15 Jan 2025 23:39:07 -0800 (PST)
Received: from lumine.fritz.box (85-127-114-32.dsl.dynamic.surfer.at.
 [85.127.114.32]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c753c617sm49431525e9.37.2025.01.15.23.39.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 23:39:06 -0800 (PST)
Message-ID: <c3b1445d236ed95f768c218503089926788256a4.camel@HIDDEN>
Subject: Re: Non-committers can't keep authenticated forks updated
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
To: Tomas Volf <~@wolfsden.cz>
Date: Thu, 16 Jan 2025 08:38:59 +0100
In-Reply-To: <87a5brsmve.fsf@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 <87a5brsmve.fsf@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, 75552 <at> debbugs.gnu.org, 45mg <45mg.writes@HIDDEN>,
 help-guix@HIDDEN, Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Am Donnerstag, dem 16.01.2025 um 00:01 +0100 schrieb Tomas Volf:
> Liliana Marie Prikler <liliana.prikler@HIDDEN> writes:
>=20
> > I think you're making this more complicated than it needs to be.=20
> > checkout, authenticate, rebase*, merge*=C2=A0ought to have you covered.
> >=20
> > * you can authenticate after these if you're paranoid=20
> >=20
> > > We could create a script to do all the steps for us, but if and
> > > when it fails on whatever insane edge cases people are able to
> > > come up with, they're going to need to understand all the steps
> > > involved anyway. Abstraction is not a substitute for a clean
> > > underlying design.
> > >=20
> > > Also I just want to point out that rebasing /will/ change the
> > > history.  The `guix pull` after every time you update your fork
> > > will need to be a force-pull (--allow-downgrades [1]).
> > No, it wouldn't.=C2=A0 You would rebase those changes on top of what yo=
u
> > already have on those respective branches.
>=20
> This has the slight issue that I can no longer easily answer a
> question "is this commit in my fork", since I cannot search by the
> commit hash. I admit it is not a question I need to answer often
> (last time was on 21st of October, CVE-2024-52867).
You could solve this by embedding an "upstream-commit:" trailer, but
that is an admittedly cursed transformation that no longer maps to a
single rebase, I admit.

> And merging also (and this is more interesting property) ensures that
> *all* official commits are always present in my repository on the
> master branch.=C2=A0 So I can just use guix time-machine --commit without
> always forgetting `-q' argument and having to do it second time.
In my personal experience, time-machine breaks with third-party
channels all the time, so `-q` is probably good advice anyway.  But
yeah, that's a valid concern.

> I feel like the merging is a superior workflow for long-lived soft-
> fork, expect the (here debated) issue with authentication.
>=20
> > > Yes, to be clear, I'm talking about the use-case where your fork
> > > is hosted remotely, and you or someone else needs to pull changes
> > > from it.=C2=A0 For example, my prospective use case would be quickly
> > > bootstrapping Guix on a new machine - I build my own installation
> > > image, and I'd want it to pull from my fork. I can include my
> > > introduction into my installer, just like the official one. But
> > > if the introduction changes before I use my installer, then the
> > > first pull can't be authenticated.
> > I don't see why in your particular use case you can not use a
> > channel on top of Guix rather than replicating Guix itself.=C2=A0 Now
> > there might be some weird edge case I'm overlooking where you cut
> > deep into the dependency graph and that makes sense, but I sure
> > hope that's a rare edge case in and of itself.
>=20
> As long as the changes are limited to packages, it is (mostly) fine,
> you can get very far with (inherit) and various transformations.
>=20
> However changes outside of that are not that rare.=C2=A0 Few examples
> follow.
>=20
> Anything modifying services is a problem.=C2=A0 As far as I know, there i=
s
> no way to modify a service the way you can do with a package.
>=20
> I carry a modification to nftables-configuration which adds (tables)
> field so that I can do:
>=20
> --8<---------------cut here---------------start------------->8---
> (service
> =C2=A0nftables-service-type
> =C2=A0(nftables-configuration
> =C2=A0 (tables
> =C2=A0=C2=A0 (modify-nftables-tables %default-nftables-tables
> =C2=A0=C2=A0=C2=A0=C2=A0 (mod 'inet
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (mod 'input
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 (rep 'allow-ssh
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (if (and sshd-port open-sshd)
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (allow-d=
port-snippet "tcp" sshd-port)
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #f))))))=
))
> --8<---------------cut here---------------end--------------->8---
>=20
> It allows me to construct the firewall gradually, however I have not
> yet decided whether I like the API or not (leaning towards "no"), so
> I did not sent it upstream.
You can roll your own service definitions, but it does become harder
when you want to keep all changes to that service from master as well.
But `(use-modules (my-channel services nftables))` should pull that
nftables code :)

> #71981 is open since July 7 and I am not aware of a way to work
> around package->symbol deficiencies from a channel.
I mean, the right thing would be to address #71979, but I don't see
that being done either.  Ludo's fix is merely lexicographic and thus
breaks with directories that aren't simply ".".

> Then there is anything modifying any of the guix commands.=C2=A0 #74832 i=
s
> over month old, and as far as I know, I am not able to fix guix-copy
> from a channel.=C2=A0 #72928 took over a month to merge, and again, not
> sure how to patch guix-describe from a channel.
Have you considered extensions?

> (Yes, I am aware I can just copy&paste the service code into my
> channel.  But at that point I am again just "replicating Guix", just
> by more manual and error-prone means.=C2=A0 And even for packages,
> adjusting system configuration to use package from my channel,
> getting it merged and then adjusting back to upstream is annoying
> chore.)
You could code your channel in a way that it serves upstream stuff
either silently or with a deprecation warning if a particular package
is requested.  Not a channel, but [1] illustrates my point.

Cheers

[1] https://git.ist.tugraz.at/clingabomino/clingabomino/-/blob/0.2.0/pkg/gu=
ix.scm?ref_type=3Dtags#L30




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 15 Jan 2025 23:01:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 18:01:17 2025
Received: from localhost ([127.0.0.1]:59200 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYCNw-00056v-Oh
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 18:01:17 -0500
Received: from wolfsden.cz ([37.205.8.62]:43456)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <~@wolfsden.cz>) id 1tYCNs-00056b-OQ
 for 75552 <at> debbugs.gnu.org; Wed, 15 Jan 2025 18:01:14 -0500
Received: by wolfsden.cz (Postfix, from userid 104)
 id E038734A6FF; Wed, 15 Jan 2025 23:01:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail;
 t=1736982070; bh=eFtOqP7EAjDnacCRfGJG0Se50U+lAdfj7jIOs87m428=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=d1SOVgtrw2uZHxJZ+A0IRj9zSj99jgQrSZFqSrEauQoaHKjH8wvebrza82QVomm4m
 vHj/nWDa/G1ZZmsT/+K+mIXrpo5aC7P7xAz69Z8CRL3Ds4RUQwveORIx2sgxV47LaH
 c45KYILHz3s4w8OAohOyWcJCCxaBCUcwbM7ZGZn8Zjezw/uhDzykk4xs6kwMPMTj3X
 0K6sUXBAC480MV/IMcnDW3wkWMC3q/fYTwTHMMNOwn9ag62jjcwrwd4M9itq3soz+R
 24TyqP9tq+eVsfvenlPZ+1jgDusl8djIx2z8hzlT95fGek2nURKtH1CvUulPQ2I9/I
 VkpwCuw59VGoPkLqyBNLV0ZOjwGXsjw168lu1W1fLos6torcMfLPIiH6KTwCKsVam/
 OLrnh28TGBhBdRwcEJhk5eiVHEbWuKU+3/gqP6gWLmB81k+NXK5F4sJ0nHz3t9xTvP
 369xHJHPfZC3YaSME5ODSZtPbZW2CYga1ZgspxOzt3U/3QBDx/EZP1Aq0m/E+b8Mze
 CzgZuM1NqSwAZdC+iNw1Mhi1MB7TcA/1SsrCF/DRpleLhwBnNKtd4Bts+YHpO+OmAV
 NU9lqVqYrKRYLkVuBK3b2978Bh70j52B7g59/UbdR9Q2bmCzeYJIVKjSoFvkuL0RPL
 gvqXJkEIb6pXMXdOeG9KZ2JM=
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on wolfsden
X-Spam-Level: 
X-Spam-Status: No, score=-3.1 required=5.0 tests=ALL_TRUSTED,BAYES_00,
 DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_BLOCKED
 autolearn=ham autolearn_force=no version=3.4.6
Received: from localhost (unknown [128.0.188.242])
 by wolfsden.cz (Postfix) with ESMTPSA id 0370734C0A6;
 Wed, 15 Jan 2025 23:01:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail;
 t=1736982070; bh=eFtOqP7EAjDnacCRfGJG0Se50U+lAdfj7jIOs87m428=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=d1SOVgtrw2uZHxJZ+A0IRj9zSj99jgQrSZFqSrEauQoaHKjH8wvebrza82QVomm4m
 vHj/nWDa/G1ZZmsT/+K+mIXrpo5aC7P7xAz69Z8CRL3Ds4RUQwveORIx2sgxV47LaH
 c45KYILHz3s4w8OAohOyWcJCCxaBCUcwbM7ZGZn8Zjezw/uhDzykk4xs6kwMPMTj3X
 0K6sUXBAC480MV/IMcnDW3wkWMC3q/fYTwTHMMNOwn9ag62jjcwrwd4M9itq3soz+R
 24TyqP9tq+eVsfvenlPZ+1jgDusl8djIx2z8hzlT95fGek2nURKtH1CvUulPQ2I9/I
 VkpwCuw59VGoPkLqyBNLV0ZOjwGXsjw168lu1W1fLos6torcMfLPIiH6KTwCKsVam/
 OLrnh28TGBhBdRwcEJhk5eiVHEbWuKU+3/gqP6gWLmB81k+NXK5F4sJ0nHz3t9xTvP
 369xHJHPfZC3YaSME5ODSZtPbZW2CYga1ZgspxOzt3U/3QBDx/EZP1Aq0m/E+b8Mze
 CzgZuM1NqSwAZdC+iNw1Mhi1MB7TcA/1SsrCF/DRpleLhwBnNKtd4Bts+YHpO+OmAV
 NU9lqVqYrKRYLkVuBK3b2978Bh70j52B7g59/UbdR9Q2bmCzeYJIVKjSoFvkuL0RPL
 gvqXJkEIb6pXMXdOeG9KZ2JM=
From: Tomas Volf <~@wolfsden.cz>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Subject: Re: Non-committers can't keep authenticated forks updated
In-Reply-To: <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
 (Liliana Marie Prikler's message of "Wed, 15 Jan 2025 18:59:24 +0100")
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
 <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
Mail-Followup-To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 45mg
 <45mg.writes@HIDDEN>, 75552 <at> debbugs.gnu.org, guix-devel@HIDDEN,
 help-guix@HIDDEN, Felix Lechner <felix.lechner@HIDDEN>
Date: Thu, 16 Jan 2025 00:01:09 +0100
Message-ID: <87a5brsmve.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, 75552 <at> debbugs.gnu.org, 45mg <45mg.writes@HIDDEN>,
 help-guix@HIDDEN, Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Liliana Marie Prikler <liliana.prikler@HIDDEN> writes:

> I think you're making this more complicated than it needs to be.=20
> checkout, authenticate, rebase*, merge*=C2=A0ought to have you covered.
>
> * you can authenticate after these if you're paranoid=20
>
>> We could create a script to do all the steps for us, but if and when
>> it fails on whatever insane edge cases people are able to come up
>> with, they're going to need to understand all the steps involved
>> anyway. Abstraction is not a substitute for a clean underlying
>> design.
>>=20
>> Also I just want to point out that rebasing /will/ change the
>> history.
>> The `guix pull` after every time you update your fork will need to be
>> a force-pull (--allow-downgrades [1]).
> No, it wouldn't.  You would rebase those changes on top of what you
> already have on those respective branches.

This has the slight issue that I can no longer easily answer a question
"is this commit in my fork", since I cannot search by the commit hash.
I admit it is not a question I need to answer often (last time was on
21st of October, CVE-2024-52867).

And merging also (and this is more interesting property) ensures that
*all* official commits are always present in my repository on the master
branch.  So I can just use guix time-machine --commit without always
forgetting `-q' argument and having to do it second time.

I feel like the merging is a superior workflow for long-lived soft-fork,
expect the (here debated) issue with authentication.

>> Yes, to be clear, I'm talking about the use-case where your fork is
>> hosted remotely, and you or someone else needs to pull changes from
>> it.  For example, my prospective use case would be quickly
>> bootstrapping Guix on a new machine - I build my own installation
>> image, and I'd want it to pull from my fork. I can include my
>> introduction into my installer, just like the official one. But if
>> the introduction changes before I use my installer, then the first
>> pull can't be authenticated.
> I don't see why in your particular use case you can not use a channel
> on top of Guix rather than replicating Guix itself.  Now there might be
> some weird edge case I'm overlooking where you cut deep into the
> dependency graph and that makes sense, but I sure hope that's a rare
> edge case in and of itself.

As long as the changes are limited to packages, it is (mostly) fine, you
can get very far with (inherit) and various transformations.

However changes outside of that are not that rare.  Few examples follow.

Anything modifying services is a problem.  As far as I know, there is no
way to modify a service the way you can do with a package.

I carry a modification to nftables-configuration which adds (tables)
field so that I can do:

=2D-8<---------------cut here---------------start------------->8---
(service
 nftables-service-type
 (nftables-configuration
  (tables
   (modify-nftables-tables %default-nftables-tables
     (mod 'inet
          (mod 'input
               (rep 'allow-ssh
                    (if (and sshd-port open-sshd)
                        (allow-dport-snippet "tcp" sshd-port)
                        #f))))))))
=2D-8<---------------cut here---------------end--------------->8---

It allows me to construct the firewall gradually, however I have not yet
decided whether I like the API or not (leaning towards "no"), so I did
not sent it upstream.

#71981 is open since July 7 and I am not aware of a way to work around
package->symbol deficiencies from a channel.

Then there is anything modifying any of the guix commands.  #74832 is
over month old, and as far as I know, I am not able to fix guix-copy
from a channel.  #72928 took over a month to merge, and again, not sure
how to patch guix-describe from a channel.

So, while I fully agree that package modifications *are* possible with
channel and are more common type of patch to carry, things that are
*not* possible with channel are (at least in my tree), while not as
frequent, definitely not a "rare edge case".

(Yes, I am aware I can just copy&paste the service code into my channel.
But at that point I am again just "replicating Guix", just by more
manual and error-prone means.  And even for packages, adjusting system
configuration to use package from my channel, getting it merged and then
adjusting back to upstream is annoying chore.)

Tomas

=2D-=20
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJCBAEBCgAsFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmeIPjUOHH5Ad29sZnNk
ZW4uY3oACgkQL7/ufbZ/wakLmw//eQ+au8ZRyfXjXjnS14nDF88FRVMyobjhyx+C
FtlK92au5y82D2Zj18KYbFrEKfn9AbxwKhi751CRJ7g3Y67TciITOVJi9zhb2v5q
po5KBJRZSO4gX3DOCQ68W2/3h0+SFz8qWH/ZzK74CeynmGYEc92qFu3vuFqciMcL
bBmU0/jzjul5T/Plx/5rFjNG9NUY1B+ms7OBIrPK7kd/ONyVTey7RFe5Ql/9+Ghz
m/s3l8YD5Qwpr7VeNr0uZV4MtLcO+vurYuB65Ck8/l+7mqfYmV4OcdNQXTb4E/89
p0foswQ6T4DmaaZTZUa891i/2qvVY8xLQt4vlKRb3fm99kVeI4NQZxweU/tqoJA+
p0hMYvVmozH015DmdalZqqArwcMlE2123N0tmT3UiYzWS8KyRllLEwA/aFVdNPpy
ACHN2fM01hB/E18kdYyfnbGWK3dDPjQg1yWyC3xGj0GMb4ZPCebDASzC3dMMrBFl
f6dzGZHERMU4gzdxFltxn5bVfYljJw2mnQ3SH55wZfFM+OtPQF+yNk126oUbhrVz
GaVXkzqCI/5Wg7z/NRTNTElcOVDe3AHHsu71pNUGFNfBhFZ8gtlWBw+kvvU6PX0h
cnoE4iZ2Sez7/qDJRmmz7n+NBSNVHRrRKCT6UlBw4pavCA2J0uSjYCPsPtGGzq9V
dBDVry0=
=FLym
-----END PGP SIGNATURE-----
--=-=-=--




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 15 Jan 2025 17:59:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 12:59:38 2025
Received: from localhost ([127.0.0.1]:58645 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tY7g1-0004sb-LE
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 12:59:38 -0500
Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]:57422)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <liliana.prikler@HIDDEN>)
 id 1tY7fz-0004sI-AO
 for 75552 <at> debbugs.gnu.org; Wed, 15 Jan 2025 12:59:36 -0500
Received: by mail-wm1-x344.google.com with SMTP id
 5b1f17b1804b1-4362f61757fso67816285e9.2
 for <75552 <at> debbugs.gnu.org>; Wed, 15 Jan 2025 09:59:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1736963969; x=1737568769; darn=debbugs.gnu.org;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
 :date:message-id:reply-to;
 bh=abQC8MvNVFFXTg813mfuo/SJeBYJPzgWNu1FUHiP29E=;
 b=FU+bGR/wG9aeq7hzW3HZBrJPU6nwvJx/x7C+VIdU7eN0FNPNHd2Yl+xQq3NPp5zsmO
 GBcdZ2OV3BqsWqz/r0rtXvuE1tbCGBy2PEm8B5qGGk397368ft0/c919FXkxOUhAEBo1
 lQ1E2OKj4GOBqWS2kXNTzHr2HKFUvuyEUQJK7RC0bfh5CwAVJjmFi7pMzssIXEW5jji5
 n7dbnfKY9chTmKyG/jiUHiCJdLbS3qCt5vIhlsL8KnkXboINtbgKK+N4wm5KGS4VE/36
 9XPBLFrrMN+exmoStyNTmzeYQ82jbWimCpz0bm8T41CP4Iq7z2du5R3l6F44yTC2yb9D
 7dIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1736963969; x=1737568769;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=abQC8MvNVFFXTg813mfuo/SJeBYJPzgWNu1FUHiP29E=;
 b=fDtVVxfj3in0/y3Nf+QYJEgIh87E/Zn7f7rClBR4C1l4ns9pSxKrJ8MqhnEntbZIFh
 Ghf3lahVNG3/xMRR9i2xlYgAbvAIeVfnztQr+EiI+4AbJXCCxmWYmA5Ae4h3Zs2QPf7c
 YyawsTeQzyhIbjqOwedsLd+0PvRCoYNd/VQ6dF/SEAVmHWsvCEMokM635Y2UJRVdpVGq
 7Oy8oPuhXDBNZZzYFHrN4Kl64M/GlQVrzZa6vj1i+XQ5xsPMZt9G3NypZYJcQffFBNWE
 X/XpYAdEHb64I1Y/I2+oHZ7u2Zk2ze/FLuggC2ClYdo5Bnxow2dGMpjIgIosDJdTSiYl
 LkNQ==
X-Forwarded-Encrypted: i=1;
 AJvYcCV+RKPHS7XInSDONXmy+p0UUdFt8D+uHX+Ehpr/YAKgUCfj+jRcGvEqcAg3tb2f3Lx1qxLNiw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yyh7qBSek/5L4dGh30fh5N3rkyCRnuxjqxVGaIgq+qYGO8511S+
 69tJQWc3nbm85OsuFRfz6qhNfTy47Zob7KtnuZGJTZRA4LqhMbu1
X-Gm-Gg: ASbGncuVFpKjDWD2MGnz8YR24Rn8Om/4XIsjogONZ/I47MhS4EarZBTZXnH5NemQ8wm
 EFXWvN9MuQtYLJAsklsmsTj1jC3OSfn8gCTjWRaZEGk8j5hAuLDK06yRo9fyh0+WrAVt1ReUV0V
 30p+rCv+9vBMHquE9J5zbKczZSbfvngP/NgDxGcqvRTKVP8yGKdPlKrfCkXJfleHVPpZIlKs5cz
 68ITTkgsFUH5cAqH3VhIHkI5uaXBoGUgNkSTAg51a+C5hKoERFqG5ibFx6P3jHu2Jl14kdDcO+8
 mo6CoKmaeTPkugqmCbScMixQbaAxEz9t
X-Google-Smtp-Source: AGHT+IFTuw1iOVxAuCGab7HpsvvP8uUxmDLj4DYxhaSxsKb0aRpK6ISPx+WTCG5fLQIMDVEq785uWg==
X-Received: by 2002:a5d:47af:0:b0:38b:dbeb:63a2 with SMTP id
 ffacd0b85a97d-38bdbeb64acmr11336743f8f.55.1736963968848; 
 Wed, 15 Jan 2025 09:59:28 -0800 (PST)
Received: from lumine.fritz.box (85-127-114-32.dsl.dynamic.surfer.at.
 [85.127.114.32]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-437c74c5cdfsm32061755e9.21.2025.01.15.09.59.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 09:59:28 -0800 (PST)
Message-ID: <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@HIDDEN>
Subject: Re: Non-committers can't keep authenticated forks updated
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
To: 45mg <45mg.writes@HIDDEN>, 75552 <at> debbugs.gnu.org
Date: Wed, 15 Jan 2025 18:59:24 +0100
In-Reply-To: <87h660xeld.fsf@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
 <87h660xeld.fsf@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, Tomas Volf <~@wolfsden.cz>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi,

Am Mittwoch, dem 15.01.2025 um 15:48 +0000 schrieb 45mg:
> The idea of authentication is that once you trust the channel
> introduction, you can be sure that everything you pull after that is
> authentic. The introduction only needs to be trusted once. If you're
> bumping the introduction every time, then you need to obtain and
> verify the introduction every time. You're going from 'Trust On First
> Use' to 'Trust On Every Use'. Not ideal IMO.
Let's recall that the entity you need to trust is still yourself in
most of those cases. =20

> You could do it like this:
> 0) Before creating your fork, authenticate every commit in the Guix
> =C2=A0=C2=A0 checkout (as described in the manual).
> 1) Switch to your branch that tracks upstream.
> 2) Pull from upstream.
> 3) Run `guix git authenticate`, supplying Guix's channel introduction
> as
> =C2=A0=C2=A0 arguments.
> 4) After this succeeds, create and switch to a branch from the
> current
> =C2=A0=C2=A0 tip of your upstream-tracking branch. Edit .guix_authorizati=
ons to
> =C2=A0=C2=A0 add your key, and create a signed commit.
> 5) Merge this branch into your fork branch.
> 6) Switch back to your fork branch.
> 7) Delete the [guix "authentication"] section from .git/config.
> 8) Run `guix git authenticate` with the introduction of your fork
> =C2=A0=C2=A0 branch, to authenticate the merge commit.
>=20
> That's a lot of manual steps for every pull from upstream! While I do
> have to give you credit for this idea - at least we now have a
> workaround for people who are determined enough - I'm guessing a lot
> of people will probably just skip authentication if it's going to be
> this annoying. Authenticating a fresh clone from scratch will be even
> more annoying, especially if you have multiple fork branches (eg.
> you're tracking someone else's fork).
I think you're making this more complicated than it needs to be.=20
checkout, authenticate, rebase*, merge*=C2=A0ought to have you covered.

* you can authenticate after these if you're paranoid=20

> We could create a script to do all the steps for us, but if and when
> it fails on whatever insane edge cases people are able to come up
> with, they're going to need to understand all the steps involved
> anyway. Abstraction is not a substitute for a clean underlying
> design.
>=20
> Also I just want to point out that rebasing /will/ change the
> history.
> The `guix pull` after every time you update your fork will need to be
> a force-pull (--allow-downgrades [1]).
No, it wouldn't.  You would rebase those changes on top of what you
already have on those respective branches.

> > Of course, you can also keep your own fork unauthenticated, which
> > might be preferable if you only do local work anyway, but that's
> > besides the issue here.
>=20
> Yes, to be clear, I'm talking about the use-case where your fork is
> hosted remotely, and you or someone else needs to pull changes from
> it.  For example, my prospective use case would be quickly
> bootstrapping Guix on a new machine - I build my own installation
> image, and I'd want it to pull from my fork. I can include my
> introduction into my installer, just like the official one. But if
> the introduction changes before I use my installer, then the first
> pull can't be authenticated.
I don't see why in your particular use case you can not use a channel
on top of Guix rather than replicating Guix itself.  Now there might be
some weird edge case I'm overlooking where you cut deep into the
dependency graph and that makes sense, but I sure hope that's a rare
edge case in and of itself.

> > This does not state how the additional introductions are used, if
> > at all.=C2=A0 It may mean that the additional introductions are
> > pointless other than for blocking case 4.
>=20
> My bad, I guess I forgot to explain that.
>=20
> The purpose of the additional introductions is to make it so that
> signed commits from upstream Guix, or commits from other people's
> forks, can still be authenticated. As I mentioned above, the current
> design is not suited to this.
>=20
> To go a bit more into detail - we will accomplish authentication by
> doing a postorder traversal of the commit tree, considering the
> latest commit as the root node. We traverse its parents recursively
> until we reach a commit whose parent is one of the channel
> introductions (primary or additional). Then that commit and all its
> children are authenticated from the introduction that we encountered.
> In this way, every commit is authenticated from the introduction that
> is its most recent ancestor.
Yeah, I think this scheme will still end up in [4].  As pointed out in
[8], "primary" is just a convention that we can't rely on.  So let's
just talk about the idea of widening one channel introduction to any
number of channel introductions =E2=80=93 we can always store a mapping of =
HEAD
=E2=86=92 first authenticated commit and then assert that this set is a sub=
set
of what we declare as introductions. =C2=A0(This mapping will also make
authentication as efficient as it currently is, since we don't need to
reauthenticate everything all the time.)

Is this good enough?  No: an attacker could easily add their own
introduction and call it a day.  In fact, this scheme is even worse
than what was exploited in [4], because they never need commit access
to the Guix repo to do so.  Ahh, but wait!  `guix pull` on the user's
side uses their clean set of channels for authentication.  Those only
have upstream Guix=E2=80=A6 unless you actually pull your own fork or manag=
e an
attack as outlined below (in which case you do need commit access for
some amount of time).

> > I think this might still hide a serious flaw.=C2=A0 With the way
> > *upstream* authentication works.=C2=A0 Let's flip the example in [6]
> > around a little bit and construct the following:
> >=20
> > -A---B---C---D
> > =C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \
> > =C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \-E---F---=F0=9F=92=
=80
> > =C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /
> > =C2=A0=C2=A0=C2=A0=C2=A0 \----G--H--I*-/
> > =C2=A0=20
> > Both A and I* are introductory commits on their various branches.=C2=A0
> > In =F0=9F=92=80, any committer who has valid keys in both F and I* can =
merge
> > a branch with unsigned commits, effectively voiding the invariant
> > of BCEF, e.g. by undoing any changes that happened there.=C2=A0 Of
> > course, they can do so with signed commits as well, given that they
> > have commit access to the main repository, but the point still
> > holds that they may introduce unsigned commits to any fork where
> > their key is valid in.
>=20
> So, my design enables an attacker who can make authorized signed
> commits to also introduce changes made in unsigned commits. Hmm.
>=20
> I don't think this compromises our current security guarantees,
> though?
I mean, the promise we do make is that all commits starting from a
certain commit are signed.  So IMHO, this effectively breaks that :)

>   If the attacker can already make trusted commits, then any attack
> they can perform in the way you described can also be done directly
> with signed commits onto F, as you pointed out. And the latter way
> would be far simpler for them.
Simpler, yes, but less stealthy.  Most contributors don't concern
themselves with the specifics of any particular branch, and you may
even be able to dress up your evil branch as a good branch until the
point where you finally merge it.

> Also, the branch they merged into would not contain any unsigned
> commits; the commit '=F0=9F=92=80' is still signed with a key authorized =
for
> F's branch. So at most, we can say that the attacker can introduce
> /changes made in/ unsigned commits, not 'introduce unsigned commits'.
They can make an arbitrary number of unsigned commits before needing to
sign off one commit that will be merged.  If they follow the style of
merging master into their branch and then their branch into master,
said commit can even be empty, though that would no longer be stealthy.
Now if they were to I don't know, bump 9000 Rust packages or something
like that, they have a lot of space to exploit the as-of-yet in this
manner unexploited, but still weak SHA-1 hashes Git uses.

> Once you manage to revoke their commit access, you'd just revert the
> '=F0=9F=92=80' commit and delete the GHI branch (which is the one that co=
ntains
> unsigned commits). The same way you'd recover from them directly
> making malicious changes on master.
Reverting this change could land you in early 2025.  And worse, your
attacker could lure you onto their branch if you happen to land on any
bad commit in the meantime.

Cheers

[8] https://lists.gnu.org/archive/html/help-guix/2025-01/msg00116.html




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at 75552 <at> debbugs.gnu.org:


Received: (at 75552) by debbugs.gnu.org; 15 Jan 2025 15:49:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 10:49:06 2025
Received: from localhost ([127.0.0.1]:58382 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tY5di-0007VB-5V
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 10:49:06 -0500
Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]:42292)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <45mg.writes@HIDDEN>)
 id 1tY5dc-0007UU-P4
 for 75552 <at> debbugs.gnu.org; Wed, 15 Jan 2025 10:49:03 -0500
Received: by mail-pl1-x642.google.com with SMTP id
 d9443c01a7336-2167141dfa1so20087535ad.1
 for <75552 <at> debbugs.gnu.org>; Wed, 15 Jan 2025 07:49:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1736956134; x=1737560934; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
 :reply-to; bh=HPMnsRQXxH8pkoE0/qqn/AksOCtWiSIF8CVPAYkLsh4=;
 b=YsKK+w54pRoghXgxKxppkmyuC9FWBzmtff0sImgEInrK9KjNa7T2qqAcdOFGUTUERA
 HJXYVfCsEL0shLqVTwiSIcbiG8zZ7yqVXglEkc8toqj6AvzDkma4AiFRy/WVaxLnuOun
 5Ii00w6eGxSNN4/xn4oeEiZtUJeanPnVkj8HDQzvkR5aYatQw08pYoxlCTTqOZC6OZjr
 KaXrDfMczb1h81BwhBLIXUjBrNnvJDR2AchSNjhFeO32IRhDvyNim4WvxqhXq2WcqpV3
 p6UMjgynutw0zxRPNDAGH5O2V0tz7FmQ5j3cbn9c/M+9BceXhfIy2fJNFubSLukfmasm
 pZSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1736956134; x=1737560934;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=HPMnsRQXxH8pkoE0/qqn/AksOCtWiSIF8CVPAYkLsh4=;
 b=qbfhrdsWf7sCyzKPp6eA7ZKgVzgKr4gQ7QRCRlvDPd9xJInGyo/nHQRLBeyNgS0eUX
 LkhMrZjcUWJdwBvLDvRMoUXZLxpMyscizuzbW6vUKfjBRtNGO0LKixm1LcWaIk6wDetG
 zyhRL7ByCrdDVfjS5jRjQrvmjYRUEFLKLbjZt3ODs/kNQqFqBbq9bepiUDnGT0hmJhgX
 bzX6NAczbruWzyAbyImRxwutOitGtd36SuifZJUlSJK9wFLtM3LMXugamv9npl82ERDk
 pQHozmkIpeXgZcuLKJW/1MRfYLi1k4TAF/gJkAM4gS9BsE+EXM4WC/3jsZHaoUUEW3sX
 ILJA==
X-Forwarded-Encrypted: i=1;
 AJvYcCUGrKaxBZtCFEkqy71ICqx1LB5Jcny+9y85+bBsmfD/cmSOzxVLne1gxBMrF/L/9+DyMEmo7w==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxuDJtfpJ0mkwNSO+xsw0GianfzDXiefE5B16+sQcrRF7vdu9gB
 qSU4ZPg6ncgNfrYlzs3raUfiYJuKoTuyuG/bx8hAvMgQIdBe4Yra
X-Gm-Gg: ASbGnctDdBr574cgIX/TEg40f6xP61vBZ/ufiPxANht6pbD+mQoUDeAZ2EcRjVeeZf7
 ypqjdqjAej14aeFg6f+DR4XH4C0orFlFNyMhIfquYm5YBA9+E5rM73mWNvB6LtHpa849F4PKTiB
 ShVEAH8dkKTlplvw6iTlOBU20H3Y4sfydlM1X5cVtLbDuT1CP/g3JBZTB7jXDrNi2wu1liJZ87b
 56P3BUNKwP0o6z2tIWzwwgV3gW6wvYekxEulhYI9ZUukmDjShnne6SO2g==
X-Google-Smtp-Source: AGHT+IF80avSI55eMib4Wpw5KQ6rY6crgRO6rs+zq83LhDRpF7+HvSp8K9XJ7k/cS4ZZyUnzlK1E4A==
X-Received: by 2002:a17:902:ce8d:b0:215:a56f:1e50 with SMTP id
 d9443c01a7336-21bf0b9af0fmr48601225ad.8.1736956134310; 
 Wed, 15 Jan 2025 07:48:54 -0800 (PST)
Received: from guix1 (utm3.nitt.edu. [14.139.162.2])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-21a9f10df57sm83955295ad.12.2025.01.15.07.48.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 07:48:54 -0800 (PST)
From: 45mg <45mg.writes@HIDDEN>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 75552 <at> debbugs.gnu.org
Subject: Re: Non-committers can't keep authenticated forks updated
In-Reply-To: <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
 <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
Date: Wed, 15 Jan 2025 15:48:46 +0000
Message-ID: <87h660xeld.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75552
Cc: guix-devel@HIDDEN, Tomas Volf <~@wolfsden.cz>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Liliana!

Liliana Marie Prikler <liliana.prikler@HIDDEN> writes:

> For most use cases, this is a non-issue.  Assuming you are a single
> committer to your fork, you can always rebase your changes on top of
> Guix (if you're willing to bump the introductory commit)

The idea of authentication is that once you trust the channel
introduction, you can be sure that everything you pull after that is
authentic. The introduction only needs to be trusted once. If you're
bumping the introduction every time, then you need to obtain and verify
the introduction every time. You're going from 'Trust On First Use' to
'Trust On Every Use'. Not ideal IMO.

> or sign the changes to Guix with your own key (if you are willing to
> accept that this changes the history). With multiple committers, you
> will need to do the latter.

While this could actually work, without changing the history, the
problem is that there is no easy way to authenticate upstream commits.

You could do it like this:
0) Before creating your fork, authenticate every commit in the Guix
   checkout (as described in the manual).
1) Switch to your branch that tracks upstream.
2) Pull from upstream.
3) Run `guix git authenticate`, supplying Guix's channel introduction as
   arguments.
4) After this succeeds, create and switch to a branch from the current
   tip of your upstream-tracking branch. Edit .guix_authorizations to
   add your key, and create a signed commit.
5) Merge this branch into your fork branch.
6) Switch back to your fork branch.
7) Delete the [guix "authentication"] section from .git/config.
8) Run `guix git authenticate` with the introduction of your fork
   branch, to authenticate the merge commit.

That's a lot of manual steps for every pull from upstream! While I do
have to give you credit for this idea - at least we now have a
workaround for people who are determined enough - I'm guessing a lot of
people will probably just skip authentication if it's going to be this
annoying. Authenticating a fresh clone from scratch will be even more
annoying, especially if you have multiple fork branches (eg. you're
tracking someone else's fork).

We could create a script to do all the steps for us, but if and when it
fails on whatever insane edge cases people are able to come up with,
they're going to need to understand all the steps involved anyway.
Abstraction is not a substitute for a clean underlying design.

Also I just want to point out that rebasing /will/ change the history.
The `guix pull` after every time you update your fork will need to be a
force-pull (--allow-downgrades [1]).

> Of course, you can also keep your own fork unauthenticated, which
> might be preferable if you only do local work anyway, but that's
> besides the issue here.

Yes, to be clear, I'm talking about the use-case where your fork is
hosted remotely, and you or someone else needs to pull changes from it.
For example, my prospective use case would be quickly bootstrapping Guix
on a new machine - I build my own installation image, and I'd want it to
pull from my fork. I can include my introduction into my installer, just
like the official one. But if the introduction changes before I use my
installer, then the first pull can't be authenticated.

> This does not state how the additional introductions are used, if at
> all.  It may mean that the additional introductions are pointless other
> than for blocking case 4.

My bad, I guess I forgot to explain that.

The purpose of the additional introductions is to make it so that signed
commits from upstream Guix, or commits from other people's forks, can
still be authenticated. As I mentioned above, the current design is not
suited to this.

To go a bit more into detail - we will accomplish authentication by
doing a postorder traversal of the commit tree, considering the latest
commit as the root node. We traverse its parents recursively until we
reach a commit whose parent is one of the channel introductions (primary
or additional). Then that commit and all its children are authenticated
from the introduction that we encountered. In this way, every commit is
authenticated from the introduction that is its most recent ancestor.

> I think this might still hide a serious flaw.  With the way *upstream*
> authentication works.  Let's flip the example in [6] around a little
> bit and construct the following:
>
> -A---B---C---D
>   \       \
>    \       \-E---F---=F0=9F=92=80
>     \               /
>      \----G--H--I*-/
>=20=20=20
> Both A and I* are introductory commits on their various branches.  In
> =F0=9F=92=80, any committer who has valid keys in both F and I* can merge=
 a
> branch with unsigned commits, effectively voiding the invariant of
> BCEF, e.g. by undoing any changes that happened there.  Of course, they
> can do so with signed commits as well, given that they have commit
> access to the main repository, but the point still holds that they may
> introduce unsigned commits to any fork where their key is valid in.

So, my design enables an attacker who can make authorized signed commits
to also introduce changes made in unsigned commits. Hmm.

I don't think this compromises our current security guarantees, though?
If the attacker can already make trusted commits, then any attack they
can perform in the way you described can also be done directly with
signed commits onto F, as you pointed out. And the latter way would be
far simpler for them.

Also, the branch they merged into would not contain any unsigned
commits; the commit '=F0=9F=92=80' is still signed with a key authorized fo=
r F's
branch. So at most, we can say that the attacker can introduce /changes
made in/ unsigned commits, not 'introduce unsigned commits'.

Once you manage to revoke their commit access, you'd just revert the
'=F0=9F=92=80' commit and delete the GHI branch (which is the one that cont=
ains
unsigned commits). The same way you'd recover from them directly making
malicious changes on master.

[1] https://issues.guix.gnu.org/41604#16-lineno14




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 15 Jan 2025 09:41:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 04:41:49 2025
Received: from localhost ([127.0.0.1]:56964 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tXzuG-0003Pu-A4
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 04:41:49 -0500
Received: from lists.gnu.org ([2001:470:142::17]:38278)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <liliana.prikler@HIDDEN>)
 id 1tXzuC-0003Pb-EA
 for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 04:41:45 -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 <liliana.prikler@HIDDEN>)
 id 1tXzu6-00069u-JM; Wed, 15 Jan 2025 04:41:38 -0500
Received: from mail-ej1-x641.google.com ([2a00:1450:4864:20::641])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <liliana.prikler@HIDDEN>)
 id 1tXzu4-0006Ts-TS; Wed, 15 Jan 2025 04:41:38 -0500
Received: by mail-ej1-x641.google.com with SMTP id
 a640c23a62f3a-aab925654d9so506311066b.2; 
 Wed, 15 Jan 2025 01:41:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1736934094; x=1737538894; darn=gnu.org;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
 :date:message-id:reply-to;
 bh=cRIjWB6aGwHaosegQQZ1fD5Gzgvn7vf9adh2XpKnOvs=;
 b=ShO2R9jp7wiRnWd9IhcYS3NXy1wy4MXcZZMq20DFhE2MHji5d4lExq156n6Ap/ZjBG
 PRTLunzxHad6J3VwwuIOkUX5U2gBDmuyfj4QA9GW1XCEFlhIbjR/k5FEblrydY/bzmHD
 QUt/JWhXQi8Zg6Jav8hgWS82hTEgo2hnV4UKHuPoNqmFkbGYXIiLCo013GnV7w5aP3Jt
 SzmjhuVgG7lPBjiXUwT9ywhih/wmzc8j20UW/Z9xeQsTGqMtAZ2P+gURl+Av938uNxU7
 tMKvRzldnQoh6mTp5w/UbuqokIwH/oZ6hxihRo359mzngKL1Yl95t1LPnc4ZzyZoSg1h
 f1wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1736934094; x=1737538894;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=cRIjWB6aGwHaosegQQZ1fD5Gzgvn7vf9adh2XpKnOvs=;
 b=RinIj9mblW/gPFbSLEI877W+AZn9X/nUBHSZogv3/qKXXpFJQVMYis6iC72YNHX/EI
 3A8kFYdZtLgGNggMAFoe/UeYSDzINIvkqGeOli+8cKQ2OVAKyrkeELcxfanrN+t5a2oI
 Lpz3EP8i8PjrfjT66lWUtR7JnjDMx2rrDawuPHJCc/U/kp481CocPp/zVljGRbtUDaid
 UaJs489j/UI6saN/uAP53yB3/rKGrs8ERFCq9ieHP910sCt9uejmZI3YX+cX+r4h8ulU
 sCX+AuOlrfMVMjRhgs2XEWOE5ONSsI+p0y6zmnDR0G0xM2jc/NRUAkZ5lNYm9AJ/MxeF
 IVHQ==
X-Forwarded-Encrypted: i=1;
 AJvYcCWkollvmYaFeXO2kx+VAjJmkEezXsgoliyJfg2wbJ7z2aorPnUrM2n7PuMP5kBxFP1fvcw20MTh/CjW@HIDDEN,
 AJvYcCXh06WPH2JMeAucTqLEvGzT9A1dTw8fjNwjrUSATp0EB/sfzD8YqOo1Nav0cdFPeWf/5d3O+5LfQQ==@gnu.org
X-Gm-Message-State: AOJu0YztJ91+EIDGOsr3Nvg/bDOqaCo8AH9u03YxssVejmXb5cqoIVAe
 zakklK18brr2X0CcFc+5nkU56X116fyyi0XlzBr8dIXpupbH+dgR
X-Gm-Gg: ASbGncuz7dWAL/Dwr7PvTLU6N0tP881Ojq0RmVVi54ELbGevgUnGG7Fs9ya7yI8RCWP
 8aPf9MyOfNxwVL5tWmj8dcczOZONDct39NjxWgnbFEVNddJ8yMhWr4tNybi7mh81WixC0luZi5z
 6SgeJRYud5hzAGeQUtZmi/KK+ApWukykJi/IO1MWkgLo5oqQZExPUjLS5raSfujIWbBJH1OUPpd
 ajZlmSzZTmY9OJFb+vzQSq5oe591bN8EvXab0QCmKmoUvoKhNXQrXEYOuR5lELFlLzbVgociTrg
 xZZgWDbTotaFrWUAf/aUQNG4/FIMprND
X-Google-Smtp-Source: AGHT+IE5sXNecNokVPGF7wUONMIf+wU06GTqt4BJEifqvWOIzt9eUZZ4Ok+CH8q+Gx80KPTitFCNiQ==
X-Received: by 2002:a17:906:ef0b:b0:aa6:8096:204d with SMTP id
 a640c23a62f3a-ab2ab6a8e78mr2862566866b.3.1736934094126; 
 Wed, 15 Jan 2025 01:41:34 -0800 (PST)
Received: from lumine.fritz.box (85-127-114-32.dsl.dynamic.surfer.at.
 [85.127.114.32]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ab2c9060de9sm743686266b.11.2025.01.15.01.41.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 15 Jan 2025 01:41:33 -0800 (PST)
Message-ID: <a0bd47239c7b8443e26e75c858a896db3d00c987.camel@HIDDEN>
Subject: Re: Non-committers can't keep authenticated forks updated
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
To: 45mg <45mg.writes@HIDDEN>, bug-guix@HIDDEN
Date: Wed, 15 Jan 2025 10:41:29 +0100
In-Reply-To: <878qrednyx.fsf@HIDDEN>
References: <878qrednyx.fsf@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 
MIME-Version: 1.0
Received-SPF: pass client-ip=2a00:1450:4864:20::641;
 envelope-from=liliana.prikler@HIDDEN; helo=mail-ej1-x641.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
Cc: guix-devel@HIDDEN, Tomas Volf <~@wolfsden.cz>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Am Dienstag, dem 14.01.2025 um 04:21 +0000 schrieb 45mg:
> --8<---------------cut here---------------start------------->8---
> When authenticating merge commits, intersection of authorized keys
> from all parents is used. That is fine in Guix proper, since all
> involved commits are under the control of the Guix committers,
> however it does not work that well for authenticating merge commits
> in forks.
>=20
> When Guix fork is created (starting from Guix-proper commit A), new
> commit (authorizing the fork creator's signing key K) is created (I).
> Later, when update from Guix proper (U) is merged, new merge commit
> is created (M):
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0 M
> =C2=A0=C2=A0=C2=A0 / \
> =C2=A0=C2=A0 I=C2=A0=C2=A0 U
> =C2=A0=C2=A0=C2=A0 \ /
> =C2=A0=C2=A0=C2=A0=C2=A0 A
>=20
> The M is signed with the K. However since the K is allowed by only
> one parent (I), it will not be in the set of authorized keys
> (intersection of keys from I and U). So, commit M cannot be
> authenticated.
>=20
> Thus, an authenticated fork cannot be kept updated.
> --8<---------------cut here---------------end--------------->8---
For most use cases, this is a non-issue.  Assuming you are a single
committer to your fork, you can always rebase your changes on top of
Guix (if you're willing to bump the introductory commit) or sign the
changes to Guix with your own key (if you are willing to accept that
this changes the history).  With multiple committers, you will need to
do the latter.  Of course, you can also keep your own fork
unauthenticated, which might be preferable if you only do local work
anyway, but that's besides the issue here.

> [=E2=80=A6]
>=20
> For commits that have multiple parents - ie. merge commits - we
> weaken the authorization invariant [6] as follows:
>=20
> 1. If all parents have the primary introduction as their most recent
> =C2=A0=C2=A0 ancestor, then the invariant holds as usual.
> =C2=A0=C2=A0=20
> 2. If one or more parents has the primary introduction as its most
> =C2=A0=C2=A0 recent ancestor (call these the 'primary parents'), and the =
rest=20
>    have any of the additional introductions, then the merge commit is
> =C2=A0=C2=A0 authenticated if and only if:
> =C2=A0=C2=A0 a) it's signed by a key authorized in all of the primary par=
ents,
>    AND
> =C2=A0=C2=A0 b) the /first parent/ [^] of the merge commit is a primary p=
arent.
This does not state how the additional introductions are used, if at
all.  It may mean that the additional introductions are pointless other
than for blocking case 4.
=C2=A0=C2=A0=20
> 3. If all parents have the same additional introduction as their most
> =C2=A0=C2=A0 recent ancestor, then the invariant holds as usual.
>=20
> 4. If none of the parents have the primary introduction as their most
> =C2=A0=C2=A0 recent ancestor, nor do they have the same additional
>    introduction, then the merge commit cannot be authenticated.

> The idea is - the primary introduction is for the part of the tree
> under YOUR control. When you fork Guix and create your own branch,
> you use the initial commit on your branch as the primary channel
> introduction.  You add upstream Guix's primary channel introduction
> as an additional channel introduction. If you add anyone else's fork
> as a remote and pull one of their branches, you add their primary
> introduction as one of your additional introductions.
>=20
> Thus, any merge into one of YOUR branches (ie. any branch with the
> primary introduction as the most recent ancestor) only needs to be
> signed by a key that's authorized on that branch.
>=20
> But you can't merge into a branch from upstream Guix or someone
> else's authenticated fork (unless you're authorized to commit to
> those), because the first parent of the merge commit would not be a
> primary parent (see 2b) - it would be a commit on someone else's
> branch. And people not authorized by you can't merge into your branch
> either, because of 2a. And finally, you can't merge someone else's
> fork and upstream, or anything like that. The merge commit would not
> be authenticated in any of these cases.

> So What Do You Want From Me Anyway, 45mg?
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> I've tried to think of ways in which this modification to the
> behaviour of `guix git authenticate` could compromise security, but
> so far I haven't been able to think of any attacks it might enable.
>=20
> Of course, this only means that /I/ haven't been able to think of
> anything wrong. You, dear reader, have the advantage of a unique
> perspective and a fresh view on this idea. So, I'm hoping that you'll
> be able to sniff out any fundamental issues with the design here.
I think this might still hide a serious flaw.  With the way *upstream*
authentication works.  Let's flip the example in [6] around a little
bit and construct the following:

-A---B---C---D
  \       \
   \       \-E---F---=F0=9F=92=80
    \               /
     \----G--H--I*-/
 =20
Both A and I* are introductory commits on their various branches.  In
=F0=9F=92=80, any committer who has valid keys in both F and I* can merge a
branch with unsigned commits, effectively voiding the invariant of
BCEF, e.g. by undoing any changes that happened there.  Of course, they
can do so with signed commits as well, given that they have commit
access to the main repository, but the point still holds that they may
introduce unsigned commits to any fork where their key is valid in.

Cheers




Information forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 14 Jan 2025 04:22:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 13 23:22:33 2025
Received: from localhost ([127.0.0.1]:53555 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tXYRk-0000Tf-PY
	for submit <at> debbugs.gnu.org; Mon, 13 Jan 2025 23:22:33 -0500
Received: from lists.gnu.org ([2001:470:142::17]:33808)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <45mg.writes@HIDDEN>)
 id 1tXYRe-0000TN-VR
 for submit <at> debbugs.gnu.org; Mon, 13 Jan 2025 23:22:30 -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 <45mg.writes@HIDDEN>)
 id 1tXYRX-000888-92; Mon, 13 Jan 2025 23:22:19 -0500
Received: from mail-pl1-x643.google.com ([2607:f8b0:4864:20::643])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <45mg.writes@HIDDEN>)
 id 1tXYRT-0007KU-N7; Mon, 13 Jan 2025 23:22:19 -0500
Received: by mail-pl1-x643.google.com with SMTP id
 d9443c01a7336-21634338cfdso75423855ad.2; 
 Mon, 13 Jan 2025 20:22:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1736828529; x=1737433329; darn=gnu.org;
 h=mime-version:message-id:date:subject:cc:to:from:from:to:cc:subject
 :date:message-id:reply-to;
 bh=oi8h/rkVRT6VZd34fJqWXYv4kb818TCBqLtG0DaX+mc=;
 b=JaoLhNxnmSx70jbSXuYbBfMF54uAy1WODa46mFMhhzMbF1fRrxid4bWeUGbQH1FGUA
 ghQftn1I6VOxAkFiv3KJi6FIPTbpyl7Wl+KMPuJQXjObPppIB9Fo35FGsEZxRsjtlRzT
 7Gh5LVN228Lc2i6O3vseoTnZrr4oWdzsL6OgdV4Bgmd43qR4Id/utaPcsAb0JJAtoeU3
 66dOw6hjOob0ZTgc9M9Hz6gfrep3T6FjN9SELMmUk4qZpJKQt2NNhnIbkWDAeEYde0vW
 Govnhx/zR+MKurBgMLcrvePmpak3IqhY933guaS3yq2Vu4DDi0AQ3an7zzlMqnAra4RO
 /FKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1736828529; x=1737433329;
 h=mime-version:message-id:date:subject:cc:to:from:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=oi8h/rkVRT6VZd34fJqWXYv4kb818TCBqLtG0DaX+mc=;
 b=TVZJ3Ytsf8L/+OpULqwdqJnoSXc/G9DoB3Ivz9l2PFiYJkHHHaWITDlvGcJPsvBw7L
 wASUspgJRVPKR8w96dnqvskZayj3YmcOiNeeHdoXI4m1SAi+SorNceZeQesQXo6MbFra
 wxmw17xYEb/am3giPeBZ+CdaK5XjL3SvnBmRw6Ec6n7SPrTvg1oXGOmcHESNlp6g6f9p
 P0kgD4s6ni0RCVKS0UriK73RlQPFLkqao5lbjXxbzL7ZR/oBJhDM1UFWDG0wxmK1TfWk
 E1c5AG/eo6NjE2l7i48ts/4fFVeqMDxLcDu/xZSIEK2uDjpjvyriNwp1SY6g1paND3Ud
 EYKw==
X-Forwarded-Encrypted: i=1;
 AJvYcCUmKHHoA2bqxxJmfItA1lHsFJMWVXTC4i8jMFd7nUuobCVUQX9ONIDkfrIMHP4evrknq2AD6prjMU4E@HIDDEN,
 AJvYcCX7H40w3fmgJeonlRxrc4x2besT09hu+u4us5EbXYdrSq/xyHJY9gAf+a38lvEq0qVC4ggI11gim2Gj@HIDDEN
X-Gm-Message-State: AOJu0Ywm/rwRAAQqDkuV611vizFUyLLSWeYsawhq+YuXjAAUJd5MSQ2m
 SF5opWXQD8syasRyuiGMwZqwhYIpnvI/DYe6Pn3lJ4SCn8c62HAR9iLf5KUB
X-Gm-Gg: ASbGncv5Hv8p9gJhDJ64mcZvaa++bXEq/0JzOS5mp7yjp0DA1QDh4nYqEN9m/ZorBZ6
 mbRHNxPbOTBMdBkCCWCc1bOaKZ00IlRpkWaB1950HFnn1VrMhH8pK1e8ploByUbaBSF/Ip+IXwD
 TqacLry6WgoNMSBmccHXJENAvTevPhZSbZ1+OidJfHClAQKu1KLbKSGt+3boF00imIOGGO6SyVD
 Bo5889BfHOVECMe9lOm2BwL3QSidTx6Jy3RtpxIMIOxUU4qejanDbUHwg==
X-Google-Smtp-Source: AGHT+IEe8q8SEgNMv3wwMLLzzDfcmiNRM2kpm00f0D+xIcAma59G2/oSOk4Pt64lnYFCQkpZluAseA==
X-Received: by 2002:a05:6a21:1506:b0:1e1:9f77:da92 with SMTP id
 adf61e73a8af0-1e88d2eadb5mr33369918637.33.1736828528565; 
 Mon, 13 Jan 2025 20:22:08 -0800 (PST)
Received: from guix1 (utm3.nitt.edu. [14.139.162.2])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-a3196da0bf3sm7720136a12.42.2025.01.13.20.22.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 13 Jan 2025 20:22:08 -0800 (PST)
From: 45mg <45mg.writes@HIDDEN>
To: bug-guix@HIDDEN, 45mg <45mg.writes@HIDDEN>
Subject: Non-committers can't keep authenticated forks updated
Date: Tue, 14 Jan 2025 04:21:58 +0000
Message-ID: <878qrednyx.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=2607:f8b0:4864:20::643;
 envelope-from=45mg.writes@HIDDEN; helo=mail-pl1-x643.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
Cc: guix-devel@HIDDEN, Tomas Volf <~@wolfsden.cz>, help-guix@HIDDEN,
 Felix Lechner <felix.lechner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hi Guix,

First of all, please spare me a few paragraphs to explain why I'm CC'ing
guix-devel on this bug report (I promise it's a good reason this time!).

Introduction
============

As has been mentioned many, MANY times on these lists, patch review is
erratic in Guix, and patches can be neglected for months. This can be
frustrating when you /need/ those patches on your own system (esp. when
you're patching anything under guix/, and not just adding or updating
packages). To avoid this frustration, as suggested by Felix Lechner [1],
one can fork Guix, apply patches in a separate branch, and `guix pull`
from that branch. Given that even a moderately active contributor will
probably have multiple open patches at any point in time, this needs to
work as a long-term arrangement - which means the fork needs to be kept
updated with upstream Guix.

Next, authentication. I'm sure I don't need to justify the need to
authenticate the code that our systems run on, especially since this
project has done so for years now. Especially for those of us that host
our forks remotely and pull over a network, pulling with
`--disable-authentication` becomes a security risk.

Now, finally, I can state the problem at hand - Unless you are
authorized to make authenticated commits into upstream Guix, /you cannot
keep an authenticated fork updated/. (Explanation to follow.)

This is a serious problem for anyone who's looking to become more active
in Guix; they must either give up security to use a fork, or wait months
before being able to benefit from their own work.

Explanation
===========

To the best of my knowledge, this problem was first mentioned on
Help-Guix by Tomas Volf [2], who patched `guix git authenticate` to work
around it [3]. Here's (a touched-up version of) the explanation of this
issue found in that patch's description:

--8<---------------cut here---------------start------------->8---
When authenticating merge commits, intersection of authorized keys from
all parents is used. That is fine in Guix proper, since all involved
commits are under the control of the Guix committers, however it does
not work that well for authenticating merge commits in forks.

When Guix fork is created (starting from Guix-proper commit A), new
commit (authorizing the fork creator's signing key K) is created (I).
Later, when update from Guix proper (U) is merged, new merge commit is
created (M):

     M
    / \
   I   U
    \ /
     A

The M is signed with the K. However since the K is allowed by only one
parent (I), it will not be in the set of authorized keys (intersection
of keys from I and U). So, commit M cannot be authenticated.

Thus, an authenticated fork cannot be kept updated.
--8<---------------cut here---------------end--------------->8---

A Prospective Solution
======================

I discovered Tomas's patch [3] more than a year later. I initially
wanted to contribute it upstream to solve this issue, but I discovered
that it leaves room for a rather serious attack [4]. So I had to rule it
out.

After some brainstorming, I thought of a solution. I'm paraphrasing the
relevant part of the mail in which I articulated it [5] below (this mail
should be a reply to that one):

--8<---------------cut here---------------start------------->8---
I think I may have an idea myself; one that seems reasonably clean,
would fix our use-case of authenticating our own personal Guix forks,
and would even allow pulling branches from other people's forks and
authenticating those.

We could allow users to specify additional channel introductions. So,
there's always one primary introduction, but there can also be one or
more additional ones.

Commits with only one parent are authenticated normally.

For commits that have multiple parents - ie. merge commits - we weaken
the authorization invariant [6] as follows:

1. If all parents have the primary introduction as their most recent
   ancestor, then the invariant holds as usual.
   
2. If one or more parents has the primary introduction as its most
   recent ancestor (call these the 'primary parents'), and the rest have
   any of the additional introductions, then the merge commit is
   authenticated if and only if:
   a) it's signed by a key authorized in all of the primary parents, AND
   b) the /first parent/ [^] of the merge commit is a primary parent.
   
3. If all parents have the same additional introduction as their most
   recent ancestor, then the invariant holds as usual.

4. If none of the parents have the primary introduction as their most
   recent ancestor, nor do they have the same additional introduction,
   then the merge commit cannot be authenticated.

[^] Quoting from the Pro Git book [7]:
> ...the first parent of a merge commit is from the branch you were on
> when you merged (frequently master), while the second parent of a
> merge commit is from the branch that was merged...

The idea is - the primary introduction is for the part of the tree under
YOUR control. When you fork Guix and create your own branch, you use the
initial commit on your branch as the primary channel introduction. You
add upstream Guix's primary channel introduction as an additional
channel introduction. If you add anyone else's fork as a remote and pull
one of their branches, you add their primary introduction as one of your
additional introductions.

Thus, any merge into one of YOUR branches (ie. any branch with the
primary introduction as the most recent ancestor) only needs to be
signed by a key that's authorized on that branch.

But you can't merge into a branch from upstream Guix or someone else's
authenticated fork (unless you're authorized to commit to those),
because the first parent of the merge commit would not be a primary
parent (see 2b) - it would be a commit on someone else's branch. And
people not authorized by you can't merge into your branch either,
because of 2a. And finally, you can't merge someone else's fork and
upstream, or anything like that. The merge commit would not be
authenticated in any of these cases.
--8<---------------cut here---------------end--------------->8---


So What Do You Want From Me Anyway, 45mg?
========================================

I've tried to think of ways in which this modification to the behaviour
of `guix git authenticate` could compromise security, but so far I
haven't been able to think of any attacks it might enable.

Of course, this only means that /I/ haven't been able to think of
anything wrong. You, dear reader, have the advantage of a unique
perspective and a fresh view on this idea. So, I'm hoping that you'll
be able to sniff out any fundamental issues with the design here.

I've actually started work on a patch series to implement this, but it's
going to be pretty slow going - I've spent several hours on it so far,
and I'm maybe a fifth of the way done. (Obviously, I'm going to have to
pace myself more; so don't hold your breath.)

In the meantime, if there's a fundamental problem with the approach I've
described, I hope you will be able to find it sooner rather than later,
before I sink even more time and energy into this endeavor.

Thanks for reading this far, and here's hoping we can achieve a better
experience for budding contributors!

45mg

[1] https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00072.html
[2] https://lists.gnu.org/archive/html/help-guix/2023-09/msg00078.html
[3] https://git.wolfsden.cz/guix/tree/etc/0001-git-authenticate-Trust-all-keys-from-already-authent.patch
[4] https://lists.gnu.org/archive/html/help-guix/2025-01/msg00097.html
[5] https://lists.gnu.org/archive/html/help-guix/2025-01/msg00101.html
[6] From the 'Securing Updates' Guix blog post:
    > A commit is considered authentic if and only if it is signed by
    > one of the keys listed in the .guix-authorizations file of each of
    > its parents. This is the authorization invariant.
    https://guix.gnu.org/en/blog/2020/securing-updates/
[7] https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection





Acknowledgement sent to 45mg <45mg.writes@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-guix@HIDDEN. Full text available.
Report forwarded to bug-guix@HIDDEN:
bug#75552; Package guix. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 3 Feb 2025 16:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.