Re: A real-life test of long-term reproducibility

[zimoun]

Hi Konrad,

On lun., 05 sept. 2022 at 09:49, Konrad Hinsen <konrad.hinsen@fastmail.net> 
wrote:
> Hi Ludo and Simon,
>
>> On Fri, 02 Sep 2022 at 15:17, Ludovic Courtès <ludo@gnu.org> wrote:
>>
>>> Here you would need ‘--allow-downgrades’.
>>
>> Maybe time-machine could advertise of this option?
>
> And explain what it's about. I don't consider myself an absolute
> beginner with Guix, but I don't understand what's going on here!

Well, it is documented. ;-) The entry of ’time-machine’ [1] is the
manual says:

        The general syntax is:

            guix time-machine options… -- command arg…

        where command and arg… are passed unmodified to the guix command
        of the specified revision. The options that define this revision
        are the same as for guix pull (see Invoking guix pull):

then the entry of ’guix pull’ [2] explains the option:

        --allow-downgrades

          Allow pulling older or unrelated revisions of channels than
          those currently in use.

          By default, guix pull protects against so-called “downgrade
          attacks” whereby the Git repository of a channel would be
          reset to an earlier or unrelated revision of itself,
          potentially leading you to install older, known-vulnerable
          versions of software packages.

Last, a blog post [3] provides some details.

I agree it could be improved.  Any suggestion? :-)


1: https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-time_002dmachine
2: https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-pull
3: https://guix.gnu.org/en/blog/2020/securing-updates/


> OK, now I do a well... but should users need to understand the
> developers' git workflow?

I agree.


> Ultimately, the issue here is that guix works on the implementation
> level of git commit references, whereas the development process uses an
> abstraction layer on top of it. Maybe "guix pull" and "guix
> time-machine" should acquire some built-in intelligence when given a tag
> instead of a hash? Issue a warning when an inappropriate tag is given,
> and suggest a correction?

Well, the tags are there and usable.  But, Guix relies on guile-git and
uses string->oid; which supporting hash-commit and not string-tag.
That’s a technical limitation which could be easily improved, I guess.

Even, we could imagine local Git-tags using “guix git tag” and reuse
them via the time-machine.  Some code are around for “guix git log” (see
branch wip-guix-log [4]).

(However, although convenient, Git-tag is extrinsic (mutable) and thus it
is not suitable for long-term, where intrinsic (immutable) seems
preferred.)

4: https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-guix-log


Cheers,
simon