Currently our PKCS11 provider is forcibly kept single-threaded - all crypto or key management operations have to take a lock that ensures only one is executing at any time. This is because of an issue probably found in SoftHSM2. We raised a point with them about it and got a partial fix, but even with that fix there are still failures.
The problem is that when run in a multi-threaded way, without locking, generate and import key operations start failing (with CKR_GENERAL_ERROR or CKR_TEMPLATE_INCONSISTENT). Given that this happens pretty consistently, the CI would've failed so we made the decision to simply lock down the provider. This comes at the cost of performance of said provider, but we're not that worried about that for now.
On the SoftHSM side softhsm/SoftHSMv2#576 was raised to fix this and I've tested with the initial commits. The issue was still happening, but much less frequently. I've yet to test with the latest commit as well - hopefully that fixes the issue and we can then remove the locking.
Currently our PKCS11 provider is forcibly kept single-threaded - all crypto or key management operations have to take a lock that ensures only one is executing at any time. This is because of an issue probably found in SoftHSM2. We raised a point with them about it and got a partial fix, but even with that fix there are still failures.
The problem is that when run in a multi-threaded way, without locking, generate and import key operations start failing (with
CKR_GENERAL_ERRORorCKR_TEMPLATE_INCONSISTENT). Given that this happens pretty consistently, the CI would've failed so we made the decision to simply lock down the provider. This comes at the cost of performance of said provider, but we're not that worried about that for now.On the SoftHSM side softhsm/SoftHSMv2#576 was raised to fix this and I've tested with the initial commits. The issue was still happening, but much less frequently. I've yet to test with the latest commit as well - hopefully that fixes the issue and we can then remove the locking.