libgcrypt and patches again
misc at dstoecker.de
Sun Oct 9 18:45:15 CEST 2005
> 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
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
> * 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.
____ _ _ ____ _ _ _ _ ____
| | | | | | \ / | | | the cool Gremlin from Bischofswerda
| __ | ____| | \/ | | | WWW: http://www.dstoecker.de/
| | | | | | | | PGP key available on www page.
|____| _|_ |____| _|_ _|_ |____| I hope AMIGA never stops making fun!
More information about the Gcrypt-devel