From: Mark H Weaver <mhw@netris.org>
To: Maxime Devos <maximedevos@telenet.be>, guix-devel@gnu.org
Subject: Re: [PATCHES] ImageMagick security updates without grafting
Date: Sun, 28 Mar 2021 17:37:54 -0400 [thread overview]
Message-ID: <875z1bdkmq.fsf@netris.org> (raw)
In-Reply-To: <9fb6ac4f0893446e3619d62395e035a446a9606f.camel@telenet.be>
Maxime Devos <maximedevos@telenet.be> 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
guidelines.
> 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.
Regards,
Mark
next prev parent reply other threads:[~2021-03-28 21:39 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 [this message]
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
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=875z1bdkmq.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).