On Thu, 2016-04-07 at 17:13 -0700, Julien Pierre wrote: > > Hm, I thought PK11_ListCerts tried to eliminate duplicates too, which > > is why it has that crappy O(n²) behaviour? Does it *really* return more > > than one of the 'same' certificate? Don't you *still* get a randomly- > > chosen one with unpredictable contents of cert->slot? > > It depends on the argument to PK11_ListCerts .
Hm, I'd missed that useful detail; thanks. I'll experiment with making
Evolution use that, and maybe it'll stop taking so long to enumerate
certs, when I make the entire company Exchange address book (well, the
S/MIME certs therein) available in a PKCS#11 token :)
Our GSoC student has actually come up with a good patch to fix the
O(n²) behaviour, but avoiding the filtering altogether would fix it for
Evolution in even *current* NSS versions, and allow us to enable that
new PKCS#11 token straight away.
> Well, the fact cert may not match "token" isn't necessarily an issue.
> But it's definitely an issue for the key.
Some might argue that it's an obvious bug if
PK11_FindCertsFromNickname("token:...") returns an object such that
cert->slot doesn't match the "token". Why in $DEITY's name is it even
*looking* elsewhere? Does it go off and do its O(n²) enumeration of all
those thousands of certs in my corporate addressbook (for example),
when it was explicitly told to look *elsewhere*?
Regardless of the existing/historical behaviour of the nickname API and
whether we can 'fix' that 'bug', I think we can *certainly* declare
that a new PK11_FindCertsFromUri() function MUST only return objects
such that cert->slot matches the slot which was identified by the URI,
if a slot was specified. Never the same cert from elsewhere.
That basically covers your needs, at least as far as the new API is
concerned, doesn't it? It means that you *can* just use cert->slot to
find the key.
> > And if you find any app shipped in Fedora which *doesn't* support it,
> > please do file a bug.
>
> Since I don't use Fedora, that is unlikely. The Linux we support is
> either RHEL, or OEL which is some RH fork, not quite sure from what
> tree. Dev is mostly done on OEL.
It's coming to RHEL (that being part of Fedora's raison d'être).
So there will (hopefully soon) come a time when it is appropriate to
file RHEL bugs against any tool which accepts certs from a file (via
command line or config file, etc.), and which *doesn't* also accept
PKCS#11 URIs in place of the filename. And which doesn't automatically
load the PKCS#11 tokens listed for it in the system's (and/or user's)
p11-kit configuration.
In fact I think the Red Hat folks have already started cloning some of
the open Fedora bugs, against RHEL.
> > Yeah, but solving it for PKCS#11 is still a very big step forward for
> > usability. On Linux platforms it still gives us *consistent* access to
> > a key either in a hardware token, or in a software token like GNOME-
> > keyring's or even the NSS user database in ~/.pki/nssdb (although
> > there's more work to be done before that's easy).
> >
> Yeah, AFAIK Firefox/Thunderbird still don't use DB in the user's
> directory. Also, they still don't use the sqlite DB.
Yeah. Chrome manages to use sql:$HOME/.pki/nssdb, but unfortunately
still doesn't manage to use sql:/etc/pki/nssdb when nsssysinit.so is
set up. There is basically *nothing* that gets this right. Partly
because there's no clear answer about what is "right".
Evolution basically *greps* /etc/pki/nssdb/pkcs11.txt to see if
nsssysinit.so is enabled there, and uses sql:/etc/pki/nssdb or
sql:$HOME/.pki/nssdb accordingly. Which is just horrid. It basically
gets the right behaviour, but I can't call it the "right thing to do".
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
