nss question: did we close on the nspr issue?

Submitted by Wichmann Mats D on Thu, 08/28/2008 - 15:30.

A while back there was some discussion about the need for nspr. nspr is clearly an internal dependency, but if it's /only/ internal it doesn't necessarily have to be exposed in LSB. During a discussion yesterday, it turns out LSB participants weren't clear on whether we'd closed out that question or not. Does the nspr library and some set of interfaces need to be exposed in LSB? Or is the current proposed state sufficient for what we want to accomplish? -- mats

nss question: did we close on the nspr issue? - Submitted by Wan-Teh Chang on Thu, 08/28/2008 - 17:45.

Submitted by Wan-Teh Chang on Thu, 08/28/2008 - 17:45.

On Thu, Aug 28, 2008 at 8:23 AM, Wichmann, Mats D
wrote:
>
> A while back there was some discussion about the
> need for nspr. nspr is clearly an internal dependency,
> but if it's /only/ internal it doesn't necessarily have
> to be exposed in LSB. During a discussion yesterday,
> it turns out LSB participants weren't clear on whether
> we'd closed out that question or not.
>
> Does the nspr library and some set of interfaces
> need to be exposed in LSB? Or is the current
> proposed state sufficient for what we want to
> accomplish?

I meant to write about this issue yesterday but forgot.

Some NSPR functions need to be exposed to use
the SSL functions in NSS. These NSPR functions
need to be exposed in LSB.

Since NSPR is a finished product and its API has
been stable for years, I have no problem exposing
all the NSPR functions in LSB.

Wan-Teh Chang

nss question: did we close on the nspr issue? - Submitted by Wichmann Mats D on Thu, 08/28/2008 - 18:00.

Submitted by Wichmann Mats D on Thu, 08/28/2008 - 18:00.

Wan-Teh Chang wrote:
> On Thu, Aug 28, 2008 at 8:23 AM, Wichmann, Mats D
> wrote:
>>
>> A while back there was some discussion about the
>> need for nspr. nspr is clearly an internal dependency,
>> but if it's /only/ internal it doesn't necessarily have
>> to be exposed in LSB. During a discussion yesterday,
>> it turns out LSB participants weren't clear on whether
>> we'd closed out that question or not.
>>
>> Does the nspr library and some set of interfaces
>> need to be exposed in LSB? Or is the current
>> proposed state sufficient for what we want to
>> accomplish?
>
> I meant to write about this issue yesterday but forgot.
>
> Some NSPR functions need to be exposed to use
> the SSL functions in NSS. These NSPR functions
> need to be exposed in LSB.
>
> Since NSPR is a finished product and its API has
> been stable for years, I have no problem exposing
> all the NSPR functions in LSB.
>
> Wan-Teh Chang

Okay, if you give us some more detailed pointers,
we'll get going on this bit.

nss question: did we close on the nspr issue? - Submitted by Wan-Teh Chang on Thu, 08/28/2008 - 18:45.

Submitted by Wan-Teh Chang on Thu, 08/28/2008 - 18:45.

On Thu, Aug 28, 2008 at 10:55 AM, Wichmann, Mats D
wrote:
>
> Okay, if you give us some more detailed pointers,
> we'll get going on this bit.

NSPR's API is documented in the NSPR Reference at
http://www.mozilla.org/projects/nspr/reference/html/.

The functions that must be exposed to use the SSL
functionality in NSS are:

Socket I/O functions:
http://www.mozilla.org/projects/nspr/reference/html/priofnc.html#18579

Polling functions (optional):
http://www.mozilla.org/projects/nspr/reference/html/priofnc.html#19643

I/O layering functions (optional, equivalent to OpenSSL's BIO):
http://www.mozilla.org/projects/nspr/reference/html/priofnc.html#19749

Hostname resolution functions (optional):
http://www.mozilla.org/projects/nspr/reference/html/prntdb.html#20541

Date and time functions (for certificate validation, only PR_Now
is needed):
http://www.mozilla.org/projects/nspr/reference/html/prtime.html#21275

NSPR shutdown (PR_Cleanup, optional):
http://www.mozilla.org/projects/nspr/reference/html/prinit.html#15811

Getting the error codes (NSS has wrappers for these):
http://www.mozilla.org/projects/nspr/reference/html/prerr.html#PR_GetErr...
http://www.mozilla.org/projects/nspr/reference/html/prerr.html#PR_GetOSE...

Interrupting a blocking I/O function call of another thread:
http://www.mozilla.org/projects/nspr/reference/html/prthrd.html#15202
http://www.mozilla.org/projects/nspr/reference/html/prthrd.html#15471

Please let me know if you need any other information.

Wan-Teh Chang

nss question: did we close on the nspr issue? - Submitted by Ron Hale-Evans on Thu, 09/04/2008 - 19:45.

Submitted by Ron Hale-Evans on Thu, 09/04/2008 - 19:45.

This email is intended to start finalizing NSPR support in LSB.

With bug 2286 (Add libnspr to LSB), ISPRAS wrote some SQL to include
the libnspr interfaces to the database, including the following 35
interfaces. We were expecting about 20. A fair number of these are
marked as optional in Wan-Teh's email (below this list). Which of
these interfaces are really necessary for inclusion of NSPR in LSB,
and which interfaces can we legitimately exclude?

PR_Accept
PR_AcceptRead
PR_Bind
PR_Cleanup
PR_Connect
PR_CreateIOLayerStub
PR_EnumerateHostEnt
PR_GetConnectStatus
PR_GetCurrentThread
PR_GetDefaultIOMethods
PR_GetError
PR_GetHostByAddr
PR_GetHostByName
PR_GetLayersIdentity
PR_GetNameForIdentity
PR_GetOSError
PR_GetPeerName
PR_GetSockName
PR_GetSocketOption
PR_GetUniqueIdentity
PR_Interrupt
PR_Listen
PR_NewTCPSocket
PR_NewUDPSocket
PR_Now
PR_Poll
PR_PopIOLayer
PR_PushIOLayer
PR_Recv
PR_RecvFrom
PR_Send
PR_SendTo
PR_SetSocketOption
PR_Shutdown
PR_TransmitFile

Ron Hale-Evans

On Thu, Aug 28, 2008 at 11:33 AM, Wan-Teh Chang wrote:
> On Thu, Aug 28, 2008 at 10:55 AM, Wichmann, Mats D
> wrote:
>>
>> Okay, if you give us some more detailed pointers,
>> we'll get going on this bit.
>
> NSPR's API is documented in the NSPR Reference at
> http://www.mozilla.org/projects/nspr/reference/html/.
>
> The functions that must be exposed to use the SSL
> functionality in NSS are:
>
> Socket I/O functions:
> http://www.mozilla.org/projects/nspr/reference/html/priofnc.html#18579
>
> Polling functions (optional):
> http://www.mozilla.org/projects/nspr/reference/html/priofnc.html#19643
>
> I/O layering functions (optional, equivalent to OpenSSL's BIO):
> http://www.mozilla.org/projects/nspr/reference/html/priofnc.html#19749
>
> Hostname resolution functions (optional):
> http://www.mozilla.org/projects/nspr/reference/html/prntdb.html#20541
>
> Date and time functions (for certificate validation, only PR_Now
> is needed):
> http://www.mozilla.org/projects/nspr/reference/html/prtime.html#21275
>
> NSPR shutdown (PR_Cleanup, optional):
> http://www.mozilla.org/projects/nspr/reference/html/prinit.html#15811
>
> Getting the error codes (NSS has wrappers for these):
> http://www.mozilla.org/projects/nspr/reference/html/prerr.html#PR_GetErr...
> http://www.mozilla.org/projects/nspr/reference/html/prerr.html#PR_GetOSE...
>
> Interrupting a blocking I/O function call of another thread:
> http://www.mozilla.org/projects/nspr/reference/html/prthrd.html#15202
> http://www.mozilla.org/projects/nspr/reference/html/prthrd.html#15471
>
> Please let me know if you need any other information.
>
> Wan-Teh Chang

nss question: did we close on the nspr issue? - Submitted by Wan-Teh Chang on Fri, 09/05/2008 - 19:15.

Submitted by Wan-Teh Chang on Fri, 09/05/2008 - 19:15.

On Thu, Sep 4, 2008 at 12:32 PM, Ron Hale-Evans wrote:
> This email is intended to start finalizing NSPR support in LSB.
>
> With bug 2286 (Add libnspr to LSB), ISPRAS wrote some SQL to include
> the libnspr interfaces to the database, including the following 35
> interfaces. We were expecting about 20. A fair number of these are
> marked as optional in Wan-Teh's email (below this list). Which of
> these interfaces are really necessary for inclusion of NSPR in LSB,
> and which interfaces can we legitimately exclude?
>
> PR_Accept
> PR_AcceptRead
> PR_Bind
> PR_Cleanup
> PR_Connect
> PR_CreateIOLayerStub
> PR_EnumerateHostEnt
> PR_GetConnectStatus
> PR_GetCurrentThread
> PR_GetDefaultIOMethods
> PR_GetError
> PR_GetHostByAddr
> PR_GetHostByName
> PR_GetLayersIdentity
> PR_GetNameForIdentity
> PR_GetOSError
> PR_GetPeerName
> PR_GetSockName
> PR_GetSocketOption
> PR_GetUniqueIdentity
> PR_Interrupt
> PR_Listen
> PR_NewTCPSocket
> PR_NewUDPSocket
> PR_Now
> PR_Poll
> PR_PopIOLayer
> PR_PushIOLayer
> PR_Recv
> PR_RecvFrom
> PR_Send
> PR_SendTo
> PR_SetSocketOption
> PR_Shutdown
> PR_TransmitFile

Hi Ron,

I will look at this list more closely this weekend and send you an
improved list next week.

Let me explain why I marked some NSPR functions as optional.
They are optional in that you can use the SSL functions in NSS
without these NSPR functions. A good example is
PR_NewUDPSocket. Since SSL runs over TCP, there is
no need to create UDP sockets for SSL.

On the other hand, there is nothing wrong with including
PR_NewUDPSocket in the LSB. If there is cost involved
with each included function, for example in documentation
and testing, then I can try to generate an absolutely
minimal list required for NSS SSL functions.

If the worry is on API stability, then don't worry -- all the
NSPR functions have been stable for years, and I'll generate
a more complete list of NSPR functions that can be
used with NSS SSL functions. It'll still be a subset of
the full NSPR API.

I'd appreciate it if you could give me some guidance.

Wan-Teh

nss question: did we close on the nspr issue? - Submitted by Ron Hale-Evans on Sat, 09/06/2008 - 23:00.

Submitted by Ron Hale-Evans on Sat, 09/06/2008 - 23:00.

On Fri, Sep 5, 2008 at 12:00 PM, Wan-Teh Chang wrote:
> On Thu, Sep 4, 2008 at 12:32 PM, Ron Hale-Evans wrote:
>> This email is intended to start finalizing NSPR support in LSB.
>>
>> With bug 2286 (Add libnspr to LSB), ISPRAS wrote some SQL to include
>> the libnspr interfaces to the database, including the following 35
>> interfaces. We were expecting about 20. A fair number of these are
>> marked as optional in Wan-Teh's email (below this list). Which of
>> these interfaces are really necessary for inclusion of NSPR in LSB,
>> and which interfaces can we legitimately exclude?
>> [snip]
>
> Hi Ron,
>
> I will look at this list more closely this weekend and send you an
> improved list next week.
>
> Let me explain why I marked some NSPR functions as optional.
> They are optional in that you can use the SSL functions in NSS
> without these NSPR functions. A good example is
> PR_NewUDPSocket. Since SSL runs over TCP, there is
> no need to create UDP sockets for SSL.
>
> On the other hand, there is nothing wrong with including
> PR_NewUDPSocket in the LSB. If there is cost involved
> with each included function, for example in documentation
> and testing, then I can try to generate an absolutely
> minimal list required for NSS SSL functions.

Thank you, Wan-Teh. Yes, I'd appreciate it if you would create an
absolutely minimal list for us. There is always a cost in supporting
interfaces, whether in documentation, testing, or in the additional
burden on ISVs and distributions. However, we can add more NSPR
functions later, by request or because we discover new dependencies,
and if the LSB 4.0 deadline weren't looming for us, we might have
decided to be more inclusive this time.

Thanks,

Ron Hale-Evans

nss question: did we close on the nspr issue? - Submitted by Wan-Teh Chang on Mon, 09/08/2008 - 23:30.

Submitted by Wan-Teh Chang on Mon, 09/08/2008 - 23:30.

On Sat, Sep 6, 2008 at 3:55 PM, Ron Hale-Evans wrote:
>
> Thank you, Wan-Teh. Yes, I'd appreciate it if you would create an
> absolutely minimal list for us. There is always a cost in supporting
> interfaces, whether in documentation, testing, or in the additional
> burden on ISVs and distributions. However, we can add more NSPR
> functions later, by request or because we discover new dependencies,
> and if the LSB 4.0 deadline weren't looming for us, we might have
> decided to be more inclusive this time.

Hi Ron,

Here is an absolutely minimal list of NSPR functions required
for using the NSS SSL functions. This list is different from
the list I sent before.

I generated this list by inspecting the source code of libcurl,
nss_compat_ossl, mod_nss, and the NSS test programs
selfserv, tstclnt, strsclnt, vfyserv, and vfychain.

I documented this list in the wiki page at
http://developer.mozilla.org/En/NSS_reference/NSPR_functions

Since the wiki page may change, here is a static list for
the record:

PR_Cleanup

PR_GetError
PR_SetError

PR_Now

PR_SecondsToInterval
PR_MillisecondsToInterval

PR_GetUniqueIdentity
PR_CreateIOLayerStub
PR_GetDefaultIOMethods
PR_GetIdentitiesLayer
PR_GetLayersIdentity
PR_PushIOLayer
PR_PopIOLayer

PR_ImportTCPSocket

PR_Read
PR_Write
PR_Recv
PR_Send
PR_GetSocketOption
PR_SetSocketOption
PR_Shutdown
PR_Close

Wan-Teh Chang

nss question: did we close on the nspr issue? - Submitted by Denis Silakov on Wed, 09/10/2008 - 11:00.

Submitted by Denis Silakov on Wed, 09/10/2008 - 11:00.

Wan-Teh Chang wrote:
> PR_ImportTCPSocket

The page referenced in wiki seems to be the only documentation source
for this interface. Should we reference that page directly or it will be
included in the NSPR Reference?

--
Regards,
Denis.

nss question: did we close on the nspr issue? - Submitted by Wan-Teh Chang on Wed, 09/10/2008 - 23:45.

Submitted by Wan-Teh Chang on Wed, 09/10/2008 - 23:45.

On Wed, Sep 10, 2008 at 3:53 AM, Denis Silakov wrote:
> Wan-Teh Chang wrote:
>>
>> PR_ImportTCPSocket
>
> The page referenced in wiki seems to be the only documentation source for
> this interface. Should we reference that page directly or it will be
> included in the NSPR Reference?

Denis,

I should have explained this.

We are migrating the NSPR Reference to the wiki at
http://developer.mozilla.org/En/NSPR_API_Reference.
The migration is not done, which is why I still have the
habit of referring to the original NSPR Reference at
http://www.mozilla.org/projects/nspr/reference/html/,
and for minor changes I try to change both places.

But new functions will only be documented in the
wiki. Also, the majority of the NSPR Reference
has been migrated, so I recommend that LSB
reference the pages in the wiki. All the links in
http://developer.mozilla.org/En/NSS_reference/NSPR_functions
point to the wiki.

Wan-Teh Chang

nss question: did we close on the nspr issue? - Submitted by tytso on Thu, 09/11/2008 - 14:00.

Submitted by tytso on Thu, 09/11/2008 - 14:00.

On Wed, Sep 10, 2008 at 04:40:52PM -0700, Wan-Teh Chang wrote:
>
> We are migrating the NSPR Reference to the wiki at
> http://developer.mozilla.org/En/NSPR_API_Reference.
> The migration is not done, which is why I still have the
> habit of referring to the original NSPR Reference at
> http://www.mozilla.org/projects/nspr/reference/html/,
> and for minor changes I try to change both places.
>
> But new functions will only be documented in the
> wiki. Also, the majority of the NSPR Reference
> has been migrated, so I recommend that LSB
> reference the pages in the wiki. All the links in
> http://developer.mozilla.org/En/NSS_reference/NSPR_functions
> point to the wiki.

One of the things which is a little worrisome about Wiki's are their
mutability. This is true of anything on the web, of course, but
Wiki's raison de etre *is* that they are very easy to change. If we
are going to be referencing a standard specification for LSB 4.0, this
can be a problem, since we really want to be sure that we what we
reference when we release LSB 4.0 is the same thing other people will
see if they look at the referenced specification 2 or 3 years later.

Do you have a provision for maintaining stable snapshots of the wiki?
Or would you mind if we somehow snapshotted the relevant pages from
the wiki and stored them someplace stable, and referenced both the
stable snapshot as well as the mutable wiki version? Some users might
want to see any clarifications or improvements to the specification
from a tutorial perspective, but other people might want to make sure
they can see somethign which they know is stable and unchanging, at
least with respect to LSB 4.0 compliance.

Regards,

- Ted

nss question: did we close on the nspr issue? - Submitted by Wan-Teh Chang on Thu, 09/11/2008 - 21:15.

Submitted by Wan-Teh Chang on Thu, 09/11/2008 - 21:15.

On Thu, Sep 11, 2008 at 6:37 AM, Theodore Tso wrote:
>
> One of the things which is a little worrisome about Wiki's are their
> mutability. This is true of anything on the web, of course, but
> Wiki's raison de etre *is* that they are very easy to change. If we
> are going to be referencing a standard specification for LSB 4.0, this
> can be a problem, since we really want to be sure that we what we
> reference when we release LSB 4.0 is the same thing other people will
> see if they look at the referenced specification 2 or 3 years later.
>
> Do you have a provision for maintaining stable snapshots of the wiki?
> Or would you mind if we somehow snapshotted the relevant pages from
> the wiki and stored them someplace stable, and referenced both the
> stable snapshot as well as the mutable wiki version? Some users might
> want to see any clarifications or improvements to the specification
> from a tutorial perspective, but other people might want to make sure
> they can see somethign which they know is stable and unchanging, at
> least with respect to LSB 4.0 compliance.

Hi Ted,

We don't have a provision for maintaining stable snapshots of the wiki.
The master source of the content on www.mozilla.org is in a CVS
repository. It is a lot of work to edit it. This is why we are migrating
the NSPR Reference to the wiki.

It'd be certainly fine if you snapshotted the relevant pages from
the wiki and referenced both the stable snapshot and the
mutable wiki version. I used an open source tool called
HTTrack to take snapshots of NSS's FIPS validation docs
on another wiki before. I documented the instructions at
http://www.mozilla.org/projects/security/pki/nss/fips/wiki-download.html

Wan-Teh Chang

nss question: did we close on the nspr issue? - Submitted by Denis Silakov on Thu, 09/11/2008 - 09:30.

Submitted by Denis Silakov on Thu, 09/11/2008 - 09:30.

Wan-Teh Chang wrote:
> Denis,
>
> I should have explained this.
>
> We are migrating the NSPR Reference to the wiki at
> http://developer.mozilla.org/En/NSPR_API_Reference.
> The migration is not done, which is why I still have the
> habit of referring to the original NSPR Reference at
> http://www.mozilla.org/projects/nspr/reference/html/,
> and for minor changes I try to change both places.
>
> But new functions will only be documented in the
> wiki. Also, the majority of the NSPR Reference
> has been migrated, so I recommend that LSB
> reference the pages in the wiki. All the links in
> http://developer.mozilla.org/En/NSS_reference/NSPR_functions
> point to the wiki.
>
> Wan-Teh Chang
>

Thanks, Wan-Teh. We'll take it into account.

--
Regards,
Denis.

nss question: did we close on the nspr issue?

Community Support

Active forum topics

About the Author