Closed Bug 685776 Opened 13 years ago Closed 13 years ago

Investigate moving Camino 2.0.x to NSS_3_12_11_RTM and NSPR_4_8_9_RTM

Categories

(Camino Graveyard :: General, defect)

1.9.0 Branch
x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: alqahira, Unassigned)

Details

Because we have our own client.mk on CAMINO_2_0_BRANCH and because on 1.9.0 NSS and NSPR are pulled directly from CVS by tag (said tag governed by client.mk), it's theoretically possible to upgrade CAMINO_2_0_BRANCH's NSS and NSPR to current tags, thereby bringing in all of the "recent" NSS fixes and certificate store changes.

If we could do this with minimal effort, it would be good for our users (and easier for release-wrangling for future 2.0.x releases).

1.9.0 is currently at NSPR_4_7_6_RTM and NSS_3_12_3_1_RTM
1.9.2 is currently at NSPR_4_8_7_RTM and NSS_3_12_9_RTM (with local changes for each)

https://wiki.mozilla.org/NSS:Tags and http://www.mozilla.org/projects/nspr/release-notes/ aren't terribly descriptive, although we do learn some feature changes that were included in NSS and the advancing requirements for newer NSPRs; the NSPR notes are rather deficient, missing notes for several versions, including the last few.

It's also unclear if these upgrades depend on any unrelated Gecko changes, or if any of the upgrades required changes to other files (one way to do so would be to track the upgrade bugs/changesets and look for changes to files outside nsprpub/ and security/nss, security/coreconf, and security/dbm.  In theory the revision history of nsprpub/config/prdepend.h and security/coreconf/coreconf.dep should give you those changesets, since those files should be touched to force NSPR and NSS rebuilds (though people sometimes forget).

There may also be packaging changes (bug 509558 springs to mind), both in Gecko packaging and Camino.

My guess is, from sitting down to think about this and writing everything out, it's probably a no-go (though we could handle a small number of changes), but if someone wants to pull 2_0 branch, change those tags in client.mk (http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_2_0_BRANCH&cvsroot=/cvsroot&mark=412-413#405), that would be a simple first step.  If things blow up badly, we know it's a no-go.

An alternative would be to track the certificate changes (*_WITH_CKBI_* or NSSCKBI_* tags), pull that (or stock 1.9.0 NSS, and then update the cert stuff to NSSCKBI_1_87_RTM) onto a branch, and use that branch tag in 2_0's client.mk.

Again, the idea here is to see if it's feasible to spend a tiny little bit of effort to make future 2.0.x releases less painful around NSS and more up-to-date for our users around NSS.

Or, we could hurry up and ship 2.1 before we have to do another 2.0.x release! ;-)
For the moment, I moved the NSS tag in CAMINO_2_0_BRANCH client.mk to CAMINO_2_0_9_RELEASE so that 

1) nightlies will at least pick up the blacklisting of recent certs, and 

2) said tag is present in client.mk by default, in case of a future release (to prevent another Camino 2.0.8rc4 situation).
Flags: camino2.0.10?
2.0.x is gone…
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: camino2.0.10? → camino2.0.10-
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.