Patch names (security, fixes)

Gilles Espinasse 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
patch.

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'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.

Gilles



More information about the lfs-dev mailing list