libgcrypt and patches again

[Moritz Schulte]

Hello Dirk,

> now again a month went by and I still had no real answer if the code 
> I sent will be applied or not and in case it will not: Why?

first of all, I would like to apologize for not taking part in this
discussion and/or giving appropriate answers.  I will try to do so now.

In general I think what your patch tries to implement is a good thing:
it tries to give the user the option to release resources, which would
be lost otherwise.  But this is hard to implement in Libgcrypt.

One should also keep in mind that what you need to do in respect to the
library resources is probably not something that a majority of users of
Libgcrypt need to do.  Therefore it is a special-need and one COULD
argue that users with such special-needs should rip the library apart
and modify it to their needs.  I think, in this context one should take
the amount of work necessary for modifying the library in such a way
into account.

Now lets become concrete.

The main problem I see here is that this concept of "bringing the
library back to initial state" is not something that has been thought of
so far during the development of Libgcrypt; I am quite sure that it is
actually more complicated than your patch tries to make it look like. :)

Examples:
 * ath: your patch does not bring the ath code back to initial state
(the callbacks would not be reset, etc)
 * secmem: the pool of secure memory is not touched by your patch either.
 * global: debug flags and handlers are not reset

These things could be fixed, yes.  But it would be more work then just
releasing the cipher/md/pubkey modules and the PRNG pool.

Let me think about the integration of your patch in the official
Libgcrypt tree again; it is kind of hairy.

I would like to point your attention to my personal, bleeding-edge
development branch of Libgcrypt; you can check it out through:

svn co svn://cvs.gnupg.org/libgcrypt/branches/LIBGCRYPT-2.0-MO libgcrypt

The tree contains a file named `DESIGN', which explains the main
differences between the official version and this highly-experimental
(!) and entirely unofficial version.

I think what you need is something that my hacked Libgcrypt branch is
supposed to provide.  Of course, this is branch is rather uninteresting
to you in case you simply want this functionality in the official,
soon-to-release branch.  But it might be interesting to you, in case you
want to benefit from the functionality provided by this experimental
branch without seeing the lack of `official support' and/or a stable API
 as a fundamental disadvantage.

In case something related to that code is unclear to you, do not
hesitate to contact me by private mail..

Thanks & happy hacking,
Moritz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : /pipermail/attachments/20051008/5dd3d25a/signature.pgp