rust-cryptoki
rust-cryptoki copied to clipboard
parallaxsecond
Improvement to unreleased open_session change?
Regarding the Replace SessionFlags with bool to open session unreleased change I have a concern.
With the new code one ends up with a call like:
ctx.open_session(slot, true)?;
The reader is left wondering what does that true do so I modified my code like so:
const READ_WRITE: bool = true;
let session_handle = ctx.open_session(slot, READ_WRITE)?
However, this issue wouldn't exist if instead an enum were passed in rather than a bool.
Calling @vkkoskie as the original author of the change and who is thus perhaps best placed to comment on it.
Hmm, I don't particularly like the bool, but an enum just for this seems like overkill. What would you think if I just removed the parameter and introduced another method, open_read_write_session (or open_rw_session...)?
I'm fine with either suggestion as they are both more obvious than the current bool. As "rw" is used by the PKCS#11 standard itself as an abbreviation I would be fine with that (e.g. ulMaxRwSessionCount and CKS_RW_PUBLIC_SESSION).
Oh, hi there! I guess you could say I've mostly moved on from contributing here. The work I was doing that motivated my contributions was OBE, and the general frustration with Oasis' silence about licensing stalling #66 was a little more than I was interested in dealing with for what was intended to be a fun side project.
I think this change is mostly orthogonal to my earlier changes. Those were to remove an argument that didn't really make sense. The bool was the closest match for a replacement type for what was left. But it wasn't an opinionated choice.
I'd say among the proposed choices I prefer two functions.
Without advocating one way or another for it, I'll also mention that some APIs will opt for a marker type here. A good example of this pattern is openssl's PKey struct which is generic over empty Private and Public types. A private key can do anything a public key can but the reverse isn't true. Likewise here with RW sessions being able to do anything a RO session can. Just something to consider.
Thanks @vkkoskie, that's a sad story, and very useful interesting API design feedback, thanks!
The generic approach sounds good, but beyond my bandwidth right now :( I can do the "two functions" for now and change it to a generic-based solution for a later release when I get some free time, or I can let someone else take this over?
That someone wouldn't be me as I don't have the bandwidth to take this on at the moment.
Apologies for the delay. I've implemented the "two methods" approach in #101 , will look at maybe implementing the generics approach after I get up to speed following the summer lull.
Let me know if that approach seems sensible to you.