Questions about GPGME / GnuPG library
wk at gnupg.org
Thu Dec 7 13:50:39 CET 2000
On Thu, 7 Dec 2000, Olaf Trygve Berglihn wrote:
> something here. I would think that the cleanest way to (re)implement
> gnupg would be to have core functionality accessed by some
> (g)ui-frontend. If you are afraid of dynamically linked libraries, so
Then go and (re)implement it!!!
I have never seen that you contributed any code to GnuPG. Frankly
there are only a very few people working on GnuPG and I am spending
way to much time on all this discussions.
> I consider it a more serious threat that gnupg should be setuid
> root. This is the last thing i want. The next to last is a separate
Tell the Linux developers to fix that, it is not needed for *BSD.
> gnupg-daemon with a rpc-interface. Have you at all considered the
> vulnerabilities i rpc-calls?
Noone has talked about an rpc interface, I just talked about a
daemon which has nothing to do with Remote Procedure Call over a
> Root is root is root is root, i.e. if you can exploit to become root,
> then you could swap the gnupg-binary, the shell-binary or
Sure, but what is your point?
> Sure, protected memory would be fine, but root is root is ...
So you didn't understand for what nonswapable memory is good for.
> great care, or at least are venting opinions that go in the direction
> as to protect programmers from themselves. That provokes me a little.
GnuPG is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
If you feel that you are not capable of doing what you have to do,
go and hire someone to do it for you.
Sorry, I am somewhat upset about all this code-less discussions.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 240 bytes
Desc: not available
Url : /pipermail/attachments/20001207/54b3ec86/attachment.bin
More information about the Gnupg-devel