Talk:NSS Library Init

Read-Only applications prevent read-write DB access?

In the section How we initially intended to solve these problems there is a statement that reads:

some applications only need read-only access to the NSS configuration, but other applications (like Firefox, or Thunderbird) need read-write access. This means if a read/only user initializes first, then a read/write user will not be able to update the database.

The statement seems to suggest that separate applications affect each others' ability to open databases for read/write access. Surely that is not true with cert9 DBs, is it??

I think the section meant to say that, in a single application, if the first caller of NSS_Init opens it read-only, then the second caller cannot have read-write access. But that's not what it seems to say.

> Bad wording it should say 'some NSS users'. The issue is NSS users operating in the same address space.

Binary compatibility means applications must continue to fail?

In the section Restrictions on any future solution Item 1) NSS must maintain binary compatibility, says NSS shutdown puts NSS into a state where it can NOT be re-initialized if it had slot references in use when it was shut down. It says that some applications that switch profiles depend on this behavior.

Is that a mistake?

> I'm not sure where you saw that. Today NSS_Shutdown will not complete if there are open references. That is true, and will continue to be true. That was not what it was saying. It was saying the some applications that switch profiles expect NSS_Shutdown to shutdown independent of any existing libraries that may have opened NSS it the meantime. This says the NSS_Shutdown needs to ignore any open context and just shutdown (to the best of it's ability). If it weren't for this case, I would have suggested that NSS_Shutdown basically do an NSS_ShutdownContext(NULL).

Why count unique contexts?

Point 1 of the proposal says Multiple NSS_LibraryInit() calls are allowed. Each call will get it's own context. Point 3 of the proposal says NSS_LibraryShutdown() can be called once per context. If NSS_LibraryShutdown is called a second time on a context, an error is returned. But point 1 also says NSS will keep a count of NSS_LibraryInit calls. Why is a count of those calls necessary if each call gets its own unique context?

> The count was an implementation detail. It no longer exists. it's been replaces with a list of active contexts. In any case, it's still important to know when the last user has shutdown NSS so that NSS actually shuts down.

NSS_Init() semantics change after a call to NSS_LibraryInit() ??

Proposal point 2 says that, after the first time NSS_LibraryInit is called, subsequent calls to the older traditional NSS_Init functions change their behavior. I think this violates the principle of least astonishment. Well, that's an oversimplification, but I need to commit this now, and will expand on it later. This is probably the BIG issue!

> It would be if that was what it really said.

> NSS_Init is still idempotent. What changes is now NSS_Init is called, but NSS has already been initialized with NSS_ContextInit(). The first of these NSS_Init calls will do the same tap-dance that any NSS_ContextInit does. Subsequent NSS_Init calls will continue to act as they do today. I've changed the document working to make this more clear.