Re: Removal of NSS and/or NSPR from the API exposed to addons
On 01/19/2012 02:55 AM, Brian Smith wrote: > Mike Hommey wrote: >> But linux users are not necessarily up-to-date with the latest NSS. I >> seriously doubt the number of users with the very last system nss >> exceeds 10% of the linux user base except in exceptional "good >> timing" cases (like when ubuntu is released with the latest version), >> but that doesn't last long). > > If the system NSS isn't new enough, then Firefox's local version of NSS would > be used. And, if that is complicated to implement at all, then we can just > avoid trying to optimize how we load NSS on Linux at all. To be honest, you > would likely be the one to implement any of these optimizations on Linux, if > they are ever to happen at all. > > I am not intending to optimize NSS or rearrange it for code size on Linux *at > all* because of these issues. For example, the idea of linking NSS into > libxul *on Linux* was taken off the table a long time ago, because of these > issues and others. Gecko (or Firefox and Thunderbird individually) would have > its own special build configuration of NSS on Android, Windows, Mac, and B2G > *only*, according to the current plan. The same build configuration we have > now, which is the same build configuration that system NSS builds are done > with (more or less), would be the build configuration used on Linux for the > indefinite future. > > AFAICT, any distro that ships its own builds of Firefox seems to configure > Firefox to use system NSS and system NSPR, and that effectively means that > those distros have to be on their toes with the latest NSS and NSPR releases > available as installable packages whenever they release a new version of > Firefox, since every version of Firefox going forward will require the very > latest NSS and/or NSPR for the foreseeable future. If this doesn't work for > them then they will have to stop configuring their Firefox packages to depend > on system NSS and/or system NSPR packages. > > - Brian FWIW, Ubuntu doesn't do this. We build Firefox and Thunderbird with its internal NSS/NSPR as this makes things easier with the Rapid Release train. Micah -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
On Thu, Jan 19, 2012 at 11:15:51AM -0500, John Dennis wrote: > On 01/19/2012 07:26 AM, Mike Hommey wrote: > >He is talking about runtime detection. Not build time detection. And we > >already have --with-system-nss. My point is that it's probably not worth > >trying to do runtime detection because few systems will have the right > >system nss anyways. > > I've been lurking on this thread. There seems to be an assumption > that on Linux system NSS won't be current, won't be available and > you might deploy something which has a dependency that can't be > detected and satisfied during installation. > > At least on RPM based systems (Fedora and RHEL in particular) none > of this is true. When packages are built you have to opportunity to > express the dependency, the installer won't install the package > unless the dependencies can be satisfied and the installer knows how > to locate and download the dependencies. Also, when there is a > dependency affecting other packages there is a coordinated effort > update things in unison. Can't speak for Debian based systems, but > my understanding is they have similar facilities. > > So what's the problem with using system NSS? We're not speaking of distro-packaged firefox. We're talking about Mozilla-shipped firefox binaries. These can't use system NSS because system NSS is likely too old. Shipping RPMs and DEBs that only work on non-released fedora and ubuntu branches is not a solution. Mike -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
On 01/19/2012 07:26 AM, Mike Hommey wrote: He is talking about runtime detection. Not build time detection. And we already have --with-system-nss. My point is that it's probably not worth trying to do runtime detection because few systems will have the right system nss anyways. I've been lurking on this thread. There seems to be an assumption that on Linux system NSS won't be current, won't be available and you might deploy something which has a dependency that can't be detected and satisfied during installation. At least on RPM based systems (Fedora and RHEL in particular) none of this is true. When packages are built you have to opportunity to express the dependency, the installer won't install the package unless the dependencies can be satisfied and the installer knows how to locate and download the dependencies. Also, when there is a dependency affecting other packages there is a coordinated effort update things in unison. Can't speak for Debian based systems, but my understanding is they have similar facilities. So what's the problem with using system NSS? BTW, the practice of not using system NSS with firefox massively broke things for us recently, one of the clear downsides of using private versions of NSS independent of the global system environment. Would truly like to avoid that experience again. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
Eitan Adler wrote: > Brian Smith wrote: > > If the system NSS isn't new enough, then Firefox's local version of > > NSS would be used. > > From a packager point of view, please don't automagically detect > these things. If the system NSS is supported provide an option > --with-system-nss which if not set will use the bundled NSS. I suggested this "automagic" mechanism only for when --use-system-nss is NOT used (i.e. basically for Mozilla-distributed Firefox only). --use-system-nss would force the use of system NSS. The idea behind it is to get Mozilla-distributed Firefox to integrate with other software on the system a little more sanely and a little more efficiently than it currently does, *if* (big IF) the distro has a new-enough NSS package. - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
On Thu, Jan 19, 2012 at 06:52:26AM -0500, Eitan Adler wrote: > On Thu, Jan 19, 2012 at 3:55 AM, Brian Smith wrote: > > Mike Hommey wrote: > >> But linux users are not necessarily up-to-date with the latest NSS. I > >> seriously doubt the number of users with the very last system nss > >> exceeds 10% of the linux user base except in exceptional "good > >> timing" cases (like when ubuntu is released with the latest version), > >> but that doesn't last long). > > > > If the system NSS isn't new enough, then Firefox's local version of NSS > > would be used. > > From a packager point of view, please don't automagically detect these > things. If the system NSS is supported provide an option > --with-system-nss which if not set will use the bundled NSS. He is talking about runtime detection. Not build time detection. And we already have --with-system-nss. My point is that it's probably not worth trying to do runtime detection because few systems will have the right system nss anyways. Mike -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
On Thu, Jan 19, 2012 at 3:55 AM, Brian Smith wrote: > Mike Hommey wrote: >> But linux users are not necessarily up-to-date with the latest NSS. I >> seriously doubt the number of users with the very last system nss >> exceeds 10% of the linux user base except in exceptional "good >> timing" cases (like when ubuntu is released with the latest version), >> but that doesn't last long). > > If the system NSS isn't new enough, then Firefox's local version of NSS would > be used. >From a packager point of view, please don't automagically detect these things. If the system NSS is supported provide an option --with-system-nss which if not set will use the bundled NSS. > AFAICT, any distro that ships its own builds of Firefox seems to configure > Firefox to use system NSS and system NSPR, and that effectively means that > those distros have to be on their toes with the latest NSS and NSPR releases > available as installable packages whenever they release a new version of > Firefox, since every version of Firefox going forward will require the very > latest NSS and/or NSPR for the foreseeable future. If this doesn't work for > them then they will have to stop configuring their Firefox packages to depend > on system NSS and/or system NSPR packages. As long as there is a release version of NSS that works with the latest version of Firefox it shouldn't be a problem -- Eitan Adler -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
Mike Hommey wrote: > But linux users are not necessarily up-to-date with the latest NSS. I > seriously doubt the number of users with the very last system nss > exceeds 10% of the linux user base except in exceptional "good > timing" cases (like when ubuntu is released with the latest version), > but that doesn't last long). If the system NSS isn't new enough, then Firefox's local version of NSS would be used. And, if that is complicated to implement at all, then we can just avoid trying to optimize how we load NSS on Linux at all. To be honest, you would likely be the one to implement any of these optimizations on Linux, if they are ever to happen at all. I am not intending to optimize NSS or rearrange it for code size on Linux *at all* because of these issues. For example, the idea of linking NSS into libxul *on Linux* was taken off the table a long time ago, because of these issues and others. Gecko (or Firefox and Thunderbird individually) would have its own special build configuration of NSS on Android, Windows, Mac, and B2G *only*, according to the current plan. The same build configuration we have now, which is the same build configuration that system NSS builds are done with (more or less), would be the build configuration used on Linux for the indefinite future. AFAICT, any distro that ships its own builds of Firefox seems to configure Firefox to use system NSS and system NSPR, and that effectively means that those distros have to be on their toes with the latest NSS and NSPR releases available as installable packages whenever they release a new version of Firefox, since every version of Firefox going forward will require the very latest NSS and/or NSPR for the foreseeable future. If this doesn't work for them then they will have to stop configuring their Firefox packages to depend on system NSS and/or system NSPR packages. - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
On Wed, Jan 18, 2012 at 11:45:02PM -0800, Brian Smith wrote: > 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 other applications. It seems like this may avoid the types of > > > issues you are concerned about too. > > > > Except if we change the current trend, which is to use unreleased > > nspr/nss code in mozilla, there's no way this can be sustainable. > > The system NSS libraries will no longer be the "right version" in that case. > > We (NSS team) have agreed to make sure that Firefox *releases* will always be > compatible with the latest NSPR and NSS release. Almost always, Firefox beta > releases will have that property too. But, often -nightly and -aurora won't > be compatible with the latest NSPR or NSS release, though they will usually > be compatible with the NSPR and NSS CVS trunk. The current situation is in > -nightly and -aurora is exceptional. But linux users are not necessarily up-to-date with the latest NSS. I seriously doubt the number of users with the very last system nss exceeds 10% of the linux user base except in exceptional "good timing" cases (like when ubuntu is released with the latest version), but that doesn't last long). Mike -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
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 other applications. It seems like this may avoid the types of > > issues you are concerned about too. > > Except if we change the current trend, which is to use unreleased > nspr/nss code in mozilla, there's no way this can be sustainable. The system NSS libraries will no longer be the "right version" in that case. We (NSS team) have agreed to make sure that Firefox *releases* will always be compatible with the latest NSPR and NSS release. Almost always, Firefox beta releases will have that property too. But, often -nightly and -aurora won't be compatible with the latest NSPR or NSS release, though they will usually be compatible with the NSPR and NSS CVS trunk. The current situation is in -nightly and -aurora is exceptional. - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
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 the > beginning. My priorities are are Android and Windows first, then Mac. > > 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 other applications. It seems like > this may avoid the types of issues you are concerned about too. Except if we change the current trend, which is to use unreleased nspr/nss code in mozilla, there's no way this can be sustainable. Mike -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
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 > beginning. On Linux and other Unix platforms where NSS is available as a system library, we cannot ask third-party code to not use NSS. It is best for libxul to continue to link with NSS as shared libraries on those platforms. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
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 patterns assume/require use of NSPR, and I don't think it's > the right time to try changing that. NSPR is not nearly as big as NSS and we use a large percentage of NSPR functionality. So, this kind of "dead code" elimination for NSPR would not necessarily be a justifiable win considering potential compatibility pain, like it would be for NSS. And also, I don't know (yet) of any startup time, correctness, or security wins from doing this for NSPR, like I do know for NSS. Even if we link NSS and/or NSPR into libxul, we can easily create forwarder DLLs with the old DLL names that forward calls to the retained functions in libxul, so that any binary components that link to NSS/NSPR and only use the NSS/NSPR functions we retain will work correctly. > > 3. Help out with the DOMCrypt effort that ddahl is leading, which > > will create a W3C-standardized Javascript API for cryptography for > > *web* applications. I suspect it would be non-trivial, but > > possible, to expose the DOMCrypt API to extensions. I suspect that > > this would replace APIs from #1 and #2 above. > I tend to think that extensions would get this basically "for free" > because they have access to the DOM. It is likely that DOMCrypt will base part of its key management system on a same-origin policy, and that origin-based key management policy is likely to be inappropriate for a bunch of applications. Also, I do not know how JetPack (Addon SDK) deals with any "origin", and I bet there will need to be some new/different glue to get DOMCrypt to fit into the JetPack model. - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
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 Mac. 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 other applications. It seems like this may avoid the types of issues you are concerned about too. - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
- 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 DOMCrypt effort that ddahl is leading, which > > will create a W3C-standardized Javascript API for cryptography for > > *web* applications. I suspect it would be non-trivial, but > > possible, to expose the DOMCrypt API to extensions. I suspect that > > this would replace APIs from #1 and #2 above. > I tend to think that extensions would get this basically "for free" > because they have access to the DOM. Indeed they will. There is also (possibly going to be) a privileged JS API that allows for more flexibility as the DOM API will tie all crypto operations to the current domain. I can see some extensions needing to ignore this limitation. David -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of NSS and/or NSPR from the API exposed to addons
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 by Firefox (or Thunderbird, for Thunderbird builds). The footprint win, combined with fewer codepaths to consider during link-time optimization, and the knowledge that there are no unknown callers of these functions, will likely be a pretty positive startup time win and a small general perf win within PSM/NSS in Gecko. 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 patterns assume/require use of NSPR, and I don't think it's the right time to try changing that. 3. Help out with the DOMCrypt effort that ddahl is leading, which will create a W3C-standardized Javascript API for cryptography for *web* applications. I suspect it would be non-trivial, but possible, to expose the DOMCrypt API to extensions. I suspect that this would replace APIs from #1 and #2 above. I tend to think that extensions would get this basically "for free" because they have access to the DOM. --BDS -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
