In message <12031409093019_20200...@antinode.info> on Wed, 14 Mar 2012 09:09:30
-0500 (CDT), "Steven M. Schweda" <s...@antinode.info> said:
sms> From: Richard Levitte <rich...@levitte.org>
sms>
sms> > Of course not... it should be as you mentioned...
sms> > [...]
sms>
sms> I was thinking more like:
sms>
sms> #if !defined(OPENSSL_NO_JPAKE) && !defined(OPENSSL_NO_PSK)
sms> if (jpake_secret)
sms> {
sms> if (psk_key)
sms> {
sms> BIO_printf(bio_err,
sms> "Can't use JPAKE and PSK together\n");
sms> goto end;
sms> }
sms> psk_identity = "JPAKE";
sms>
sms> if (cipher)
sms> {
sms> if (strcmp( cipher, "PSK"))
sms> {
sms> BIO_printf(bio_err,
sms> "JPAKE sets cipher to PSK\n");
sms> goto end;
sms> }
sms> }
sms> else
sms> {
sms> cipher = "PSK";
sms> }
sms> }
sms> #endif
That's functionally the same, isn't it?
sms> But, if I had a fatal message like that, I'd probably want to tell the
sms> victim what the bad "cipher" value was, and that JPAKE demands that it
sms> be "PSK". Saying "JPAKE sets cipher to PSK", and then dying without
sms> actually setting "cipher" to anything seems misleading to me.
I agree. However, JPAKE is considered experimental and should not be
enabled by default (that's a mistake in the VMS build, I'm working on
that right now (*)).
sms> > There's a fix in newer OpenSSL versions, with a variant for BeOS R5
sms> > that tries reading stdin in non-blocking mode to see if there's
sms> > anything there... I'm just now seeing if that can be hijacked for VMS
sms> > as well, in that case I think we're good to go for a back port.
sms>
sms> There are VMS-specific terminal things which can be done, but, with
sms> the existing lack of descriptive comments in this code, it's not obvious
sms> (to a non-Windows/non-BEOS programmer) what the desired behavior is in
sms> some of these places. For that matter, simply defining _functional_
sms> macros, like, say, SELECT_WORKS_ON_FILES, and then defining _those_
sms> based on system type, might help someone who's trying to support a new
sms> system type.
... and writing an internal application library that takes care of the
diversity, yeah I'm with you there.
sms> > The first change (an extra \n) seem to be cosmetic only, or does it
sms> > actually change the function in a crutial way? Considering you have
sms> > marked it optional, I'll guess that it doesn't?
sms>
sms> I know nothing, but in my playing around, the last line I got before
sms> the program got stuck was "---", with the cursor resting over the
sms> left-most "-". I suspect that the extra "\n" was intended to get the
sms> cursor onto its own line, below the "---" line. Considering how
sms> differently VMS handles terminal I/O (CR, LF, et c.), I would not bet
sms> that any of this stuff would actually look right (without some extra
sms> effort, anyway). Of course, I'm not overly fond of programs which wait
sms> for user input without putting out an obvious prompt first, so what's my
sms> opinion worth?
s_client is basically supposed to work like telnet (minus the telnet
features plus the ssl features), so it's not much of a surprise that
it gives you as much a prompt as telnet does.
I find it weird that the particular \n there would fail... isn't that
something that C library is supposed to deal with properly? Of
course, s_client uses BIO_printf(), but that one in turn uses the
usual C library... so it's to wonder why \n wouldn't work in that
particular spot. I'll have to see if I can reproduce it.
--
Richard Levitte rich...@levitte.org
http://richard.levitte.org/
"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
