[Top][All Lists]

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

Re: [PATCHES] ImageMagick security updates without grafting

From: Mark H Weaver
Subject: Re: [PATCHES] ImageMagick security updates without grafting
Date: Sun, 28 Mar 2021 17:37:54 -0400

Maxime Devos <> writes:

> On Sat, 2021-03-27 at 20:01 -0400, Mark H Weaver wrote:
>> [...]
>> Maxime wrote:
>> > What does ‘guix refresh --list-dependent imagemagick@6.9.11-48’
>> > output now?
>> When I last checked, it reported on the order of 2400 dependent package
>> rebuilds.
> I should have written imagemagick@6.9.12-4 here.

On my Guix system, after applying my recent patch set, "guix refresh -l
imagemagick" (which refers to imagemagick@6.9.12-4) reports 603
dependent packages.

I see that, according to our guidelines, since this number is greater
than 300, it implies that updates to 'imagemagick' should not be done on
the 'master' branch.

On the other hand, for what it's worth, on my own GNOME system, the
number of rebuilds from my patch set was quite minimal, and *far* less
than the number of rebuilds than I usually need to do when updating my
system to the latest 'master' after just a few days.

I should say that I'm fully in support of having guidelines like this to
limit the number of rebuilds on 'master'.  It's especially important to
me since I never use substitutes, and build everything locally on my
(rather old) Thinkpad X200.

That said, _number_ of dependent packages is not a good measure of what
we should be trying to minimize.  I can build hundreds of 'python-*'
packages in the time it takes to build a single package like 'webkitgtk'
or 'icecat'.

A better measure might try to estimate the total amount of *build time*
suffered by _all_ Guix users, as a result of updating a given package.
That would depend on both (1) the estimated _time_ needed to build the
dependent packages, and (2) the estimated number of users of those
dependent packages, perhaps based on download statistics from our
substitute servers.

>> > If it there are many dependent packages, could some
>> > of them use imagemagick/stable, dblatex/stable or gtk-doc/stable
>> > as well?
>> Yes, that's exactly the purpose of this patch set.  Although at present,
>> the only user of 'imagemagick/stable' is 'dblatex/stable', and the only
>> user of 'dblatex/stable' is 'gtk-doc/stable'.
> You missed a few packages:
> in gnu/packages/mate.scm: search for "gtk-doc".
> Also, the (gnu packages imagemagick) import seems
> unused.

I did not attempt to comprehensively change all 'native-inputs'
references of 'gtk-doc' to 'gtk-doc/stable'.  I stopped when the number
of rebuilds on my own GNOME system became quite minimal.  That's why the
summary line of commit 9dea1618755891526f708aa335b4136c1302d16e ends
with the words "selected packages".

However, I see now that we should continue working on this, at least
until we can update 'imagemagick' on 'master' without violating our

> Looking at the package graph, many packages depend on imagemagick
> through python-sphinx, so it may be worthwile to define a
> python-sphinx/stable and use it instead of python-sphinx in the
> native-inputs.
> I suggest
>  guix graph --type=reverse-package imagemagick@6.9.12-4 | dot -Tpdf > a.pdf
> to find out if there are more uses for imagemagick/stable.

That's a good idea.  Would you like to work on it?

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'.

On my own system and user profile, which includes GNOME, I'm glad to
report that I have *no* references to 'imagemagick' at all, not even to
its newest release, and that's my strong preference.


reply via email to

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