-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for PKCS11_store_certificate generates CKR_ATTRIBUTE_TYPE_INVALID error #519
Conversation
…cs11_store_certificate
https://github.com/OpenSC/libp11/blob/master/src/p11_load.c#L94-L107 The version number could be save once in @mtrojnar comments? |
Thanks for the feedback. First, saving the version at library load is a good idea. The only problem I see in reusing CK_VERSION is that I need to include "pkcs11.h" into "libp11.h", which is probably not a good idea. I'm thinking of creating a different type in "libp11.h" (ex: Version) that mirrors CK_VERSION. @dengert, what do you think? Second, I don't see the issue with adding a new source file. Even if a source file contains trivial content, you don't really want to repeat it in all places it is used. Probably I'm missing something here... |
Adding 9ac6919 was easier than explaining. Avoid converting them to an integer or adding an encapsulation layer. An additional abstraction layer makes the code harder instead of simpler to understand. Simply create and appropriate condition every time it's needed. General advice: Use the KISS principle. |
9ac6919 adds a new type to PKCS11_CTX. Any idea how can this be accessed from a PKCS11_SLOT_private object? |
Good point. It shouldn't go into the public API anyway. Apply c6e69c9 and refer to |
This, hopefully, makes the comparison obvious.
I've used the simpler CK_VERSION instead of struct _CK_VERSION. @mtrojnar, is there a reason you used the latter in PKCS11_SLOT_private? |
Thank you very much for your work. |
No problem. Thank you for merging the changes! |
This fixes the issue #518