From: Richard Levitte <rich...@levitte.org>

> Of course not...  it should be as you mentioned...
> [...]

   I was thinking more like:

#if !defined(OPENSSL_NO_JPAKE) && !defined(OPENSSL_NO_PSK)
        if (jpake_secret)
                {
                if (psk_key)
                        {
                        BIO_printf(bio_err,
                                   "Can't use JPAKE and PSK together\n");
                        goto end;
                        }
                psk_identity = "JPAKE";

                if (cipher)
                        {
                        if (strcmp( cipher, "PSK"))
                                {
                                BIO_printf(bio_err,
                                 "JPAKE sets cipher to PSK\n");
                                goto end;
                                }
                        }
                else
                        {
                        cipher = "PSK";
                        }
                }
#endif

   But, if I had a fatal message like that, I'd probably want to tell the
victim what the bad "cipher" value was, and that JPAKE demands that it
be "PSK".  Saying "JPAKE sets cipher to PSK", and then dying without
actually setting "cipher" to anything seems misleading to me.

> There's a fix in newer OpenSSL versions, with a variant for BeOS R5
> that tries reading stdin in non-blocking mode to see if there's
> anything there...  I'm just now seeing if that can be hijacked for VMS
> as well, in that case I think we're good to go for a back port.

   There are VMS-specific terminal things which can be done, but, with
the existing lack of descriptive comments in this code, it's not obvious
(to a non-Windows/non-BEOS programmer) what the desired behavior is in
some of these places.  For that matter, simply defining _functional_
macros, like, say, SELECT_WORKS_ON_FILES, and then defining _those_
based on system type, might help someone who's trying to support a new
system type.

> The first change (an extra \n) seem to be cosmetic only, or does it
> actually change the function in a crutial way?  Considering you have
> marked it optional, I'll guess that it doesn't?

   I know nothing, but in my playing around, the last line I got before
the program got stuck was "---", with the cursor resting over the
left-most "-".  I suspect that the extra "\n" was intended to get the
cursor onto its own line, below the "---" line.  Considering how
differently VMS handles terminal I/O (CR, LF, et c.), I would not bet
that any of this stuff would actually look right (without some extra
effort, anyway).  Of course, I'm not overly fond of programs which wait
for user input without putting out an obvious prompt first, so what's my
opinion worth?

------------------------------------------------------------------------

   Steven M. Schweda               sms@antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to