"Tomas Volf" <~@wolfsden.cz> writes: > On 2023-11-02 15:25:33 +0000, Suhail wrote: >> [..] >> >> The hypothetical test derivation leaves the build artifact unchanged, >> but does communicate some "side" information. It's like a fixed-output >> derivation carrying some metadata (further elaboration below). > > I am not aware of any, but I wonder if there are test suites that actually > modify the built binary, for example by patching a bool flag `was_tested' to > #t. > Runtime behavior could then differ based on the flag. Do you have some ideas > how to detect/deal with this?
When you say "built binary" do you mean as an input to the "hypothetical test derivation", or the purported output of the test derivation which was supposed to be identical to the input but has been modified? If former, you'd need to ensure that the derivation has read-only access to the input (I believe/hope Guix already does this). If the latter, what's material is whether or not the original input can be recovered (with verification based on the comparison of some signature). To add more context, I am presently interested in situations where a "hypothetical test derivation" (say, A) passes its input (say, input_1 which was generated as the output of another derivation B) as part of its output (say, output_A), but adds additional metadata (say, metadata_A) in the process. I.e., let output_A = (input_1, metadata_A) I am also interested in being able to treat output_A as a substitute for input_1 given a function (say, f) which describes how to obtain input_1 from output_A and whose result matches the known signature of input_1. -- Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties.
