On 6/16/07, Robert Relyea <[EMAIL PROTECTED]> wrote: > > 1. The new version prompt some annoying messages in X... This is > > related to the new pam_prompt addition when HAVE_SECURITY_PAM_EXT_H is > > defined. > pam_prompt should not be blocking, pam_prompt only displays information. > If it's blocking, then there is something wrong with the function (or > the application conversation part).
Oh... and I don't like the blocking pam... But I don't use this. And get the messages. > > 2. I've look at the code. It seems like you added the whole nss into > > the source... I don't understand why... You can use the external > > library files. > > > No, I definately did not add all of NSS, it used NSS from a shared > library. I'm not sure what code you think is NSS. What is there is the > previous pam_pkcs11 api to the common directory, abstracted out to allow > it to be bilingual. So what are these files? src/common/SECerrs.h src/common/SSLerrs.h src/common/NSPRerrs.h src/common/rsaref/PKCS11_README src/common/rsaref/pkcs11.h src/common/rsaref/Makefile.am src/common/rsaref/pkcs11t.h src/common/rsaref/pkcs11f.h > > 3. Regarding the pkcs11-helper... > > > > The problem is that NSS addition is somewhat strange... I expected > > that it will replace OpenSSL entirely... So that you can run current > > PKCS#11 implementation with NSS... This requires the abstraction > > library for certificate and digest will be implemented as standalone, > > and use this throughout the whole package. > > > I'm not sure if you are looking at the same code. Can you give examples > of where there isn't an abstraction? OpenSSL is replaces entirely. All > the crypto library specific calls live in src/common. I did not change > the openSSL names for things like certs, but provided typedef > definitions to NSS CERTCertificates. 1. You did not fix the pkcs11_lib in the part NSS is not used. It still uses OpenSSL. 2. The fact that you did not change the OpenSSL names is also *_CONFUSING_*, the result is dirty unreadable code. > > I have one more problem regarding the slot number... For a strange > > reason the pam_pkcs11 bothers the user with numeric slot/string > > number... What happens if there are several providers? Readers? etc... > > For this reason I abstract it in pkcs11-helper... I wished to removed > > this one from pam_pkcs11 so that all available certificate objects are > > validated against the mappers. > > > This was the original pam_pkcs11 semantic. I basically mapped around it > as well. NSS prefers a higher level abstraction as well. I didn't want > to break existing configurations, so maintained the funky 'slot number > index to the selected module' from the previous pam_pkcs11. For NSS we > usually don't the slot or the module. The output of 'select slot' is a > crypto specific value, so you can use any abstraction you already have > (NSS uses regular slot IDs, and keeps the module in the pam_pkcs11 > context handle). True. But as I said, just introducing a new crypto implementation and keep the legacy complex just make things worse. If you add multi provider you need to get rid of slots... And this was one of the reason you said you added NSS. > The context handle is now completely opaque, so you are free to store > anything you need for pkcs11_helper there. Yes. This was done correctly, but the pkcs11_lib is not used by the whole package... The standalone utilities implement stuff of their own. > > I regret to say, I don't have the time right now. I think that before > > the NSS additions, I could have cleaned up the code faster... > > > If you have time in the future, I would be happy to help you identify > where the abstraction layer is. If we need to beef it up to make it > easier for pkcs#11 helper, then I would be willing to update the NSS > side for that. I think we should first make this program easier to maintain, then see if we can improve it. 1. If people wish to use NSS or OpenSSL there should be a clear abstraction for this. 2. Use the pkcs11_lib in all package modules, including tools. 3. If we wish to use multi-provider we should get rid of the slot stuff, and enumerate available objects, check each against mapper, and only if public certificate matches we authenticate to the card. Currently it first login then look for public. 4. Support protected authentication (biometric). Best Regards, Alon Bar-Lev. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
