unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
* Non-committers can't keep authenticated forks updated
@ 2025-01-14  4:21 45mg
  2025-01-15  9:41 ` bug#75552: " Liliana Marie Prikler
  0 siblings, 1 reply; 5+ messages in thread
From: 45mg @ 2025-01-14  4:21 UTC (permalink / raw)
  To: bug-guix, 45mg; +Cc: Felix Lechner, Tomas Volf, help-guix, guix-devel

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



^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#75552: Non-committers can't keep authenticated forks updated
  2025-01-14  4:21 Non-committers can't keep authenticated forks updated 45mg
@ 2025-01-15  9:41 ` Liliana Marie Prikler
       [not found]   ` <87h660xeld.fsf@gmail.com>
  0 siblings, 1 reply; 5+ messages in thread
From: Liliana Marie Prikler @ 2025-01-15  9:41 UTC (permalink / raw)
  To: 45mg.writes, 75552; +Cc: guix-devel, Tomas Volf, help-guix, Felix Lechner

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.
> 
> 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---
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.

> […]
> 
> 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.
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.
   
> 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.

> 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.

> 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 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---💀
    \               /
     \----G--H--I*-/
  
Both A and I* are introductory commits on their various branches.  In
💀, 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




^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#75552: Non-committers can't keep authenticated forks updated
       [not found]         ` <c3b1445d236ed95f768c218503089926788256a4.camel@gmail.com>
@ 2025-01-16 13:22           ` 45mg
  2025-01-16 14:39           ` Tomas Volf
  1 sibling, 0 replies; 5+ messages in thread
From: 45mg @ 2025-01-16 13:22 UTC (permalink / raw)
  To: Liliana Marie Prikler, Tomas Volf
  Cc: guix-devel, 75552, 45mg, help-guix, Felix Lechner

Liliana Marie Prikler <liliana.prikler@gmail.com> 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.  #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.
> 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.  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=tags#L30




^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#75552: Non-committers can't keep authenticated forks updated
       [not found]         ` <c3b1445d236ed95f768c218503089926788256a4.camel@gmail.com>
  2025-01-16 13:22           ` 45mg
@ 2025-01-16 14:39           ` Tomas Volf
  1 sibling, 0 replies; 5+ messages in thread
From: Tomas Volf @ 2025-01-16 14:39 UTC (permalink / raw)
  To: Liliana Marie Prikler; +Cc: guix-devel, 75552, 45mg, help-guix, Felix Lechner

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> [..]
>
>> 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.
> 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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#75552: Non-committers can't keep authenticated forks updated
       [not found]           ` <87cygmmzuh.fsf@gmail.com>
@ 2025-01-16 21:13             ` Saturanya Rahjane de Lasca via Bug reports for GNU Guix
  0 siblings, 0 replies; 5+ messages in thread
From: Saturanya Rahjane de Lasca via Bug reports for GNU Guix @ 2025-01-16 21:13 UTC (permalink / raw)
  To: 45mg, 75552; +Cc: guix-devel, Tomas Volf, help-guix, Felix Lechner

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 – and even then there's
ways around it, as discussed.  

> > > 
> 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 – 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.
> > 
> > […]
> > 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.
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 – and yes, we are – but that doesn't change
the fact that weakening security weakens security.  

> > > 
> > > 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 – 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.
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.

> > > > 
> > > […]
> > > 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.
> > Care to state how designating one introduction as "primary" adds to
> > security here?  
> 
> 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.
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.

> > 
> > > 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.)
> > 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].)

So merge commits for upstream will look like 

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

whereas merge commits for your fork will look like 

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

Uhm… how does `guix git authenticate' differentiate between the two?
🤔️

> 
> > 
> > > 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.)
When those branches tail different upstreams, they won't necessarily
have the same primary introduction – at least as you intended it.

> > > 
> > > 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.
As far as you can tell.  I think the scheme would be gnarly enough to
implement that an exploit à 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 – not necessarily the same time – 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.)

> > 
> 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.

> 
Cheers




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2025-01-19  1:47 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-14  4:21 Non-committers can't keep authenticated forks updated 45mg
2025-01-15  9:41 ` bug#75552: " Liliana Marie Prikler
     [not found]   ` <87h660xeld.fsf@gmail.com>
     [not found]     ` <cdc27d94591d7865b034b5057ce7ad25b930921c.camel@gmail.com>
     [not found]       ` <87a5brsmve.fsf@wolfsden.cz>
     [not found]         ` <c3b1445d236ed95f768c218503089926788256a4.camel@gmail.com>
2025-01-16 13:22           ` 45mg
2025-01-16 14:39           ` Tomas Volf
     [not found]       ` <87v7uerjk9.fsf@gmail.com>
     [not found]         ` <ef18ee3dc4813b20fe40c21ec0f03e856acdb9a0.camel@gmail.com>
     [not found]           ` <87cygmmzuh.fsf@gmail.com>
2025-01-16 21:13             ` Saturanya Rahjane de Lasca via Bug reports for GNU Guix

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).