On 2016-12-01 10:25:58, Jonas Meurer wrote:
> Hi Security and LTS folks,
>
> Am 01.12.2016 um 15:54 schrieb Salvatore Bonaccorso:
>> On Wed, Nov 30, 2016 at 04:05:20PM -0500, Antoine Beaupré wrote:
>>> +nss (2:3.26.2-1+debu7u1) UNRELEASED; urgency=high
>>> +
>>> + * Non-maintainer upload by the LTS Security Team.
>>> + * New upstream release to fix CVE-2016-9074
>>
>> Depending on what is done this should be either 2:3.26.2-0+debu7u1 or
>> 2:3.26.2-1~debu7u1, but 2:3.26.2-1+debu7u1 is higher than 2:3.26.2-1.
>>
>> The former if you import new orig source on top of the previous
>> packaging to indicate the new import and have a version which is
>> before any possible such ones uploaded to unstable (which is even true
>> in this case because 2:3.26.2-1 is currently in unstable). The later
>> is often prefered if the package is mostly are build of :3.26.2-1 for
>> Wheezy. (The later proposed version works obviously as well in the
>> case of just a new upstream import, but Release team has often as well
>> done that distinction for the ~debXuY suffix).
>
> With this topic being discussed again and again recently, I suggest that
> we should agree on a defined standard regarding the versioning of new
> upstream releases uploaded to (old)?stable(-security)? and document it
> somewhere. What do you think?
It has been repeatedly discussed, indeed. I think Salvatore's
description is basically the ad-hoc standard. Maybe this should be
documented better in LTS/Development in the wiki? or devref?
> I don't have particular strong feelings on the exact versioning but I
> think that the following should be considered:
>
> *) New upstream releases in (old)?stable should use lover version
> numbers than their equivalent uploaded to unstable. This because
> packages uploaded to unstable are built using more recent versions
> of the build toolchain and libraries.
>
> *) The versioning should make it obvious whether the new release is
> based on a similar upload to unstable or whether it's packaged
> solely for (old)?stable.
>
> Consequently, the following (as already done for most uploads of new
> releases to (old)?stable) is my suggestion:
>
> *) Uploads of new upstream releases to (old)?stable that were packaged
> for unstable before should use the '~debXu1' suffix to the version
> number from unstable as they're basically backports of the package
> from unstable.
> *) Uploads of new upstream releases that were not packaged for unstable
> yet or will never be, should use the '1.2.3-0+debXu1' format (given
> that '1.2.3' is the upstream version.
The distinction is a little more subtle than this - 3.26.2 *was*
packaged for unstable - it's just that the package is built with the
debian/ (or debian.tar.gz, if you prefer) from oldstable, not from
unstable.
Upstream releases that were "not packaged for unstable *yet*" should
probably *never* be shipped in unstable. In the example of nss, it would
make no sense to package 3.26.x releases in oldstable unless they had
been running for a while... Therefore, I think we may want to target
"testing" there, to make it explicit that it's not just a package that
was just uploaded to unstable that can be shipped in oldstable...
In other words, the second paragraph above would read:
*) Uploads of new upstream releases that do not ship associated debian/
packaging from testing/unstable should use a lower version than
testing/unstable, for example `1.2.3-0+debXu1` given a `1.2.3-1`
version in unstable
> If we can agree on this, what would be the proper place to document it
> for the future? Ideally, this should be mandatory for any uploads of new
> upstream releases to the (old)?stable suites, be it to
> (old)?stable-security, to stable-proposed-updates or to stable-updates.
SPU/SU is the release team's jurisdiction, i am not sure i would want to
mess with those guys. ;)
As to where document this, it's always tricky. Our documentation is
unfortunately a bit spread out. I don't know about the secteam, but i
often refer to this:
https://wiki.debian.org/LTS/Development#Build_the_update
Uploads to stable are documented here:
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-stable
Security uploads are documented here:
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#bug-security-building
We should probably cross-reference all this stuff. Note that everyone
with collab-maint access can edit the developer's reference, and I
encourage people here to get familiar with that process...
> Anything I forgot to consider?
For me, the critical issue is not versionning - those mistakes are
pretty easy to catch and even in case of mistake, can be more or less
harmless. For example, in the case of nss 3.26.2-1+deb7u1, while it was
newer than the version in testing/unstable, 3.27.1 is coming down the
pipe there and it wouldn't stay newer for long. Those problems often
have a tendency of fixing themselves with time. ;)
The real issue is how we decide which packages follow upstream and which
we backport patches for. After working 3 hours on backporting a patch
for monit, I am again questionning the practice of backporting new
security patches to old software - I am not sure we are necessarily
doing great service to our users by keeping them in the artificial
feeling of security by doing those updates.
We should have clearer guidelines for this, and it's a hard call to
make. The rule of thumb for me is basically how long it would take me to
*actually* review the patch from upstream vs how long it would take me
to port the necessary patches back. In the case of Monit, i don't know
if the tradeoff was worth it.
For NSS, it would have been really hard to backport the keylength stuff,
and maybe it's worth it to package the new upstream releases. But I'm
not sure we can afford to review *all* those upstream releases like this
forever. I was surprised to see the newer NSS release in wheezy get in,
to be honest, considering how much work I put in the 2:3.14.5-1+deb7u6
release, and others did later...
A.
--
Worker bees can leave
Even drones can fly away
The queeen is their slave
- Fight Club
