Closed ximon18 closed 1 year ago
@ximon18 yes, because the cryptoki crate is dealing with the different architectures in the right way now. Please use the cryptoki crate https://github.com/parallaxsecond/rust-cryptoki. I'm trying to catch up to properly deprecate this crate.
Thanks @mheese for all the great work you put in to the rust-pkcs11
crate, it was very nice to find and use initially and both happy and sad that the move to rust-crpytoki
is needed, but I can very much appreciate it if you don't have the time to maintain it. One thought on that though: having more than one crate that provides PKCS#11 functionality would be better for the health of the Rust ecosystem overall, did you consider calling for volunteers to take over this crate or is it that it has fundamental issues that make it not worth continuing with?
@ximon18 yes, I would like to make the pkcs11
crate name available to either the cryptoki
owners or the RustCrypto org (@tarcieri fyi). I agree with you on the health of the Rust ecosystem. It's always trouble/difficult when things like this happen. IMHO crates in this space should be owned by an org - for multiple reasons.
See:
This issue was observed with a YubiHSM2 Nano connected to a Raspberry Pi 4b which is an ARMv7 (arm7l) architecture platform. The issue occurred both when building the code locally on the Pi and when cross compiling from an x86_64 host.
The error message produced by the
pkcs11
crate was:The issue occurs in the
pkcs11
v0.5.0 Rust crate code whenfunc()
is invoked withinCtx::new()
in the code shown below (link to actual pkcs11 crate code):The same code works fine on x86_64 targets.
pkcs11-tool
had no issues on ARM?7 using the same PKCS#11 library.The
cryptoki
create doesn't appear to have the same problem as switching to that crate resolved the issue for the simple https://github.com/ximon18/keyls tool.