Patch names (security, fixes)

Ken Moffat ken at linuxfromscratch.org
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 linuxfromscratch.org>:
> 
 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.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-dev mailing list