> 1. Prepare a 2:3.14.5-1 Debian package for Wheezy.
> 2. Test this package on Wheezy.
> 3. Propose this package to Debian's NSS maintainer and security team.
> 4. Upload this package to the feature-torbrowser-17.0.11esr suite in
> our APT repository.
> 5. Test this package in the context of Tails 0.21.
> 6. Document how to enable this additional APT suite in Tails, and
> how to upgrade the binary packages built from the NSS source.
>
> I can do #1, #3 and #4.
I can do #2, #5 and #6 :) depending on the deadline though.
>> By the way, it seems that we are currently running an outdated vulnerable
>> libnss version anyway, because it is installed from backports and not
>> updated there. Version 3.14.4 also fixed a security issue [2], and
>> backports has an unpatched [3] version 3.14.3.
>
> Right. feature/ff24 (pending for review) installs 2:3.15.3-1~bpo60+1,
> so Tails 0.22 should be fine.
>
> So, alternatively we could just speed up the 0.22 release, skip the
> RC, get it out at the time we had planned for the RC, and put
> a point-release out a week later for the next ESR24 update. I'm not
> sure how crazy this would be. I can surely make this decision with my
> RM hat on, but I'd like to hear what others think first.
Another possibility would be to do the usual RC, and advertise it as a
better workaround for people concerned about the libnss issue. The ISO
will be the same, it's just the way we advertise it that changes. No?
