[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