On Mon, 2014-12-08 at 16:44 +0000, Martinsson Patrik wrote: > Well,not really, it turns out that the gnome-settings-daemon loads the > opensc-module directly from /etc/pki/nssdb. So if I don't import the > opensc-module in there, gnome-settings-daemon wont recognize > inserts/removals. I choosed to import the p11-kit-proxy instead of > opensc-module directly because then I got the 'system trust' as well > automatically. If I'm not missing something here of course (which very > well might be the case since this is *a hassle*).
Anything needing system trust will be loading libnssckbi.so explicitly, do doesn't need you to add it to any secmod.db/pkcs11.txt. > Ok, that may be the case. I was under the impression though that GKR had > sat its password to my PIN (changing the PIN code will actually result > in a dialog where it's asking me for my password at login time, since it > can't unlock my GKR). Hm, OK. Maybe it is. I can see how that would work with the way it 'steals' the password from the PAM stack. I would imagine that it's using the same password for *all* its storage, rather than different passwords. So perhaps just ignore my suggestion; it's probably not that. > > > This is theoretically fixable — if you have the smartcard present for > > login, GKR ought to be able to use *its* key for decrypting the storage. > > > (When authenticating with pam_winbind against Active Directory we have > > similar issues for which we want to use the BackupKey Remote Protocol to > > provide a key: https://bugzilla.samba.org/show_bug.cgi?id=9979 ) > > > > > And in my casse, *both* evolution and firefox asks me for, > > > - First Password to my "Gnome2 Key Storage", > > > - When entered, next dialog sows up, "Enter Password to unlock the > > > certificate/Key storage" (and the option to automatically unlock it > > > whenever I'm logged in" > > > - When entered, next dialog pops up, "Enter the password for secret > > > store" Screw it, just delete /usr/share/p11-kit/modules/gnome-keyring.module You didn't actually want to *use* it for PKCS#11 anyway. > Maybe the "best thing" thing here would be to add opensc-pkcs11 and > p11-kit-trust to /etc/pki/nssdb. Even though as you say, it shouldn't be > necessary, but I would like to state otherwise (since > gnome-settings-daemon doesn't work correctly without the opensc module > in there). But, that's probably because of, > 1 ) a bug in gnome-settings-daemon how the initialization of nssdb is > done, > 2 ) me missing something about how gnome-settings-daemon initializes > "smartcard-stuff" What exactly is the issue with gnome-settings-daemon? What's it supposed to do with the smartcard? I can't see *any* reference to /etc/pki/nssdb in its source code at first glance... We should probably file a bug for that. If OpenSC is there in the system's p11-kit configuration, it should be seen by gnome-settings-daemon. I know that NSS applications are often second-class citizens in this respect but a GNOME application *needs* to do the right thing even if it has to jump through extra hoops (or get ported to GnuTLS) in order to do so. I still maintain that the path to sanity involves killing /etc/pki/nssdb entirely, and then you can look at applying *correct* fixes to whatever's still not behaving correctly. -- 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
