Hi Mark and everyone,
On 4/14/21 1:54 AM, Mark H Weaver wrote:
Recall that the grafting code performs a set of substitutions, replacing
store item names (i.e. file names in /gnu/store) with replacement store
items of the same length, with rules like:
"fx3979c88s9yxdbchyf36qryawgzpwb5-libx11-1.6.10" =>
"rwkqxykm91a75w9afhb41saj0dmf30hw-libx11-1.6.12".
The grafting code currently only checks the first 33 bytes, consisting
of the nix-base32 hash and the "-". It *assumes* that the remainder of
the associated store item name immediately follows, and blindly writes
the replacement string over whatever is there.
In this case, I suspect that within a *.zo file, a Guix store item name
was split into pieces, with the hash and "-" together in one piece but
split somewhere between the "-" and the last byte of the store item.
This results in corruption of the bytes following that piece.
I've recently observed the splitting of store item names in *.zo files
(see <https://bugs.gnu.org/47614>), but in that case the "-" was
separated from the hash, and as a result the reference was _invisible_
to the grafter.
Yes, I agree with this diagnosis.
It seems the discussion has become a bit fragmented, since Jack first
reported one set of symptoms in <https://issues.guix.gnu.org/47064> and
you then reported another in <https://issues.guix.gnu.org/47614> (with
much better forensics than I'd found on my own—thanks!).
Both issues should have been fixed (at least with respect to Racket) by
my patch in <https://issues.guix.gnu.org/47180>, which was applied on
Monday.
-Philip
