[lsb-discuss] [Fwd: NSS public functions]

Howard Chu hyc at symas.com
Mon Aug 11 14:57:05 PDT 2008

Robert Relyea wrote:
> Hi Howard.
> Howard Chu wrote:
>> (resending, didn't see this get out the first time)
>> The presence of CERT_GetDefaultCertDB in this list implies that there may be
>> non-default DBs as well but any APIs for opening/obtaining/closing such DBs
>> are conspicuously absent from this list. (Likewise for *setting* the default.)
>> That seems like an important oversight...
> It's a legacy function that has nothing to due with actually certificate
> databases. NSS is perfectly capabable of openning several databases at
> once and using them

Yes. My point is that the APIs for manipulating these databases should be 
exposed in this spec because it's difficult to use NSS without them.

  (In fact the notion of databases are really not
> surfaced at the application level, NSS is perfectly cabable of treating
> PEM as database.
>> Since NSS is inextricably dependent on NSPR, the inclusion of NSS in the LSB
>> implies that NSPR must also be in the LSB. No?
> NSS is tied to NSPR in the same way as OpenSSL is tied to BIO. Those
> functions map pretty much one for one (we use that fact in openSSL
> compatibility libraries that we use to help port openSSL applications to
> NSS.
> Applications do not, however, have to adopt the NSS IO model. We have
> several instances of applications which have their own IO model and just
> use NSPR to do SSL reads and writes.

What APIs are used to accomplish this? The list of Public Functions doesn't 
include anything that actually performs application-level I/O. I'd expect at 
least an SSL_Read/SSL_Write to be present, but in all the code I've read apps 
simply use PR_Read/PR_Write. I.e., they must provide NSPR socket descriptors.

As it stands, it's not possible to write a working SSL application using NSS 
using only the functions listed here.


   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

More information about the lsb-discuss mailing list