libgcrypt and patches again

[Dirk Stoecker]

Hello,

> 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.

Not as hard as you think. Ok, it would be much easier to do so, when done 
from the first piece of code. Nevertheless, usually every part of 
initialization stuff only depends one nearly singular variables. So it is 
not necessary to care for everything, but only relase everything and reset 
these singular pieces (usually a "bool initialized").

The stuff I implemented works for the methods I used the library for (and 
some more, as I tried to care for other possible fields as well). If 
it is in the main tree and there are problems in other areas they will 
soon be bug-reported and fixed. Also a short code review from the 
developers could reduce the bug-reporting stage a lot.

I would also help with this, but not as long as I see no step is done in 
this direction.

I'm doing programming for more than 15 years including more than 4 totally 
different operating systems and memory models, some processor types and 
so on. So I have a bit of experience in these fields. I sometimes heard 
the "This does not work" or "This is hard to do" (and also said this 
sometimes myself), but usually it is not that complicated as one may 
think.

> 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.

Usually it is something like:
- Release everything
- Reset import global variables.

I think this is easy and straightforward (Thought it would be easier 
without any globals :-).

BTW: It is also a necessary in case someone wants the software to be 
ported to different operating systems. Not every operating system has an 
memory garbage collection.

> 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,

That's the problem. I need a certain functionality and libgcrypt provides 
it. But I also need a clean system and libgcrypt does not provide it. For 
me there are two possibilities. Either I get the cleanup implemented in 
libgcrypt or I need to switch to another solution (possibly including a 
private reduced link-library based on libgcrypt). A experimental 
development branch does not help. I can spend some work on the project, 
but not too much, as it is not a major part of the things I do.

Ciao
-- 
 ____  _ _  ____  _ _    _ _  ____
|    |  |  |    |  | \  / |  |    | the cool Gremlin from Bischofswerda
|  __   |   ____|  |  \/  |  |    | WWW: http://www.dstoecker.de/
|    |  |  |       |      |  |    | PGP key available on www page.
|____| _|_ |____| _|_    _|_ |____| I hope AMIGA never stops making fun!