search

p11-glue / p11-kit

Provides a way to load and enumerate PKCS#11 modules.
https://p11-glue.github.io/p11-glue/p11-kit.html
Other
150 stars 92 forks source link

Mark P11KitIter interface stable #589

Open ueno opened 11 months ago

ueno commented 11 months ago

Currently the P11KitIter interface is only exposed when P11_KIT_FUTURE_UNSTABLE_API is defined. Since the interface has been there for many years, it might make sense to declare it to be stable.

A couple of things to consider before doing so:

ZoltanFridrich commented 11 months ago

P11_KIT_ITER_WITHOUT_OBJECTS was added as a compatibility measure in https://github.com/p11-glue/p11-kit/commit/3d54011b0d0bf1b31fbab8d7025b7201722d61c3, as P11KitIter previously only supported enumerating objects. Maybe we could make it no-op

Why would we make it no-op? I thought that when I specify something like WITH_TOKENS it will enumerate both objects and tokens. What if I dont want to enumerate the objects but only the tokens? Unless I imagined this behavior and actually it works differently.

There is a recent behavior change (not part of any release yet) regarding the timing to stop iteration when P11_KIT_ITER_WITH_TOKENS is specified; previously we stopped before opening a session, now we stop after that. If we consider this is an ABI break, we might want to bump SONAME

Is it an ABI break though? The session is opened automatically now but that shouldnt break anything. I believe that anyone who uses such iterator and manually opens the session, their program should still work.

ueno commented 11 months ago

Why would we make it no-op? I thought that when I specify something like WITH_TOKENS it will enumerate both objects and tokens. What if I dont want to enumerate the objects but only the tokens? Unless I imagined this behavior and actually it works differently.

If we don't care about backward compatibility, we could have WITH_OBJECTS instead of WITHOUT_OBJECTS, which would be more intuitive.

Is it an ABI break though? The session is opened automatically now but that shouldnt break anything. I believe that anyone who uses such iterator and manually opens the session, their program should still work.

What if an existing program is written in a way it manually opens a session when stopped at a token and it doesn't support parallel sessions (i.e., CKR_SESSION_PARALLEL_NOT_SUPPORTED will be returned).

ZoltanFridrich commented 11 months ago

If we don't care about backward compatibility, we could have WITH_OBJECTS instead of WITHOUT_OBJECTS, which would be more intuitive.

But WITH_OBJECTS is the default behavior. I see nothing wrong having WITHOUT_OBJECTS. And introducing WITH_OBJECTS would definitely break majority of code using p11_iter. If we would like to do this (which I dont see the reason to) I could do it in a 0.26.0 maybe.

What if an existing program is written in a way it manually opens a session when stopped at a token and it doesn't support parallel sessions (i.e., CKR_SESSION_PARALLEL_NOT_SUPPORTED will be returned).

Alright, it breaks the ABI then.

ueno commented 11 months ago

Well, I'm talking about using this opportunity (i.e., removing P11_KIT_FUTURE_UNSTABLE_API guard) to introduce backward incompatible changes. Currently it's user's responsibility to define the macro to access the unstable API. Once we remove P11_KIT_FUTURE_UNSTABLE_API it would become our responsibility to maintain the compatibility.

ueno commented 11 months ago

So my suggestion here is like this: for 0.25.1, include a compatibility measure (like #590); in the future, when we bump the SONAME, remove it and WITHOUT_OBJECTS altogether.