404199 - Expose MPI for access from application (e.g. from JavaScript)

Status: RESOLVED WONTFIX

(NSS :: Libraries, enhancement, P4)

Description

[Alberto González Palomo]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; es-ES; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; es-ES; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

NSS includes the MPI bignum library.
It would be useful to have a way of doing bignum computations from JavaScript.
I want it for an extension I'm developing. I've considered trying to make my own XPCOM component by compiling GMP or other library, but it seems complicated so I thought that perhaps it wouldn't take long to make the MPI functions available through XPCOM so that it was always available in the standard build. For now my extension is written only in JavaScript, so including binary components would make it much more difficult for me to support it in all platforms.
I know C++ and would be glad to work on it myself if told exactly what documents to read and where to put the files (IDL or whatever is needed). Otherwise I don't even now where to start.

Reproducible: Always

Comment 1

[Julien Pierre]

NSS is architected in a way to hide the low-level computations in mpi from the higher-level application. This is also required for FIPS140 compliance of the NSS softoken. We simply aren't going to expose mpi in an NSS shared library. mpi can still be built as a static library if you like however, using the Makefile in mozilla/security/nss/lib/freebl/mpi .

Comment 2

[Alberto González Palomo]

I see, thanks. That's a clear answer to my question.
I'll go ahead and do the bignum support on my own, which will be better on the long run since after I have a first XPCOM component, it will be easy to add any other functionality I need.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

I'm not sure that comment #1 speaks for the whole NSS team, and indeed it 
appears to be a change from replies given to older requests for the same
thing, which are still open. In bug 212864 comment 4, Julien wrote:

> I would [propose] that we build an MPI shared library on all platforms, 
> and link both softoken and NSS shared libs against that MPI shared lib.  

I concur that's a good way to do this.  For simplicity, I would suggest 
exposing it through the freebl API.   But it's not a high priority for 
the NSS team now.  With reduced staff and a huge work load, there needs to 
be a more compelling reason to raise its priority.  

Comment 4

[Julien Pierre]

Nelson, actually you wrote that comment, not me :)
I personally think we need the freedom to implement the low-level stuff in any way we want. We have considered using libraries other than MPIs for bignum on some platforms, though we haven't actually implemented thta.

Even the freebl API is not a stable API. We are free to modify it at any point in ways that are incompatible right now. This would potentially break any JS/XPCOM component that would rely on it. freebl is currently a private interface for exclusive use by libsoftokn3 and libssl3 . I think it would be an additional burden for NSS to expose mpi as a public API, which we don't need, especially with the current level of resources we have.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Julien, You're right. I wrote that comment.  Sorry.  :-(

I am aware of the other libraries we considered. I did the original
survey of bignum libraries, and chose the MPI API for its suitability 
in multi-threaded applications, and its suitable license terms. 
(Quite a few of the others used global variables, or had unacceptable 
licenses.)  I also did the work to raise MPI's performance to a level
competitive with the other libraries of that time.  

There are now at least 4 implementations of the MPI API known to me, 
including at least one very fast one (with limited integer size) that 
claims to be public domain (libTomMath).  The implementations are similar
enough that their authors have been able to share code.  So I consider the 
API to be quite stable (even if the implementations are frequently revised). 
I have no objection, in principle, to exposing that API through freebl's function table.  

But I agree that, ultimately, making best use of our development resources 
is our greatest duty, and at this time, we don't have enough to start this
additional project.