[ apologies for delay - still having trouble sending to this list ]
On Thu, 19 Jun 2003 10:47:40 +0200 (METDST)
"Richard Levitte - VMS Whacker via RT" <[EMAIL PROTECTED]> wrote:
>
> In message <[EMAIL PROTECTED]> on Thu, 19 Jun 2003 08:51:58 +0200 (METDST), "Bob
> Hepple via RT" <[EMAIL PROTECTED]> said:
> Uhmm, you're doing the prompting through a UI_METHOD, I assume (more
> precisely, the one returned by UI_OpenSSL()). All OpenSSL application
> prompting for pass phrases ('openssl genrsa' and lots of other
> commands) use that same mechanism, so I'm quite surprised this hasn't
> been heard of before.
>
Actually, I'm using a higher level - EVP. I put the following into genrsa,
gendsa and the application (apache via mod_ssl)
mod_ssl-2.8.14-1.3.27/pkg.sslmod/ssl_engine_init.c:
if ((i = EVP_read_pw_string(buf, PKCS_PIN_SIZE, "Please enter the user's PIN: ",
FALSE)) != 0) {
ssl_log(s, SSL_LOG_ERROR, "Failed to input User's PIN");
break;
}
The EVP_read_pw_string() functions calls:
ui = UI_new();
UI_add_input_string(ui,prompt,0,buf,0,(len>=BUFSIZ)?BUFSIZ-1:len);
... tracing through this confirms that it winds up in UI_OpenSSL().
> Have you tested if 'openssl genrsa' works? If it does, perhaps you
> should figure out what you do differently from the OpenSSL
> application. You probably want to check out the function
> setup_ui_method() and related static functions in apps/apps.c, or
> check out the nCipher engine, which I'm pretty sure does things
> properly (at least last time I tested).
With "openssl genrsa" I prompt for the PIN in an identical way. It works
fine if TERMIOS is set but fails when compiled with TERMIO.
Where genrsa does prompting and input for des passphrases, in
crypto/des/read_pwd.c, it just jumps straight down to the metal and does
fopen(), fgets() by the look of it. Perhaps this is debugged and working
and EVP_read_pw_string() is not.
>
> rt> Normally, Linux is configured with -DTERMIO set. This causes fgets() to
> rt> return an error (it returns NULL and feof() is set) when NOECHO is used in
> rt> crypto/ui/ui_openssl:read_string_inner()
> rt>
> rt> If I compile with -DTERMIOS instead, there is no error. So my question is
> rt> in 3 parts:
> rt>
> rt> 1. what is the 'correct' way to specify TERMIOS instead of TERMIO? I have
> rt> tried setting the TERMIOS parameter in util/pl/linux.pl to no avail. I am
> rt> currently changing all the linux configurations in the 'Configure' script
> rt> and this seems to work, but it's messy.
>
> There's some preprocessor code in crypto/ui/ui_openssl.c that forces
> TERMIO for Linux. You might want to disable that, or make it force
> TERMIOS instead.
>
Presumably I'd need to patch up crypto/des/read_pwd.c & crypto/buildinf.h too?
> rt> 2. Since this fixes the problem, can this setting please be used as the
> rt> default in future?
>
> Will it work on all Linux variants, including somewhat aged Linux
> systems?
>
I tried RedHat 6.1 (kernel 2.2.12) and it worked fine with TERMIOS and
failed to input the key with TERMIO.
I don't have debian handy. I could do some testing on SuSE 6 to SuSE 9 but
that is so similar to RH that it's probably not worth it.
[ I probably have my old RH 4 CD's from 1999 somewhere. I only kept the
boot floppy from my SLS 0.9.x kernel from 1993? and I can't find my
yggdrasil CD from 1995? so I can't install them - but that's getting
absurd! :-) ]
> rt> 3. Why use TERMIO when TERMIOS is available on Linux?
>
> Because once upon a time, when the original code was constructed,
> there was only TERMIO, I assume. Noone has complained since, so...
>
> rt> ... and yes, the current stat of the port is available as a source code
> rt> patch at http://www.eracom-tech.com/downloads/downloads.php
>
> I think "available" depends on who you are. I just tried, and was
> redirected to http://www.eracom-tech.com/login/userlogin.php...
>
> Anyhow, whenever it really becomes available, I think I can take a
> look and see if I can spot something.
>
It's just a free registration. We are building a list of people who
download so that we can evaluate the interest in this port and also keep
people informed of new efforts. Nothing untoward!
Also, I just discovered that our web people have put up a descriptive page:
http://www.eracom-tech.com/products/openssl/openssl.htm
--
Bob Hepple, Research & Development Group
Eracom Technologies Australia Pty. Ltd.
28 Greg Chappell Drive, Burleigh Heads, Qld. 4220, Australia
Tel.: +61 7 5593 4911 Fax.: +61 7 5593 4388
Email: [EMAIL PROTECTED]
Web: www.eracom-tech.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
