Hi Simon, Thanks for the thorough explanation. I think it would make sense to add such a mechanism to the cache service.
I've burned my allotted time for open source contributions for now, but I'm hoping I can take a stab at it after the summer. Or maybe next thursday in Guix@paris, if people are feeling like it we could hack that together :) A service would let one orchestrate that without too much pain. root has many more way to subdue the users anyway, there's no hurt in trusting root with authenticating the history. Cheers, Edouard. Simon Tournier <[email protected]> writes: > Hi, > > On Sat, 14 Jun 2025 at 11:23, Edouard Klein <[email protected]> wrote: > >> I think I'll maintain a systemwide cache as a workaround, but any >> guidance as to why guix home needs a full copy of the whole history of >> guix would help me understand how to get rid of that. > > If the user does not use “guix time-machine” and thus the Git history > isn’t used, then it’s possible to trim it. For example, > > git clone --depth 1 --mirror https://codeberg.org/guix/guix > then > git fetch --depth 1 > or > git fetch > # manually tweak .git/shallow > git gc --prune=all > > This way, the ~/.cache/guix/checkouts should be ~50MiB for the Guix > repository. > > However, this saves only space and do not allow authentication. > > For allowing authentication, one user (Alice) on the machine must pay > the price of a full clone – at least until the introduction commit. Then > Alice authenticates; say the path from introduction commit to commit A. > > Alice now can tweak .git/shallow and run ‘git gc --prune=all‘. The > Alice’s cache is reduced and only contains the last authenticated > commit, here named A. > > For this machine, instead of the introduction authentication commit – > usually 9edb3f66fd807b096b48283debdcddccfea34bad – the user of this > machine will use commit A as introduction authentication commit. > > Yes the assumption is that Bob must trust Alice; Alice might be root or > under the control of any trusted user on this machine, e.g., system > administrator. Well, A will act as the introduction commit for Bob. > > However, this trust is mitigated because the history of Guix is public, > therefore Bob is able to verify if A is really part of the Guix history. > Even, Bob should be able to verify the signature of this commit A. > > Using recent Git (2.49), Bob runs: > > git clone --depth 1 --revision=A https://codeberg.org/guix/guix > > This commit A is considered as the introduction authentication commit. > > guix git authenticate A FINGER-KEY-OF-A > > Then Bob runs: > > git fetch > guix git authenticate > # edit .git/shallow > git gc --prune=all > > This way the cache ~/.cache/checkouts is kept as small as possible. > However the Git history is not part of the cache so “guix time-machine” > needs to update the cache with the relevant TARGET commit: > > git fetch origin TARGET > > But TARGET will not be authenticated. I think we don’t care because it > would mean that both Codeberg has been tampered **and** the user > explicitly asks for a tampered TARGET commit. > > Well, I do not know if it’s possible to run all these dance with > guile-git (libgit2) but that’s another question. ;-) > > Somehow, I would go in this kind of direction: shallow. > > Cheers, > simon
