Using the same nss upstream version in all suites?
Hi release team,
on the LTS list we discussed if it would be feasible to have the same
nspr/nss[1] upstream version in all suites (nameley testing, stable,
oldstable, oldoldstable). There are several reasons for this:
* Doing so would reduce the number of embedded code copies in
icedove/iceweasel/chromium/.... They currently become necessary at
one point once the version shipped in stable becomes too old.
* NSS receives frequent security updates that currently requires
backporting the patches to very different versions
* Backporting NSS patches becomes much harder over the years so
introducing a new version might become less risky than doing the
backport.
* NSS/NSPR have strict ABI policies[2] to not break backward
compatibility.
* Security bugs are often restricted on the mozilla bug tracker for
a long time so we know there _is_ a bug but might not know what it
is until the bug is publicaly accessible.
* We would have the same crypto policies for programs linked against
nss in all suites.
As a first step we discussed if it would be possible to introduce the
new nspr/nss versions via stable point releases. This would allow us to
ask for testing via the proposed-updates repo while still being able to
fix any regressions via a DSA. Backporting would become simpler since
the same backporting would happen for stable/oldstable and oldoldstable
and the diff to the new upstream version is minimal.
In order to improve confidence in nss upstream releases we enable the
test suite during the build and added some basic autopkg tests[3,4].
Would it be o.k. for the release team to handle new nss/nspr versions
via stable point releases?
Cheers,
-- Guido
[1] Mozillas Network Security Service libraries
[2] https://lists.debian.org/debian-lts/2015/11/msg00027.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806207
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806639
Reply to: