Patch names (security, fixes)
g.esp at free.fr
Fri Oct 24 01:41:44 PDT 2008
Selon Robert Connolly <robert at linuxfromscratch.org>:
> > 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
I should say I didn't understand the logic between _ and - in
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'd just like something that we can all agree on, and use.
> How about "upstream_fixes" for bug patch(es) which are in upstream,
> and "community_fixes" for other bug patch(es) which are not in upstream? and
> stop using "security" in patch names, because bugs are bugs.
> For our purpose, we can use a plural "fixes" even if the patch only fixes one
> issue, because it may be added on to later. Just to keep the naming coherent.
-p<x> notation could be used when packages like bash add patches referenced by
the <x> number that would represent a patch level after the stable release.
More information about the lfs-dev