p11-kit (current master) somehow fails token operations (???) #501
Comments
|
Two other tests would be to use p11-kit but with only one module: |
|
Going through this and latchset/pkcs11-provider#234, I still fail to see why this is relevant to p11-kit-proxy, as it simply passes through the calls to the underlying modules, without any modification except slot mappings. The only thing I can suggest is to try collecting logs with either |
I hear you. However, the summary of situation is this:
I had a few runs with Update
With only one module - it seems to work. |
I might have missed, but does this work also for YubiHSM2? latchset/pkcs11-provider#234 (comment) only mentions OpenSC so I can't figure this is really caused by having multiple tokens or sorely by the YubiHSM2 module. |
It does, with OpenSSL-3.2.0-dev: Seg-fault is because somehow provider or p11-kit get into an infinite loop on CloseSession: How can I build p11-kit in debugging mode, so symbols and such are preserved? Apparently, With OpenSSL-3.1.0, even when I have only one module YubiHSM, I'm getting an error from OpenSSL: With only YKCS11 module present, it works: Likewise, with both OpenSC and YKCS11 modules present: UpdateWhen I added "openssl" = OpenSSL-3.1.0, "openssl3" = OpenSSL-3.2.0-dev. Update 2Replacing |
With Meson, you could use
This is runtime generated code, so might not even have debugging information. |
In some runs I get infinite loop there ( |
|
Sounds like libffi comes from: https://github.com/libffi/libffi |
|
If building autoconfig check if configure has any options for debugging. If not try CFLAGS=-g LDFLAGS=-g |
|
Best I can tell on MacOS you are mixing .dylib and .so files so libffi is needed. Is there anyway to simplify you test environment? Using code still under development when building from any github master; .dylib vs .so; multiple build systems: autoconfig, Clang, Mason; multiple compilers: Clang,gcc; multiple arch: aarch64, x86_64 |
I doubt it.
Well, that's OpenSSL-3.2.0-dev that works where the released OpenSSL-3.1.0 doesn't.
I don't think this is a problem. MacOS seems to be handling that quit nicely. Not to mention that if OpenSC insists on producing .so, and other packages like p11-kit produce .dylib - what would you expect me to do about it?
Again, if authors of some packages insist on "non-traditional" build systems - what would you expect me to do about it? Rewrite those packages myself for something more mature, like make/autoconf?
That's not a hindrance, but a benefit. E.g., I can compare how the same code behaves (works vs. doesn't work) on x86_64 (doesn't work) vs. aarch64 (works, to my pleasant surprise). GCC did not seem to make an appreciable/positive difference, so I'm sticking with Clang. Macports Clang seems to have bugs different from those of Apple Clang... But again, what would you expect me to do here? |
Try running the failing test in a linux system? |
I don't have a Linux system anymore. On MacOS:
|
|
I never had a MacOS system. And don't have a YubiHSM 2. For wat ever its worth... The build dir is at the same level as the source. |
MacOS Ventura 13.3.1, Macports-installed OpenSSL-3.1.0, pkcs11-provider (main), OpenSC (master, with commit 1d5c81e85baaa8 reverted).
In short, when
pkcs11-providerfor OpenSSL is configured to usep11-kit-proxy.dylibto select the module to load - operations fail. When I force the specific driver, like/Library/OpenSC/lib/opensc-pkcs11.soor/usr/local/lib/libykcs11.dylib(in other words, takep11-kitout of the picture) - operations succeed.openssl.cnfconfig:Failures:
Successes:
@simo5 It looks like the problem manifests itself when
pkcs11-provideris used, because withlibp11engine it seems to work:Also, see latchset/pkcs11-provider#234
The text was updated successfully, but these errors were encountered: