Add PKCS#11 3.2 bindings + plug them into the cryptoki

[Jakuje]

The PKCS#11 3.2 headers are available (pre-release though, but final version should be out in coming weeks):

https://github.com/latchset/pkcs11-headers/tree/main/public-domain/3.2-prerelease

This pulls the new headers, regenerates bindings and adjusts the initialization so they can be used.

So far opened only as a draft as the specs is not published yet, but planning to add some more functions using kryoptic, that will verify the whole process works.

I took also the chance to update bindgen to 0.71.1 once we generate new binding version

[Jakuje]

Oh, lovely! The CI does not like the generated binding as it is too complex.

error: very complex type used. Consider factoring parts into `type` definitions
    --> /home/runner/work/rust-cryptoki/rust-cryptoki/cryptoki-sys/src/bindings/x86_64-unknown-linux-gnu.rs:6801:35
     |
6801 |       pub C_UnwrapKeyAuthenticated: Result<
     |  ___________________________________^
6802 | |         unsafe extern "C" fn(
6803 | |             arg1: CK_SESSION_HANDLE,
6804 | |             arg2: *mut CK_MECHANISM,
...    |
6814 | |         ::libloading::Error,
6815 | |     >,
     | |_____^
     |

Who would say it for a function with 10 arguments:

    pub C_UnwrapKeyAuthenticated: Result<
        unsafe extern "C" fn(
            arg1: CK_SESSION_HANDLE,
            arg2: *mut CK_MECHANISM,
            arg3: CK_OBJECT_HANDLE,
            arg4: *mut CK_BYTE,
            arg5: CK_ULONG,
            arg6: *mut CK_ATTRIBUTE,
            arg7: CK_ULONG,
            arg8: *mut CK_BYTE,
            arg9: CK_ULONG,
            arg10: *mut CK_OBJECT_HANDLE,
        ) -> CK_RV,
        ::libloading::Error,
    >,  

Is this something we should fix in the generated bindings or open an issue for the bindgen? Not sure if this is a new issue with the new bindgen, but more likely the issue of the new PKCS#11 API having that insane number of arguments ....

[wiktor-k]

Hmm fortunately this is just a clippy issue. I guess suppressing it somewhere would be an okayish workaround. (maybe in lib.rs of -sys?)

I'd still report it to bindgen. This may improve their code generation or at least make them consider adding the lint suppression in the generated code.

[Jakuje]

Thanks for the pointer! I see the lib.rs has already some more warnings ignored. I am not sure if there is some way how to improve the code generation to avoid this. I can think of using some temporary named type for the function, but I think it just moves the problem one more function argument away.

I think this is inherent issue of the PKCS#11 specification, introducing this complex functions.

[wiktor-k]

I am not sure if there is some way how to improve the code generation to avoid this.

FWIW I didn't mean that. Slapping the lint suppression there is sufficient enough for me.