Roger Leigh <rle...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fx4a5og6....@windlord.stanford.edu