Patch names (security, fixes)

Ken Moffat ken at
Fri Oct 24 05:40:52 PDT 2008

On Fri, Oct 24, 2008 at 10:41:44AM +0200, Gilles Espinasse wrote:
> Selon Robert Connolly <robert at>:
 Actually, that was my contribution, so I'll answer ;-)
> ...
> > >
> > >  Personally, whenever I create a patch I find it hard to create an
> > > *appropriate* name.  Often, putting 'fix' in the name helps me
> > > understand what it is for without looking at the content.  I find it
> > > hard to see *why* restricting "fixes" to only those patches which have
> > > come from upstream is going to help anyone ?
> > >
> > >  The grammarian within me says that _fixes patches should always
> > > contain fixes for more than one issue. ;)
> > >
> > >  And then, if there are known vulnerabilities but no upstream patch,
> > > how are you going to name a patch ?  For a single vulnerability you
> > > could name it fubar-0.9-CVE_2008-9990-1.patch, but what if there are
> > > a *series* of CVE numbers for related issues which all need to be
> > > patched ?
> >
> A patch for a single subject is always prefered for review, particulary for
> subject identified as CVE. A single patch that fixe multiples CVE is not the
> common case. You may put all numbers (very rare when more than 3) like
> fubar-0.9-CVE_2008-9990_9991_9993-1.patch or put the other numbers in the header
> patch.

 I'm thinking more of BLFS than LFS itself here (we use the same
repo and have the same policy).  e.g. poppler-0.5.4.  Personally,
however we format the name (see below) I would find
poppler-0.5.4-CVE_2007_0104_3387_4352_5392_5393 unwieldy
(the -1), let alone adding 2008 1693 to that (the change for -2).
> I should say I didn't understand the logic between _ and - in
> fubar-0.9-CVE_2008-9990-1.patch.
> There is no need to alter CVE names and original form should be prefered.
> Sound logic for me if it would have been fubar-0.9_CVE-2008-9990.patch.
> As - is more often the separator for the version than _, I prefer _ to separate
> the version from the identifier of the patch.
> I know Debian has a different mind. I find debian policy that alter original
> package name very unconfortable and subject to error. As debian package has a
> different version string than the original sources, that's painfull to unpack
> and move inside untarred sources.
> When version separator is _, I should say I use - to separate patch subject from
> version. But no strong policy there, when a patch is borrowed to another
> repository (and that is the most common case to me), I prefer if possible when
> the patch name is not that different from the original name as google work
> better that way.
> I don't think -1 is needed for the first version, could be gentoo ebuild
> influence that add -r1,-r2 _after_ the first release.

 I agree that I don't enjoy debian's policy of renaming the original
tarballs, but it's their policy and it suits them.

 We also have a policy: '-' between the package and the patch name,
'_' within the patch name, and '-1.patch' for the first version.  I
remember uploading a patch with a name that didn't fit this policy
and getting an error message, I think from the periodic rendering of
the patches page (so, nobody using the web interface could see the
new patch).  I eventually realised my naming was the problem and
changed it, which fixed the problem.  Again, it's possible that my
example name didn't fit the policy.

das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-dev mailing list