+++ This bug was initially created as a clone of Bug #816392 +++ We also need to backport the fixes for bug 683266, bug 808218, and bug 812802 to mozilla-beta for B2G. It was agreed to do the same for mozilla-aurora. See 816392 for more discussion.

https://hg.mozilla.org/releases/mozilla-aurora/rev/5684fa8e1b2d https://hg.mozilla.org/releases/mozilla-beta/rev/95887b927683

bsmith and I discussed this prior to landing - approval should probably be a=akeybl for these patches as they do have non-zero risk to desktop, but it's no big deal. For posterity's sake, here was Brian's risk evaluation for https://hg.mozilla.org/releases/mozilla-beta/rev/95887b927683 (which looks deceptively large): "1. There is a source code file, certdata.c that is generated from a text file certdata.txt. This file is huge. Previously, we generate certdata.c from certdata.txt and then check in the modified certdata.c to version control. After the patch, we generate certdata.c from certdata.txt as part of the build. This is why there is a "giant" change in the patch, which removes certdata.c from version control. But, the actual change to the build logic is ~10 lines. 2. One of the patches is literally just adding "const" to some declarations of some NSS functions to avoid needing const_casts in the PSM code. This has no effect at runtime. 3. One of the patches is a modification to the NSS addbuiltin tool to stop it from adding carriage returns on its output on Windows. This tool isn't run at runtime OR build time. It is only run pre-build and the output of it is checked in."

What happened to the policy of releasing FF with releases of NSPR/NSS? (what landed on aurora and beta is *not* 3.14.1, it lacks the various version bumps)

I was about to suggest releasing a 3.14.0.1 with the minimal changes, but a version like 3.14.0.1 wouldn't be handled by the configure script. How about releasing that as 3.14.1, and bump what currently is 3.14.1 as 3.14.2? It's kind of awful, but it's still better than the situation this is putting linux distros in. That is, being forced to use nss 3.14.1 while what FF really uses is something between 3.14 and 3.14.1 that is neither.

Mike, I agree with you in general. I would very much like to see that we *strictly* enforce the policy that you have cited. But the reality is that the NSPR/NSS team occassionaly gets approached to find compromises. In this particular case, Brian Smith suggested that the backported fixes don't change the ABI, and Firefox would still build fine with keeping the base NSPR/NSS without those fixes. I fully agree this is a hassle, and at least causes confusion, because people might be uncertain whether they need a newer NSS or not. Hopefully in this case Brian was right, and it's fine. Nevertheless, I would very much like to see us enforce a very strict policy, and require Mozilla to either take a new release (with all the consequences that involve that) or accept that Mozilla must do without fixes. I would appreciate an initiative that asks Mozilla drivers to be fully aware of this rule and a commitment to enforce it.

(In reply to Kai Engert (:kaie) from comment #5) > Mike, I agree with you in general. > > I would very much like to see that we *strictly* enforce the policy that you > have cited. > > But the reality is that the NSPR/NSS team occassionaly gets approached to > find compromises. > > In this particular case, Brian Smith suggested that the backported fixes > don't change the ABI, and Firefox would still build fine with keeping the > base NSPR/NSS without those fixes. Note that in this case, aurora (and probably beta) needs 3.14.1 to build when using a system nss. > I fully agree this is a hassle, and at least causes confusion, because > people might be uncertain whether they need a newer NSS or not. Hopefully in > this case Brian was right, and it's fine. > > Nevertheless, I would very much like to see us enforce a very strict policy, > and require Mozilla to either take a new release (with all the consequences > that involve that) or accept that Mozilla must do without fixes. > > I would appreciate an initiative that asks Mozilla drivers to be fully aware > of this rule and a commitment to enforce it. How about adjusting NSS release management so that we can have intermediate releases like I'm suggesting in comment 4 (but not in that ugly replace-the-version-number way)

(In reply to Mike Hommey [:glandium] from comment #6) > > Note that in this case, aurora (and probably beta) needs 3.14.1 to build > when using a system nss. Why?

(In reply to Kai Engert (:kaie) from comment #7) > (In reply to Mike Hommey [:glandium] from comment #6) > > > > Note that in this case, aurora (and probably beta) needs 3.14.1 to build > > when using a system nss. > > Why? bug 808218

(In reply to Mike Hommey [:glandium] from comment #4) > I was about to suggest releasing a 3.14.0.1 with the minimal changes, but a > version like 3.14.0.1 wouldn't be handled by the configure script. How about > releasing that as 3.14.1, and bump what currently is 3.14.1 as 3.14.2? It's > kind of awful, but it's still better than the situation this is putting > linux distros in. That is, being forced to use nss 3.14.1 while what FF > really uses is something between 3.14 and 3.14.1 that is neither. Linux distros that use system NSS should build with 3.14.1, or with 3.14 + the patches in security/patches/. They can make their binary Firefox packages require 3.14. We will be finalizing that release of 3.14.1 very soon. I agree that this situation is sub-optimal but it is hardly the most serious problem caused by crash-landing everything B2G on mozilla-beta. Note that in my checkin, I updated configure.in to say that we require 3.14.1. It is OK that some of the version strings still say "3.14" in mozilla-aurora and mozilla-beta is OK, because we do not use those version strings for anything critical for MOZ_NATIVE_NSS builds.

(In reply to Brian Smith (:bsmith) from comment #9) > > Linux distros that use system NSS should build with 3.14.1, there is no 3.14.1 yet > or with 3.14 + the patches in security/patches/ We must avoid that. That's exactly the reason why we had the rule "only released versions" in the first place, exactly in order to avoid that. I'm biting myself for punishment, for the fact that I didn't realize this consequence, when you had asked for the const-API change. We must stop allowing Mozilla to cherry pick patches, once and forever. I've made a proposal to the NSS team to doing releases more frequently, giving Mozilla the opportuniy of being able to pick up new fixes more frequently, and allowing us to establish a rule of "zero cherry picking of patches, no exceptions whatsoever".

If somebody writes a patch to add the const_casts to Gecko so that patch isn't necessary, I will review it and check it in. But, I'm not going to write the patch.