bhearsum
commented
2 weeks ago @jmhodges (or anyone else) - if you have some ideas about how we could test this usefully I'd love to hear them. The only way I could come up with is to dependency inject crypto11 into MakeKey such that we can provide a fake version of, eg: GenerateECDSAKeyPairOnSlot. This would end up trickling up the call stack to Configuration.MakeKey as well, which is a bit annoying. (And also we'd have to make a fake version of pkcs11.Ctx, but I think that is quite trivial to create and inject.) My instincts for testing all come from Python, so I may be missing some other options available to us here.
The main driver behind this is to enable us to add a
GCPHSMwith its own MakeKey implementation to avoid cluttering upConfiguration.MakeKeyfurther. While I was doing this, I moved the other HSM andcrypto11`` related things elsewhere as well. Notably, two things are still present insigner.Configurationthat would be part of asigner.HSM` implementation in an ideal world:Configuration.GetKeysConfiguration.CheckHSMConnectionentirelyBoth of these things depend on
Configuration.GetPrivateKeywhich needs alabelof a key to fetch. I don't think it's appropriate to move that label to theHSMinterface (because it would tie an instance to a single key). I couldn't find a way to adjust the usage of these methods that didn't end up making things messier, or involved refactoring other things, so I'm punting on it for now.