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

Previous Next

Package: guix;

Reported by: 45mg <45mg.writes <at> gmail.com>

Date: Tue, 14 Jan 2025 04:23:02 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Nicolas Graves <ngraves <at> ngraves.fr>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>, 45mg <45mg.writes <at> gmail.com>, 75552 <at> debbugs.gnu.org
Cc: guix-devel <at> gnu.org, Tomas Volf <~@wolfsden.cz>, help-guix <at> gnu.org, Felix Lechner <felix.lechner <at> lease-up.com>
Subject: bug#75552: Non-committers can't keep authenticated forks updated
Date: Fri, 17 Jan 2025 22:44:42 +0100
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 – 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… 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.
>

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

-- 
Best regards,
Nicolas Graves




This bug report was last modified 174 days ago.

Previous Next


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