Hi,
>> Today, Guix isn’t 100% bit-to-bit reproducible, to my knowledge. That’s
>> another topic, IMHO. :-)
>
> Is there any explanation or documentation on what the limits are?
For example, SBCL [1], Emacs [2] or Julia [3] aren’t reproducible.
Most of the source of undeterministic builds is now tackled but 100% of
Guix packages are not reproducible. And to my knowledge, we poorly
monitor the bit-to-bit reproducibility of the artifacts. Many tools are
already there but, to my knowledge, there is no notification if or when
a package isn’t bit-to-bit reproducible. And I’ve lost the track of the
dashboard we had. )-:
Moreover, please consider the “warning” from the manual [4]:
‘--save-provenance’
[...]
This option is not enabled by default because, like timestamps,
provenance information contributes nothing to the build process.
In other words, there is an infinity of channel URLs and commit IDs
that can lead to the same pack. Recording such “silent” metadata
in the output thus potentially breaks the source-to-binary bitwise
reproducibility property.
> I'm not familiar with such a comparison, but I think both kind of
> comparisons may be necessary. Simply comparing manifest.scm's assume
> that containers were not prepared maliciously, which I'm not sure we can
> assume.
Do you mean include a manifest.scm file inside the Docker image that
isn’t the compromised manifest.scm file used for generating such image?
Somehow, from my understanding, knowing the checksum of the Docker image
only allows me to detect if the image would be compromised by the
download process. However, it tell me nothing about what is inside.
And I must trust the Guix project, but without any mean for challenging
it and for checking the Guix project isn’t itself compromised.
IMHO, instead of a checksum, the Guix project should publish the
channels.scm and manifests.scm files, and also the complete command-line
for generating the Docker image.
Well, from my point of view, the checksum is useless because if I want
to verify the Docker image isn’t compromised, then I would first
download the image and the channels.scm and manifest.scm files, then I
would inspect these two files before locally rebuilding the image myself
using these two files and last challenge the two checksum of the
published image and the locally rebuilt image.
Or maybe instead of downloading the channels.scm and manifest.scm files,
I would extract them from the downloaded image, then I would inspect
them. Then I would locally rebuild the image using these two extracted
files and last challenge the checksum of the downloaded image against
the new one.
For this two scenarii, what I would inspect are the two files
channels.scm and manifest.scm; assuming my local Guix isn’t
compromised. ;-)
>From my point of view, the trust is about my ability to challenge by
locally redoing myself if I want to. Similarly as the principle of
substitutes, kind of. :-)
Bah maybe I’m missing something. In all cases, my comment is very minor
in all the big picture of publishing Docker images.
Cheers,
simon
1: https://issues.guix.gnu.org/44112
2: https://issues.guix.gnu.org/35085
3: https://issues.guix.gnu.org/47354
4: https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-pack
