[lsb-discuss] [Fwd: NSS public functions]
Robert Relyea
rrelyea at redhat.com
Mon Aug 11 15:10:53 PDT 2008
Howard Chu wrote:
> Jeff Licquia wrote:
>
>> Howard Chu wrote:
>>
>>> Since NSS is inextricably dependent on NSPR, the inclusion of NSS in the LSB
>>> implies that NSPR must also be in the LSB. No?
>>>
>> Not unless reference to NSPR must be made in the source code of the
>> application to use NSS (or, at least, the portion of NSS that we specify).
>>
>> If the dependency is hidden, then we consider that to be an
>> implementation detail.
>>
>>
> In fact it's impossible to write an NSS app without also making numerous
> direct calls to NSPR. From this same page:
>
> http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslintro.html
> >>>
> Configuration
> PR_NewTCPSocket. ... A legal NSPR socket is required ...
>
> Communication
>
> A server application typically uses these functions to establish a connection:
>
> PR_Bind
> PR_Listen
> PR_Accept
> PR_GetSockName
>
> A client application typically uses these functions to establish a connection:
>
> PR_GetHostByName
> PR_EnumerateHostEnt
> PR_Connect
> PR_GetConnectStatus
> <<<
>
This is true of a typical NSPR application that uses NSS. Not all
applications are NSPR applications.
That being said, perhaps there will be some benefit to documenting a
fuller NSPR interface.
The current nss_compat_ossl layer which helps application in porting
only uses PR_NewTCPSocket, PR_Read, PR_Write, and
PR_ChangeFileDescNativeHandle.
But I think your point of documenting more of the NSPR interface is
valid. Advanced applications may want to use the PR_Layers call to catch
the intermediate SSL output (much like BIO), and some applications may
want to use NSPR natively as well. Certainly all the mozilla apps
require it, so it's unlikely that it won't be available on a given
distribution, and it provides that same Binary API guarrentees as NSS.
> Note - apps that use NSS generally cannot use OS-native calls for these
> extremely standard functions (including I/O and memory management). Instead
> they must use NSPR calls. This extra abstraction layer offers no benefit on
> Linux, it just increases overhead and application footprint. I believe
> NSS/NSPR are a poor choice upon which to build in the Linux environment. The
> net result would be like running a POSIX emulation machine on top of Linux -
> totally redundant, wasteful, and inefficient.
>
This is actually NOT true. We have may instances of applications that
use OS-native calls for all of these functions.
NSS itself uses these to isolate itself for cross platform work (NSS can
port to many platforms natively without bringing a Linux runtime or
build environment with it). On link, these functions usually map
directly to the OS calls, often at compile time.
I think this rumor came because many of the early NSS applications used
the NSPR runtime as well since they wanted the portability advantage.
Currently, however, we are running NSS in applications that have no
other calls to NSPR other then the PR_Read and PR_Write calls needed to
send SSL data. These map directly to the SSL_Read and SSL_Write calls.
The applications continue to use their own memory allocation, threading,
I/O and even select. We now know, today, that using NSS does not require
applications to change they way they do thing.
Thanks again, Howard, for the suggestion that we may want to document
more of the NSPR API.
bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20080811/17c9e41b/attachment.bin
More information about the lsb-discuss
mailing list