Accept TryFrom<CK_MECHANISM_TYPE> for vendor mechanisms

[jwnrt]

Hi, we've been using a similar patch downstream in OpenTitan so I wanted to upstream this change.

[hug-dev]

Hello!

Thanks for the patch! We currently have new_vendor_defined to create vendor defined mechanism types. Could that be used in your use case?

[jwnrt]

Yes, you're right, we can have this conditional on our side and call new_vendor_defined.

This patch would mostly be ergonomics and would allow dependents to avoid taking a dependency on cryptoki-sys (in order to access CKM_VENDOR_DEFINED). It won't block us if you don't accept the patch :-)

[hug-dev]

I see! I was afraid this would silently allow a lot of mechanisms as vendor defined compared with the function call which is a bit more explicit. But I guess this is mostly ergonomics and allowed by the standard so fine with me!

Note that I don't think you always need to import CKM_VENDOR_DEFINED if you already know the CKM value of your vendor mechanisms:

fn main() {
    let toto = cryptoki::mechanism::MechanismType::new_vendor_defined(0x80000406).unwrap();
    println!("Hello, world {} !", toto);
}

[Jakuje]

Any chance to create some simple test case with vendor specific mechanism? Do we know about some implemented in the existing software tokens? Or should we just make some sanity test with examples how these should be handled? I find this area still quite under-documented and untested.

[hug-dev]

Agree about adding tests but I think this could also be done in another PR, since the we already allow this functionality via other methods!

[wiktor-k]

Agree about adding tests but I think this could also be done in another PR, since the we already allow this functionality via other methods!

Thinking about this, yeah, we have a bad habit of withholding many good contributions over tiny things by accident 😅

I agree that we can merge this as is.