GNU bug report logs - #47144
security patching of 'patch' package

Previous Next

Full log

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Mark H Weaver <mhw <at> netris.org>, 47144 <at> debbugs.gnu.org,
 Vivien Kraus <vivien <at> planete-kraus.eu>, Leo Famulari <leo <at> famulari.name>
Subject: Re: bug#47144: security patching of 'patch' package
Date: Wed, 05 Jun 2024 18:04:39 +0200

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:

[...]

>> Unless I’m mistaken, this will have practically no effect because Patch
>> is a build-time-only dependency.
>>
>> My recommendation would be to not add a ‘replacement’ field at all.
>> Instead, you could add a new ‘patch/latest’ public variable pointing to
>> that commit that you picked.  That way, users running ‘guix install
>> patch’ or similar will get the latest version of Patch.
>
> I see what you mean, but for all practical purposes, using a graft seems
> a more thorough (because it affects the original 'patch' *variable* as
> well) means that have the same effect for users, so I'd seems like a
> slightly better option to me.

Strictly speaking, yes, but in practice the benefit are largely
theoretical IMO, and the cost of having a graft this deep in the
dependency graph.

What about renaming ‘patch’ to ‘patch/pinned’ and having ‘patch’ point
to the new version?

Internally, we’d refer to ‘patch/pinned’ in (guix packages), but user
code etc. would refer to ‘patch’ and thus get the latest version.

Ludo’.

Previous Next

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