Re: Using the same nss upstream version in all suites?
On Thu, Dec 31, 2015 at 01:13:19PM +0100, Guido Günther wrote:
> 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?
Now that squeeze moves out of support would it be o.k. to update nss via
p-u for stable and oldstable?
Cheers,
-- Guido
Reply to: