guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Needed: tooling to detect references to buggy */stable packages (was: Re


From: Mark H Weaver
Subject: Needed: tooling to detect references to buggy */stable packages (was: Re: [PATCHES] ImageMagick security updates without grafting)
Date: Sun, 28 Mar 2021 18:33:09 -0400

Earlier, I wrote:
> One thing to be very careful about is to only use 'gtk-doc/stable',
> 'dblatex/stable', and 'imagemagick/stable' in native-inputs, and
> moreover to make sure that no references to these */stable packages
> remain in any package outputs.
>
> Of course, if any package retains references to its 'native-inputs',
> that's always a bug, but I wouldn't be surprised if such bugs exist in
> Guix.  Such bugs might be relatively harmless now (except when
> cross-compiling), but they could become a security bug if a package
> retains a reference to 'imagemagick/stable'.

It occurs to me that we will need some tooling to ensure that no
references to these buggy "*/stable" packages end up in package outputs
that users actually use.  Otherwise, it is likely that sooner or later,
a runtime reference to one of these buggy packages will sneak in to our
systems.

An initial idea is that these "*/stable" packages could have a package
property (perhaps named something like 'build-time-only') that indicates
that references to its outputs should not occur within the outputs of
any other package that does not have that same property.

We'd also need to somehow ensure that users don't install these
'build-time-only' packages directly, at least not without an additional
option (e.g. --force-unsafe-build-time-only) to override it.

Additionally, it might be good to issue warnings if 'build-time-only'
packages are not hidden, or if they are found within the 'inputs' or
'propagated-inputs' fields of any package that's not also
'build-time-only'.  Both of these last two checks have loopholes,
however, so they are not reliable indicators.

Thoughts?  Other proposals?

     Regards,
       Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]