unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Maxime Devos <maximedevos@telenet.be>, guix-devel@gnu.org
Subject: Re: Needed: tooling to detect references to buggy */stable packages (was: Re: [PATCHES] ImageMagick security updates without grafting)
Date: Sun, 04 Apr 2021 16:14:25 -0400	[thread overview]
Message-ID: <87zgyd7qo3.fsf@netris.org> (raw)
In-Reply-To: <6d8fdc44cf956c4ac450c9d2713e9be4cfce5757.camel@telenet.be>

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

> On Sun, 2021-03-28 at 18:33 -0400, Mark H Weaver wrote:
>> 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 just occurred to me: could we automatically add all native-inputs
> to #:disallowed-references when cross-compiling?  This shouldn't break
> any packages, except possibly when cross-compiling.
>
> Or stronger, add all native-inputs to #:disallowed-references (unless
> they are also in inputs or propagated-inputs), even when compiling
> natively?

Yes, I think this is a good idea and worth considering.  However, we'd
need to consider the case where the same package is in both 'inputs' and
'native-inputs'.  When cross-compiling, it's no problem, because the
same package in those two fields will lead to distinct output paths,
since they are compiled for different systems.  However, when compiling
natively, the outputs of packages occurring in both 'inputs' and
'native-inputs' should *not* be implicitly included in
#:disallowed-references.

> Problems include:
> * I guess a world rebuild, as the derivations would be different.

Indeed!

> * In some places we have the following pattern:
>
>     (native-inputs
>      `(("autoconf" ,autoconf)
>        ("automake" ,automake)
>        ("pkg-config" ,pkg-config)
>        ,@(if (%current-target-system)
>              `(("guile" ,guile-3.0))   ;for 'guild compile' and 'guile-3.0.pc'
>              '())))
>     (inputs
>      `(("guile" ,guile-3.0)
>        ("lzlib" ,lzlib)))
>     (synopsis "Guile bindings to lzlib")
>
>   The (if (%current-target-system) ...) would need to be made unconditional.

I don't understand this.  Why would it need to be made unconditional?

> * I guess an option to disable this behaviour might be useful.
>
>> 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.
>
> Would this be (a) something enforced by the build process (using
> #:disallowed-references or #:allowed-references), or (b) a linter?

I would prefer option (a) above.
  
>> 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.
>
> What about a developer running "guix environment eom"?  IIUC, this would
> make the developer vulnerable (at least, once I've gotten around replacing
> the 'gtk-doc' input with 'gtk-doc/stable'), so it might make sense to
> replace /stable -> unstable packages here.
>
> However, now the developer ends up with a different set of packages than
> wil be seen in the build environment ...

That's an excellent point, for which I don't have any good answer.
I'm open to suggestions.

> Is this something you will be writing "guix lint" checkers (or other
> checkers) for yourself?

At the present time, I'm more inclined to add machinery to automatically
add _implicit_ #:disallowed-references, to enforce this checking at
package build time.  This would require rebuilding everything that
depends on a '*/stable' package, which means that this kind of tooling
could not be applied directly to 'master', but would need to go through
'staging'.

What do you think?

    Thanks,
      Mark


  reply	other threads:[~2021-04-04 20:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-27 13:09 [PATCHES] ImageMagick security updates without grafting Mark H Weaver
2021-03-27 14:36 ` Maxime Devos
2021-03-28  0:01   ` Mark H Weaver
2021-03-28  9:59     ` Maxime Devos
2021-03-28 21:37       ` Mark H Weaver
2021-03-28 22:05         ` Maxime Devos
2021-03-29 21:28           ` Mark H Weaver
2021-03-30 22:23             ` Mark H Weaver
2021-03-28 22:33         ` Needed: tooling to detect references to buggy */stable packages (was: Re: [PATCHES] ImageMagick security updates without grafting) Mark H Weaver
2021-03-29  6:54           ` Maxime Devos
2021-04-04 20:14             ` Mark H Weaver [this message]
2021-04-05  9:53               ` Maxime Devos
2021-03-29 12:43           ` Ricardo Wurmus
2021-03-30 10:39           ` Needed: tooling to detect references to buggy */stable packages Ludovic Courtès
2021-04-04 19:54             ` Mark H Weaver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zgyd7qo3.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guix-devel@gnu.org \
    --cc=maximedevos@telenet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).