So what I actually want is
- To fix the API to the NSS system database so it isn't insane.
Do you have any suggestions on how the API would be changes. One thing=20
I'm always fighting is providing an API for apps without breaking=20
existing apps.
Well, *not* having to grub around for 'library=libnsssysinit.so'
in /etc/pki/nssdb/pkcs11.txt in order to decide whether to open
sql:/etc/pki/nssdb or sql:$HOME/.pki/nssdb would be my main request.
Oh, so you switch between sql:/etc/pki/nssdb and sql:$HOME/.pki/nssdb
depending on whether libnsssysinit.so exists. Hmm I just presumed you
would just always open sql:/etc/pki/nssdb, but I guess you need to work
on other systems as well. If you need that info, I need to find a way to
give it to you, since long term I envision admins having custom versions
for libnsssysinit.so which can fetch things like root trust lists from
central ldap servers or get admin information for some as of yet
undeveloped central admin server.
That sounds ideal to me. In the general case, if a system database has
been set up in /etc/pki/nssdb by the {sysadmin,distribution}, it should
be used. If not, it shouldn't. The default behaviour, if it's *there*,
should be to use it. With an environment variable to override that.
I might just put that on my list then as the next stage.
You may be thinking in a different direction, I would be interested in=20
hearing your ideas.
I'd also pondered allowing a NULL argument as the dbpath to NSS_Init(),
to indicate that the default database should be opened.
I'll keep that in mind, though currently NULL is used when
NSS_Init_NoDB() is used.
- To fix Firefox, Thunderbird and the NSS samples to use it correctly=
=2E
Legacy is what has been holding FF and TB back. It would be relatively=20
easy to get FF or TB to use the sqlite database. It's been a real bear=20
trying to get anyone to work on doing database migration.
Well, if we allow the old database to be used as a third slot, perhaps
we don't *need* to migrate. For per-application private keys, we're
going to need a "private" database in addition to the system-wide and
user-wide ones anyway, right?
Yup, I was actually thinking that myself.
So how about automatically opening not only /etc/pki/nssdb as a separate
slot if that directory has a database in it, but *also* ~/.pki/nssdb. So
firefox et all would just continue to open their legacy database, but
automatically pull in the trusted CAs and any private keys which are
installed in the other databases.
At this point, I think that would be what i would push for for FF.
Sorry, yes. I mean 2 slots in the same module. I've managed to access
*one* or the other of ~/.pki/nssdb and /etc/pki/nssdb by loading the
softokn module via p11-kit, but not both.
You can already do that: NSS_Init("sql:/etc/pki/nssdb")
SECUTIL_OpenUserDB("~/.pki/nssdb");
The spellings and arguments aren't quite right (OpenUserDB actually
takes a module string, which also includes flags an other such things).
NSS is perfectly happy opening multiple databases from the single module
these days. That is how nsssysinit actually works (nssysinit opens
multiple databases under the covers, but the capability is also give to
programs to do on their own).
If we go for the "automatically open the extra slot" option that you
suggested, I think this problem just solves itself.
The infrastructure is already there, it is just a change to nss_Init().
bob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
