l...@gnu.org (Ludovic Courtès) writes:
> jerem...@pdp10.guru skribis:
>
>>> So if you like, please make that change. There is only one little
>>> thing: I have no (scripted) recipe to create mescc-tools-seed-XYZ. But
>>> wait: I have a great excuse for that...I was too lazy or too sloppy.
>>
>> I do, in mescc-tools-seed; the script bootstrap.sh when run with the
>> option "sin" will build the mescc-tools-seed binaries using mescc-tools.
>> The .M1 files are always generated by cc_x86.s using the C source files.
>
> I saw this script but it’s not entirely clear to me how to package the
> whole thing. We don’t have a “stage0” package for instance in Guix, do
> we?
>
>>> WDYT?
>> I think we will end up having several versions of mescc-tools-seed; as
>> each architecture guix supports will end up needing a variant if we plan
>> on keeping them small. (I also have no idea how to make a multi-arch fat
>> elf binary)
>
> For now let’s focus on x86_64/i686. :-)
>
> IMO we should change the seeds as rarely as possible because they are
> managed “out-of-band” and verifying them is difficult (you need to fetch
> the right Guix commit, run “guix build bootstrap-tarballs”, and compare
> the result—assuming this is all bit-reproducible.)
>
> The one we’re using today in Guix date back to 2013.
I think it's important that the new bootstrap-tarballs be
bit-reproducible, such that they can be independently verified by anyone
who wishes to do so.
In particular, *I* would like to independently verify them, on my own
laptops where I have avoided using binary substitutes for a long time,
and which I keep with me at all times.
My hope until now is that when we generated our existing bootstrap
binaries in 2013, Guix was too marginal a project to attract the
attention of hackers who might wish to compromise our bootstrap. In
2018, as Guix has become more popular, we might well be considered a
worthy target of such efforts.
Mark
