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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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.
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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----- --=-=-=--
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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----- --=-=-=--
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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----- --=-=-=--
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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----- --=-=-=--
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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 --------------------
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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----- --=-=-=--
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.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
45mg <45mg.writes@HIDDEN>
:bug-guix@HIDDEN
.
Full text available.bug-guix@HIDDEN
:bug#75552
; Package guix
.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.