-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Add ability to specify initialize flags for pkcs11 provider #158
base: master
Are you sure you want to change the base?
Conversation
New pkcs11-helper interface allows to setup pkcs11 provider via properties: alonbl/pkcs11-helper@b78d21c Also pkcs11-helper added ability to setup init args for pkcs11 provider: alonbl/pkcs11-helper@133f893 Signed-off-by: Petr Mikhalicin <mkh199740@mail.ru>
@dsommers what's our take on this? it's a new pkcs11-helper interface (I am not sure how we'd deal with backwards compatibility though). Maybe we don't want to expand pkcs11 in this direction? |
I wonder which PKCS#11 providers this has been tested against. I'm also lacking some pointers to where Generally speaking, I think this patch makes somewhat sense. But the pkcs11-helper code isn't exactly too verbose in the documentation, and the way to little documentation in this patch doesn't make it too easy to understand which use cases this new option are needed. It might also help to split it up in a few smaller chunks doing individual changes on its own. This patch re-implements the "add provider" call and adds a new option; this should at least be split up into separate commits. More documentation is definitely needed (there are no man page changes) and the changes in I know the prior code isn't documented well either, but since the PKCS#11 stuff is quite magical for many people - lets try to help the understanding when we change these code paths. That will also ease the code review next round. And it will help other contributors digging into these code paths in 1-2 or 10 years from now. |
Another detail here is striking me - and this is not something this patch should fix(!) There seems to be a strict relation between the It would probably be a good idea to rethink the whole PKCS#11 options, and move it towards a similar direction to what we're doing with So instead of:
you could have:
It's a more verbose approach, but it ties each setting to each provider more clearly. For example, if the first example you set This should also move all the various pkcs11 variables and struct members to be re-implemented using a "pkcs11 config struct" with one element per configured pkcs11 provider. This would also make the overall PKCS#11 code easier, and the It seems the whole PKCS#11 implementation is getting ready for a solid clean-up as well ... |
The middle part of this change (use calls to register/set-provider-property/initialize) is now part of master/2.6 in a way that does not break when compiled with with |
@dsommers if the code for the config restructure is not too complex, it might be nice use named entities, like
You could still opt to name your providers Limiting identifiers to numeric values might also lead to confusion what to expect when commenting out (disable) all entries for provider |
New pkcs11-helper interface allows to setup pkcs11 provider via
properties: alonbl/pkcs11-helper@b78d21c
Also pkcs11-helper added ability to setup init args for pkcs11 provider:
alonbl/pkcs11-helper@133f893
Thank you for your contribution
You are welcome to open PR, but they are used for discussion only. All
patches must eventually go to the openvpn-devel mailing list for review:
Please send your patch using git-send-email. For example to send your latest commit to the list:
For details, see these Wiki articles: