Usually we have that NSS update as part of a staging/staging-next cycle to reduce the amounts of rebuilds on master. Given the severity of some of the issues and it being a dependency of Firefox it might be fine to just land this on master as is. If someone disagrees we can also do it the "normal" way.

I'll spent the afternoon on the backports of this. As of a few days we are only support 20.03 and master IIRC so I'll skip 19.09 but it would probably not be that hard (famous last words).

I expect tomorrow around noon we can start a new staging-next cycle so this can be included then.

I'm not that familiar with the whole staging/staging-next workflow. Is there anything I need to do once the new cycle has been started?

I pushed the nss bump to staging now. This still does not prevent us from skipping the wait in case the staging-next cycle gets stuck on some hard-to-solve problem. (I pushed with non-SRI hash, although that change perhaps wasn't really required.) Actually, this time I see no "critical" security problems, so it seems to be less important than usual :-)

Uh, I forgot to mention it here... and forgot this PR for a while: most of the commits don't need any large rebuild and they can go directly to master. I pushed those now (better late than later).

I see these commit hashes are linked from 20.03 already, so we merge this PR as-is into current staging-next?

I don't know why @edolstra merged the backport, before this was merged. Since the commits are already referenced on release-20.03, this should probably merged as is.

I think it's good that 20.03 merge to wasn't delayed this long, but we could have merged this whole PR to staging long ago – at the first moment I only took what was necessary (nss).

So I'll just close this then, right?

Won't firefox on master fail because nss is still on staging-next?

firefox would fail, but I didn't push that. I tested running all those I pushed.