On Thu, Dec 07, 2006 at 09:06:41PM +0200, Alon Bar-Lev wrote: > On 12/7/06, Joe Orton <[EMAIL PROTECTED]> wrote: > >> >The point is that there's nothing *neon* can do with this callback. It > >> >must always be entirely specific to the application. Say that the call > >> >to your library is: > >> > >> Yes it can. > > > >Could you give a code example to help illustrate your point here? > > I tried to... :)
I'm not trying to be obtuse here, but maybe I am missing something fundamental. In the example I gave, specifically what would neon do for the token prompt callback other than pass through the callback straight to the pkcs11h_* API? You say the KDE QCA code can be used as a library. So in that case: what happens when both QCA code and some other pkcs11h_*-using code are linked into the same process, and both register a token prompt hook? There can only be one callback registered for the process so it can't be handled by both the QCA code and any other user, right? > >neon certanly supports the mode of operation where the application > >selects an appropriate client cert in a callback based on the set of > >acceptable CA DNs presented by the server: see ne_ssl_provide_clicert(). ... > But if you work with multipile sessions you get prompt for passphrase > once for each session. You can call ne_ssl_set_clicert() on multiple sessions for a single once-decrypted client cert object safely; the cert is duplicated internally hence why the API takes a "const" argument. Regards, joe _______________________________________________ neon mailing list [email protected] http://mailman.webdav.org/mailman/listinfo/neon
