Closed Direktor799 closed 1 month ago
Thank you!! As a prerequisite to this PR maybe we should agree and go on with https://github.com/parallaxsecond/rust-cryptoki/pull/156 so that we use v3.0
and then merge your changes based on that?
Thank you!! As a prerequisite to this PR maybe we should agree and go on with #156 so that we use
v3.0
and then merge your changes based on that?
That's a good idea. This PR unnecessarily couples the HKDF and the 3.0 change that maybe should be there in the first place. Does #156 also solve the "unofficial OASIS header" issue reported at https://github.com/parallaxsecond/rust-cryptoki/pull/66? If so maybe we need some acks from other maintainers that the licensing looks good in #156 and then rebase this on top of master (when #156 is done).
@hug-dev would you ask in #parsec
if everyone is OK with this approach? :pray:
Thank you!! As a prerequisite to this PR maybe we should agree and go on with #156 so that we use
v3.0
and then merge your changes based on that?
That will be nice, thank you!
@hug-dev would you ask in #parsec if everyone is OK with this approach? 🙏
Yes! Also pinged on the related PR to use another free source of headers.
@Direktor799 You might need to rebase!
do we use to put 2021 everywhere or the year the file is added instead?
I think the date of the file addition was used in previous instances. The entire copyright years issues is a minefield: https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/
In my other project we've migrated to reuse which automatically checks licensing info. Previously we used headers, just like here, but then we aggregated everything in one file and it's good. (I guess this is a question if we want to improve copyright headers in the long run and if so how).
Add HKDF mechanisms to
cryptoki
andcryptoki-sys
. The mechanisms were defined in PKCS#11 v3.0.I found that SoftHSM doesn't support such mechanisms so I couldn't write any unit test. But I did run some
CKM_HKDF_DERIVE
tests against our own HSM and it works.