Re: libgcrypt brain dead?
Roger Leigh <rleigh@codelibre.net> writes:
> The issue here is that upstream don't appear to want to fix it, because
> the change in behaviour could break backward compatibility and
> potentially introduce security exploits into programs relying on this
> side-effect of gcrypt. Any change would require the use of a new
> interface, leaving all existing code still affected.
This is amazingly intrusive behavior for a library initialization function
that's intended to be general-purpose. Aie. At the very least, any
functions that modify global process state like this should be an optional
separate API. This is particularly nasty in a low-level library like
gcrypt.
Can anyone confirm the comment in the bug log that setuid shouldn't even
be required to do what libgcrypt is doing here, namely locking memory so
that it's not swapped to disk?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: