488241 - Fix cert7/cert8.db issues with large issuer names in NSS_3_11_BRANCH as well

Status: RESOLVED FIXED

(NSS :: Libraries, defect)

Description

[Kaspar]

Attachment: Combined patch (see description in comment 0)

As suggested in bug 487381 comment 30, I'm filing a separate bug for backporting the fixes originally written for bug 486304 and bug 487381 to NSS_3_11_BRANCH. Specifically, the attached diff combines the following 4 patches (which have been committed to trunk already):

attachment 370548 [details] [diff] [review]
attachment 371634 [details] [diff] [review]
attachment 372188 [details] [diff] [review]
attachment 372351 [details] [diff] [review]

Comment 1

[Robert Relyea]

Comment on attachment 372547 [details] [diff] [review]
Combined patch (see description in comment 0)

lowcert.c and pcertdb.c are virtually unchanged between NSS 3.11 and 3.12 (just a directory move).

so it's not surprising the patch moved applied cleanly.

bob

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

(I'm going to post this comment to one or more mailing lists, also.
Please reply to it in one of those.)

This bug raises interesting policy and/or procedural questions.  

Because of NSS's strong backwards binary compatibility policy, it is possible
to use newer "minor" releases as patch fixes for older minor releases in the 
same major release group.  For example, it is possible to use NSS 3.12.3 as 
a bug-fix drop-in replacement (a "patch release") for NSS 3.11.x, without rebuilding or altering the NSS apps that used NSS 3.11.x in any way.  
We have used NSS 3.11.x as a bug-fix replacement for NSS 3.10.x, NSS 3.9.x, 
and even NSS 3.3.x, and we plan to do exactly that again, using NSS 3.12.3 
as a drop-in replacement for NSS 3.11.x.  

Because of that strong backwards binary compatibility, we do not typically
keep old "minor" releases of NSS alive after making a newer minor release.
After releasing NSS 3.11, we stopped making any further releases in the 
3.10.x series, for example.  Likewise, when we released 3.10, we immediately
stopped making any further 3.9.x releases.  And now that we have released 
NSS 3.12.3, we have no further plans for any future 3.11.x releases ... 
which brings us to this bug.

In effect, this bug asks for a fix from the trunk (3.12.3) to be committed 
to the 3.11 branch in anticipation of a future NSS 3.11.11 release.  But 
there is no 3.11.11 release planned or anticipated.  

So, what shall we do?  Among our potentially many options are:
- resolve this bug WONTFIX
- commit the patch to the branch, knowing that it probably won't go anywhere
- turn control of the branch over to some group of people who are willing to work to try to keep it alive by back porting more fixes.  

I am told that there are various Linux and/or Unix distros that plan to keep
FF2 alive for some time to come, even though Mozilla has stopped maintaining
it.  I suspect that the people committed to keeping FF2 alive might also be interested in trying to keep NSS 3.11.x alive.  I would prefer that they not
do that, but instead use NSS 3.12.x as a replacement for 3.11.x.  I believe
the entire NSS team would prefer that (but I might be mistaken about that.)

So, the immediate question for this bug is: 
What shall we do here?  Commit this patch to the branch?  or not?

And if we do commit it, many more questions follow.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Kaspar, do you have a specific consumer of this patch in mind?
Is there a particular Linux distro, or other distributor of FF2, or 
other software group that you believe might make an NSS 3.11.11 release 
even if Mozilla's NSS team does not?

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 372547 [details] [diff] [review]
Combined patch (see description in comment 0)

Checking in lowcert.c; new revision: 1.20.2.2;  previous revision: 1.20.2.1
Checking in pcertdb.c; new revision: 1.53.2.12; previous revision: 1.53.2.11
Checking in pcertt.h;  new revision: 1.13.30.2; previous revision: 1.13.30.1

I decided to commit this to the branch.  If anyone wants to carry this forward
to a new release, that's a separate issue.

Comment 5

[Daniel Veditz [:dveditz]]

Firefox 3 is currently using NSS 3.11.x, but at some point we'd like to upgrade that to NSS 3.12.x.  What changes would the client have to make to adapt to 3.12? Probably none (per your comment 2) but need to be sure.

We probably would not make that change in Firefox 3.0.10, but we probably wouldn't take a one-off unsupported (by the NSS team) patched NSS either.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Don't know of any necessary adaptations, off hand.  
Would be nice to get somebody to try to test it.

Comment 7

[Samuel Sidler (old account; do not CC)]

Nelson, can you (or someone on the NSS team that has the time) file a bug for upgrading 1.9.0.x to NSS 3.12.x? And if you (or anyone) happen to know of things we should be aware of for such an upgrade, that'd help a bunch.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Mozilla branch numbers always confuse me. :(
I think that 
  FF 2.x.x.x uses NSS 3.11.x
  FF 3.0.x   uses NSS 3.12.x (with x < 3 currently, but could be 3.12.any)
  FF 3.5.x   will use NSS 3.12.x with x >= 3.  
So, I'm not sure any additional bugs are needed here.  
This bug is essentially just to benefit FF 2.x.x.x
But let me know if you still think that more bugs are needed.

Comment 9

[Samuel Sidler (old account; do not CC)]

Thanks for the explanation Nelson. Apparently we were a little confused. :) No new bug needed!

Comment 10

[Kaspar]

(In reply to comment #3)
> Kaspar, do you have a specific consumer of this patch in mind?
> Is there a particular Linux distro, or other distributor of FF2, or 
> other software group that you believe might make an NSS 3.11.11 release 
> even if Mozilla's NSS team does not?

Sorry about the late reaction. The main consumers I had in mind are Thunderbird 2 and Seamonkey. Tb currently uses 3.11.10.1 (http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=MOZILLA_1_8_BRANCH&mark=262#255), that's why I was filing this bug, originally.

As far as Linux distributions are concerned, those with 5-year maintenance periods (RHEL, Ubuntu LTS etc.) are probably interested in backported fixes, because they are usually reluctant to replace system-wide libraries with considerably newer versions (i.e., an upgrade from 3.11 to 3.12).