Bug 903 - grid-proxy-init crashes ERROR:Couldn't create proxy certificate
: grid-proxy-init crashes ERROR:Couldn't create proxy certificate
Status: RESOLVED WONTFIX
: GSI C
Credentials and Proxies
: unspecified
: Sun Solaris
: P2 minor
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2003-04-25 08:00 by
Modified: 2008-08-11 13:53 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2003-04-25 08:00:42
grid_proxy_init.c:869:
globus_gsi_proxy.c:761: globus_gsi_proxy_create_signed: Error with the
proxy handle
globus_gsi_proxy.c:231: globus_gsi_proxy_create_req: Error with private
key: Couldn't generate RSA key pair for proxy handle
OpenSSL Error: rsa_gen.c:182: in library: rsa routines, function
RSA_generate_key: BN lib
OpenSSL Error: md_rand.c:501: in library: random number generator,
function SSLEAY_RAND_BYTES: PRNG not seeded
OpenSSL Error: pem_lib.c:663: in library: PEM routines, function
PEM_read_bio: no start line
------- Comment #1 From 2003-04-25 09:29:53 -------
I understand this was solved in the short-term by creating ~/.rnd:

http://doesciencegrid.org/Grid/public/mail_archive/html-archive/doe-sg-eng/0833.html
http://doesciencegrid.org/Grid/public/mail_archive/html-archive/doe-sg-eng/0836.html

I'm not sure what the right long-term solution is unless openssl is just missing
some source of entrophy on the system.
------- Comment #2 From 2003-04-25 09:32:33 -------
http://www.openssl.org/support/faq.html#USER1

Your system does not provide enough entropy. Try running the entropy gathering
daemon.

/Sam
------- Comment #3 From 2003-04-25 11:17:42 -------
The reason that grid-proxy-init crashed is that it assumed that the file
/dev/urandom would exist.  There is a Solaris 8 patch that will add the devices
/dev/random and /dev/urandom, but I have checked 2 other sites that have Solaris
8 and they have not installed the patch.  I do not think that grid-proxy-init
should be considered production ready if it crashes just because a file does not
exist.  I also discovered that any binary file can be named ~/.rnd and
grid-proxy-init will then work.  The fact that the file is not there should not
make the software crash.  Not to mention that the error message does not even
give a clue that it crashed because it could not find /dev/urandom. The
work-around that I was given was to use head -1000 /dev/urandom > ~/.rnd  which
does not work when /dev/urandom does not exist.
------- Comment #4 From 2003-04-25 12:02:39 -------
First of, as far as I can tell it didn't crash, it just produced a error. Also,
the problem is not with grid-proxy-init, the problem is that your system does
not provide openssl with enough entropy to generate a key. grid-proxy-init tries
pretty hard to gather as much entropy as possible, e.g. results from various
stat() calls etc. Some of these sources are highly dubious but are supposed to
provide enough entropy for key generation on systems that do not provide
/dev/urandom. This generally seems to work but your system still does not seem
to provide enough entropy. This is a general problem with openssl, hence the
openssl faq entry. The faq entry points you at the entropy gathering daemon.
Please run it on your system. It should make the problem go away. I agree that
we could probably intercept and clarify the error openssl throws and will keep
the bug open for that (low priority for me though), but there is really nothing
more we can do in grid-proxy-init itself.

/Sam
------- Comment #5 From 2003-04-25 13:51:02 -------
Nina,

 I agree this is a bug, however please understand the following:

 1) It effects a very small number of users (you are the first we have seen in a
long time).
 2) Those users have acknowledged shortcomings on their systems and those
systems have patches available from their vendor or other ways of addressing the
problem (e.g. the entrophy grather deamon).
 3) There is an fairy easy workaround with ~/.rnd.
 4) Fixing this in our distribution would be non-trivial. It's part of the
openssl codebase we relying on and not out own code and to fix this without
compromising security would be very difficult if not impossible.

Given this and our limited resources, while we acknowledge this is not ideal, we
cannot fix it anytime in the forseeable future.

Von