Need non-writable --homedir
jw at raven.inka.de
Wed Sep 13 21:55:20 CEST 2006
On Tue, Sep 12, 2006 at 02:10:57PM -0500, Robert J. Hansen wrote:
> I apologize if this email seems snarky.
Robert, please get a beer and calm down.
> However, I'm getting tired of repeating the same answers over and over
If you find yourself repeating the same answers, chances are that you
keep answering the wrong questions. (just kidding :)
> Josef Wolf wrote:
> >>> Don't most unices have /dev/random nowadays? I never planned to
> >>> run this thing on a windows box :)
> >> GnuPG has been ported to many platforms. BeOS, OpenVMS, Win32, and
> >> many more that have no /dev/random.
> > I know. And this is good. But I am asking as a gnupg user, not as a
> > developer.
> Your question is predicated on a "well, I'm on UNIX with a /dev/random,
> so why doesn't GnuPG just use /dev/random for everything?"
To be precise, I asked "I wondered why /dev/random is not used" exactly
_once_ after your explanation why random_seed is important. From context
it should be clear that this was meant as a _possible_ alternative to the
random_seed method. I never said that it should be used for everything.
After that, I kept asking _whether_ it will be used. Notice the semantic
Then you said that data from /dev/random has bad quality. For me, this
was Bad News, because I always assumed that /dev/random is the highest
quality average people (those who can't afford radioisotope, like me)
can get. From that, a second discussion, entirely unrelated to gnupg,
evolved. Please don't confuse the two independent topics.
BTW: _You_ asked me to tell you what platform I use before you can answer
the question. You should not be very surprised that I start getting
platform specific after that.
> > I know that my application will run only on unix-like systems.
> Ah, yes, UNIX Programmer's Disease. I suggest you look into getting cured.
I don't force you to use my application, so what exactly is your problem
here? I don't know whether windows have something like sudo, or how to
properly drop privileges, and many other things. So why should I bother
to port it to a system I don't know? Should anybody be interested to
run it on a system I don't use or know, then it's up to him to port it
on whatever system he likes. This is a pretty common idiom in the
open-source world: if something don't fit your needs, you are free to
fix it yourself.
I don't ask you to port your applications to any of the wired systems
I use. And I don't say you are suffering from any desease for your
decision on that.
BTW: Actually, I _do_ programming for non-unix (embedded systems mostly),
so portability is usually a high priority for me.
> If you care only about UNIX systems, that's your lookout.
> It's not the lookout of the GnuPG developers.
I never questioned _that_...
> >> GnuPG may fail well in that situation. But will _all_ your
> >> applications fail well in that situation? Especially ones which
> >> can't afford to block for minutes until the /dev/random pool
> >> replenishes?
> > Well, that's why I asked how many random data gnupg consumes when
> > encrypting.
> Please re-read my answer.
> GnuPG _doesn't_ diminish /dev/random when encrypting, because it uses
> its own pseudorandom number generator, which is why it uses random_seed.
Still no answer to what happens when random_seed is to be avoided. From
the beginning of the thread I have made clear that I want to avoid the
random_seed file and you keep explaining me what the intent of this file
> > AFAIK, having random_seed be accessible to unauthorized people is not
> > acceptable. Thus I have no choice
> You always have a choice. I'd suggest rearchitecting your solution.
Oh, you already mentioned that. And I responded that I'm open for
> Your current solution does not strike me as particularly sound.
You keep talking in riddles. What exaclty is wrong with my current
solution? I will be happy to fix it if you can tell me what's wrong.
> > I never had a radioisotope RNG and I will probably never have such a
> > beast. On an average system /dev/random collects entropy from
> > keystrokes, mouse events, network traffic and such things.
> Please consider this very carefully:
> _GnuPG has absolutely no way of knowing the internals of /dev/random._
> None. Nada. Zilch. Zero. GnuPG doesn't know, doesn't care.
> Also, please consider this very carefully, too:
> _There is no such thing as an 'average' GnuPG system._
> What's an average GnuPG system? Is it BeOS? Win32? Debian GNU/Linux?
> Fedora? FreeBSD? OS X?
Hey, why have you removed the quotes? From the context, it should
be clear that the topic of this part of the mail was the quality
of randomness sources and had nothing to do with gnupg. Is it by
intent that you misunderstand me?
> >> GnuPG has no control over how each UNIX handles /dev/random. If
> >> GnuPG has no control over that, then GnuPG isn't going to rely on
> >> that.
> > On my system gnupg relies on /dev/random when keys are generated.
> Because it has no other choice. It needs highest-quality random values,
> and it can block indefinitely until those values are available. (In
> fact, it warns you it might block for a while.)
Ough... Two mails ago you stated that the quality of /dev/random is poor
(or at least not guaranteed) and now you turn 180 degrees and tell it's
highest-quality. You keep confusing me..
> > I have no doubts about this. But I still don't have any clue what
> > consequences --no-random-seed-file has. Will encryption process
> > block? Will the random data be of bad quality?
> While I am certain answers exist to be found, I am not certain the
> answers will do you much good.
Well, David gave me the answer. Now you made me wondering what might
be wrong with his answer... Would you please give a hint?
More information about the Gnupg-users