[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnutls-dev] sign callback for certificate authentication

From: Simon Josefsson
Subject: Re: [gnutls-dev] sign callback for certificate authentication
Date: Sat, 12 May 2007 11:11:38 +0200
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux)

"Alon Bar-Lev" <address@hidden> writes:

> On 5/11/07, Simon Josefsson <address@hidden> wrote:
>> Hi.  I'm making Scute an optional dependency on the branch now.
> OK.
> Just reference me to the place I can sync your modifications.


The announcement (and likely, this message too) didn't make it to the
gnutls-dev list because I recently changed mail server to one that
doesn't have any reverse-dns.  Sigh...

There is a branch in CVS too:

I'm going to set up a Git server for it today.

>> > BTW2: You should add cleanup callback, so that resources can be
>> > released on session end.
>> >
>> This seem to be bloat to me, since it offers no additional
>> functionality.  Applications can cleanup resources when they deinit the
>> particular GnuTLS session that uses the sign callback, can they not?
> We would like to add a layer for application to use...
> So except get certificate/credentials/whatever, the layer should be
> able to free its resources.
> So if we put this at gnutls_certificate_credentials_t we should have
> gnutls_certificate_free_credentials() call callback cleanup so that
> resources may be released.

The application calls gnutls_certificate_free_credential, so it should
be able to call another function at the same place to clean up the
resources that itself allocated.  This seems a better API separation to
me: the application is responsible for deallocating what it allocates,
and GnuTLS deallocate what it has allocated.

> So that user code will look like:
> gnutls_pkcs11_set_certificate (gnutls_certificate_credentials_t *cred, <id>)
> And that's it!

That API could be the same with my approach.

However, I don't think strongly about this, and when I get around to
changing the API to be certificate_credential-specific rather than
session-specific, we'll see how it works out.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]