RFE: Use p11_kit_modules_load() directly #117
Labels
Comments
|
Using |
|
Also: |
|
Did you definitely fix Yubico/yubico-piv-tool#91 before trying this? That would explain a long list of 'The specified slot ID is not valid' errors, and would also explain not finding a private key — because in Yubico/yubico-piv-tool#94 (comment) you showed that due to that same YKCS11 bug, the "real" slot number was showing up three times along with all those bogus ones. So it looks like there are three tokens matching your URI with |
|
FYI: p11-kit-proxy.so was not being built on OS X due to a Makefile bug that has been reported at https://bugs.freedesktop.org/show_bug.cgi?id=98022 and fixed today. But you don't really need the proxy because it's just a symlink to |
I did not - but while fixing it improved the long list of wrong slots, it did not help with the main problem: |
|
Hmm... I recompiled and it (including your ykcs11 fix) appeared to fix the problem: The problem appeared to be in |
|
OK, it should have picked that up automatically from the pkg-config for p11-kit, by running Btw, stop using |
|
OK, changing to Also: But after the latest upgrade of the Note the above trying to send 270 bytes to sign instead of 256. Reported this bug: Yubico/yubico-piv-tool#98, which includes the complete debugging output. |
|
Do I understand correctly that it is a YKCS11 issue? |
|
is this the same as your OpenSSL isue form January? openssl/openssl#543 |
|
The inability to correctly compute an RSA signature (that I complained about here) was a YKCS11 issue Yubico/yubico-piv-tool#98 that has been reported and resolved there.
No, some symptoms were similar, but the cause was a bug in YKCS11 (see above). But the main issue here that @dwmw2 reported (and that I almost hijacked :) is about loading PKCS311 modules directly rather than via To this I can add that the OS X build issue was reported to So it would be nice if |
I prefer cheaper tricks (and less dependencies) as long as they do the job. @dwmw2 is a bit biased here due to his previous work in companies that build really huge and complex systems. Smaller integrators really do appreciate simplicity. |
|
:-) I can live with the current way of loading modules. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are a couple of discussions of this in places where they're a bit off-topic. See Yubico/yubico-piv-tool#94 (comment) and Homebrew/homebrew-core#5434 (comment)
The "easy" way to integrate a PKCS#11-capable application and make it use the modules configured by p11-kit is to use
p11-kit-proxy.so. That just loads all the configured modules internally, then proxies for them, making their slots appear as its own slots.However, there are a couple of problems with this. One is that it requires the use of
libffito build trampolines for the module entry points, which can be problematicThe other is that
p11-kit-proxy.sodoesn't seem to build on OSX for other reasons, as noted by @martinpaljak in https://lists.freedesktop.org/archives/p11-glue/2014-December/000550.htmlIt might be better for the ENGINE just to use p11_kit_modules_load() directly in the default case, instead of the cheaper trick of using
p11-kit-proxy.soas its default module, which it does at the moment.Using
libp11-kitdirectly has the added bonus that we could ditch our own incomplete RFC7512 parsing. And it's only for the ENGINE, not forlibp11. And obviously where the user does explicitly specify a single module that would still override the default behaviour, just as it does now.Thoughts?
The text was updated successfully, but these errors were encountered: