Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion NSS 3.12 codesize hit (Was: Milestone Scheduling)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Boris Zbarsky  
View profile  
 More options Jul 22 2007, 12:28 pm
Newsgroups: mozilla.dev.planning
From: Boris Zbarsky <bzbar...@mit.edu>
Date: Sun, 22 Jul 2007 11:28:44 -0500
Local: Sun, Jul 22 2007 12:28 pm
Subject: Re: NSS 3.12 codesize hit (Was: Milestone Scheduling)

Mike Connor wrote:
> As a note, the codesize hit is the only visible problem, Tp/Ts/etc seem
> generally unaffected.

I very much doubt Tp exercises any of this code, since none of it is over https.
  Ts exercises some parts of PSM/NSS, I think (due to creating principals for
the stylesheets coming from jars).  I don't know whether it actually ends up
loading this .so, though.

> Almost by definition, any major new feature adds code, the question is
> how much new code is acceptable for a given feature.

Yes.  So let's put this in perspective.  Is a codesize that is 20% of gklayout
(or double that of cairo + thebes if you prefer to look at it that way)
acceptable for EV support?

I agree that the actual amount of code in terms of code complexity is not really
that big; the code is large because it's written with so much logic inlined, not
because there is so much logic.  At least the parts I saw.  So I'm not worried
about this destabilizing the app or anything, though I _am_ worried about
potential security issues in what is a large glob of code no matter what.  But
not much we can do about that, as you say.

> I think we've decided we want EV cert support as part of our security UI strategy

Given the limited real value of EV certs, a number of people (myself included)
were fine to include them as (a small) part of a more comprehensive approach to
the problem of phishing.  But if there's a high enough price to pay for EV
support, perhaps we need to revisit that decision.

Put another way, at the time it was nonobvious that EV support involved a 60%
increase in the size of the NSS libraries.

> That said, there's clearly a ton of work that should be done to optimize
> a lot of this codesize pain (bz has made some concrete suggestions in
> the bug)

Right.  I don't think anyone is arguing we shouldn't take this, offhand.  What
we need to figure out are:

1)  What can we do to improve things?
2)  Who will do that work?
3)  How we can get them started on it yesterday.

The closer we get to release, the less willing we should be to take the sort of
refactoring it will take to make this code smaller...  I really wish this
landing had taken place six months ago or so.  Not much use crying over that,
though.

> but I think we will take some sort of nontrivial hit, and I think we
> need to be prepared for that in order to get onto the new NSS version.  

I think sayrer's suggestion of a hit that's no bigger than the win we got from
turning off webservices is a good starting point.  If the code I looked at is
representative, I think this should be achievable.

> That hit should be as small as possible, but I see no situation where
> we'll throw away EV cert support over a codesize hit.

That contradicts the "I'm not saying a 9% Z hit is shippable" statement you make
earlier, for what it's worth.

-Boris


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.