GNU bug report logs - #62051
Early detection of derivations with unreadable builder scripts

Previous Next

Package: guix;

Reported by: Christopher Baines <mail <at> cbaines.net>

Date: Wed, 8 Mar 2023 14:50:01 UTC

Severity: normal

To reply to this bug, email your comments to 62051 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#62051; Package guix. (Wed, 08 Mar 2023 14:50:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christopher Baines <mail <at> cbaines.net>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Wed, 08 Mar 2023 14:50:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: bug-guix <at> gnu.org
Subject: Early detection of derivations with unreadable builder scripts
Date: Wed, 08 Mar 2023 14:41:55 +0000
[Message part 1 (text/plain, inline)]
Currently it's quite easy to end up with packages that have builder
scripts that can't be read by Guile.

This is part of the following builder script:

  (cons "--enable-mpi-java" #<gexp  gnu/packages/mpi.scm:233:24 7f366e0cd930>)

from: /gnu/store/yngxnpcs4s6y8acxf4nwx5pcpj0j6q6i-java-openmpi-4.1.4-builder

And when attempting to build that derivation, you get the following
error.

  ice-9/read.scm:126:4: In procedure read-expr*:
  /gnu/store/yngxnpcs4s6y8acxf4nwx5pcpj0j6q6i-java-openmpi-4.1.4-builder:1:3820: Unknown # object: "#<"


It would be nice if Guix could detect this category of problems and
raise an error at the time the derivation is created, rather than the
error occuring only when you build the derivation.

This would be helpful particularly for the Guix Data Service since
currently it ends up storing these useless derivations, often many times
since the builder includes some often changing string (7f366e0cd930 in
the example above), so this is a common cause of spurious changes
between revisions (as often noted on qa.guix.gnu.org).
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#62051; Package guix. (Thu, 09 Mar 2023 20:52:01 GMT) Full text and rfc822 format available.

Message #8 received at 62051 <at> debbugs.gnu.org (full text, mbox):

From: Josselin Poiret <dev <at> jpoiret.xyz>
To: Christopher Baines <mail <at> cbaines.net>, 62051 <at> debbugs.gnu.org
Cc: Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#62051: Early detection of derivations with unreadable
 builder scripts
Date: Thu, 09 Mar 2023 21:51:51 +0100
[Message part 1 (text/plain, inline)]
Hi Chris,

Christopher Baines <mail <at> cbaines.net> writes:

> This is part of the following builder script:
>
>   (cons "--enable-mpi-java" #<gexp  gnu/packages/mpi.scm:233:24 7f366e0cd930>)
>
> from: /gnu/store/yngxnpcs4s6y8acxf4nwx5pcpj0j6q6i-java-openmpi-4.1.4-builder
>
> And when attempting to build that derivation, you get the following
> error.
>
>   ice-9/read.scm:126:4: In procedure read-expr*:
>   /gnu/store/yngxnpcs4s6y8acxf4nwx5pcpj0j6q6i-java-openmpi-4.1.4-builder:1:3820: Unknown # object: "#<"
>
>
> It would be nice if Guix could detect this category of problems and
> raise an error at the time the derivation is created, rather than the
> error occuring only when you build the derivation.
>
> This would be helpful particularly for the Guix Data Service since
> currently it ends up storing these useless derivations, often many times
> since the builder includes some often changing string (7f366e0cd930 in
> the example above), so this is a common cause of spurious changes
> between revisions (as often noted on qa.guix.gnu.org).

We could probably modify sexp->string, or the builder bind in
gexp->derivation so that the sexp is sanity-checked for non-printable
things (we could even work on a whitelist basis).  However, the
docstring of sexp->string talks about performance, and indeed "write" is
pure C code and very fast.  I'd be reluctant to introduce a performance
hit that would be too heavy here.

This particular example though was caused by non-gexp #:phase arguments,
so another option could be to sanity check sexps given to sexp->gexp,
but again, the docstring talks about performance, so I'm not sure what
we should do here.  In general, things written only with G-Exps should
work well, because you can't insert random stuff into them, but S-Exps
are more dangerous, hence why I think this option would be a better
middle ground.

Paging Ludo wrt. the performance cost of this (I can write a patch for
it adding a whitelist of what is allowed in a sexp->gexp sexp).

Best,
-- 
Josselin Poiret
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 1 year and 49 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.