Re: Removal of NSS and/or NSPR from the API exposed to addons

2012-01-18 Thread Brian Smith
Mike Hommey wrote: > > In the long run, for performance reasons, we should probably prefer > > the system NSS libraries to our own, whenever the system NSS > > libraries are available and are the right version, because at > > least some of them are likely to already have been loaded into RAM > > by

Re: Removal of NSS and/or NSPR from the API exposed to addons

2012-01-18 Thread Mike Hommey
On Wed, Jan 18, 2012 at 02:44:34PM -0800, Brian Smith wrote: > Mike Hommey wrote: > > Please note that this is going to be a problem on systems that have > > system nspr and nss libraries that other system libraries use. > > I am intending to avoid changing how NSS is linked on Linux, at least at

Re: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

2012-01-18 Thread Brian Smith
Sean Leonard wrote: > The most glaring problem however is that when validation fails, such > as in the case of a revoked certificate, the API returns no > certificate chains My understanding is that when you are doing certificate path building, and you have to account for multiple possibilities

Re: Removal of NSS and/or NSPR from the API exposed to addons

2012-01-18 Thread Wan-Teh Chang
On Wed, Jan 18, 2012 at 2:44 PM, Brian Smith wrote: > Mike Hommey wrote: >> Please note that this is going to be a problem on systems that have >> system nspr and nss libraries that other system libraries use. > > I am intending to avoid changing how NSS is linked on Linux, at least at the > begi

Re: Removal of NSS and/or NSPR from the API exposed to addons

2012-01-18 Thread Brian Smith
Benjamin Smedberg wrote: > I have no particular opinion about whether this is a good idea for > NSS. I do think that we should not do this for NSPR unless we > decide to remove support for binary XPCOM components in Firefox > (per the ongoing discussion in dev.planning). Many of our XPCOM > code pa

Re: Removal of NSS and/or NSPR from the API exposed to addons

2012-01-18 Thread Brian Smith
Mike Hommey wrote: > Please note that this is going to be a problem on systems that have > system nspr and nss libraries that other system libraries use. I am intending to avoid changing how NSS is linked on Linux, at least at the beginning. My priorities are are Android and Windows first, then M

Re: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

2012-01-18 Thread Sean Leonard
Hi All, I'm the lead developer of Gmail S/MIME, and its successor, Penango, which is bringing /end-to-end/ cross-platform S/MIME secure e-mail to webmail and web-based messaging everywhere. It seems that this thread has brought out its fair share or lurkers so I thought I would add some persp

Re: Removal of NSS and/or NSPR from the API exposed to addons

2012-01-18 Thread David Dahl
- Original Message - > From: "Benjamin Smedberg" > To: "Brian Smith" > Cc: "dev-platform" , "mozilla's crypto code > discussion list" > > Sent: Wednesday, January 18, 2012 11:06:21 AM > Subject: Re: Removal of NSS and/or NSPR from the API exposed to addons > > 3. Help out with the DOMC

Re: Removal of NSS and/or NSPR from the API exposed to addons

2012-01-18 Thread Benjamin Smedberg
On 1/18/2012 1:30 AM, Brian Smith wrote: they live in, and/or we may change the DLL we export those symbols from. This will be a very positive footprint win, because it means that the linker will be able to throw away the code for a lot of functions in NSPR and (especially) NSS that are unused