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

Previous Next

Package: guix;

Reported by: Mark H Weaver <mhw <at> netris.org>

Date: Sun, 14 Mar 2021 21:39:02 UTC

Severity: normal

Tags: security

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Mark H Weaver <mhw <at> netris.org>, Leo Famulari <leo <at> famulari.name>, Vivien Kraus <vivien <at> planete-kraus.eu>, 47144 <at> debbugs.gnu.org
Subject: bug#47144: [PATCH 3/3] gnu: patch: Graft to latest commit [security fixes].
Date: Sat, 01 Jun 2024 11:02:49 -0400
Hi Ludovic,

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

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>>  (define-public patch
>>    (package
>> +    (replacement patch/fixed)
>
> 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.

So e.g. someone using the Guix API referencing exactly to the 'patch'
package variable would get a secure version, but would otherwise need to
know to adjust their code to use 'patch/latest'.

Does that make sense?

-- 
Thanks,
Maxim




This bug report was last modified 333 days ago.

Previous Next


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