Re: Harmonising OpenSSL UI handling...

[Richard Levitte - VMS Whacker]

From: Goetz Babin-Ebell <[EMAIL PROTECTED]>

gbe> I don't think that one UI function is a good solution:
gbe> There should be more than UI function:
gbe> 
gbe> 1. InsertString:   ask the user for a string
gbe> 1.1        InsertPass:     special case: ask for a passphrase
gbe> (1.2       InsertFile:     special case: ask for file name, could be handled with
gbe> 1.)
gbe> 2. Confirm:        ask to confirm some action (eg. accept a certificate in
gbe> handshake)
gbe> 3. InsertNumber:   ask for a number
gbe> 4. Ough:           give a error message
gbe> ...

Hmm, I thought this would be handled inside the general function,
depending on the command number...  But hey, matter of taste...

gbe> >         - a prompt string
gbe> should be generated in the UI

I disagree, there's no way to get it general enough.  A simple string
completely generated by the caller is a better way to maximise
generality.  Otherwise, I can almost guarantee that we will see some
ugly tweaking, or this part being hacked into until clumsiness is
irrevocably reached.  Seen it too many times already...

gbe> >         - a "wrong" string (eh, "That was the wrong password", f. example?)
gbe> should be handled in the UI (another call ?)

Really?  And how would it determine if something was previously wrong?
I was thinking of the UI as a pretty stateless thingy.  A bit
according to the KISS principle.

gbe> >         - a return buffer (double pointer, so we might allocate it in
gbe> >           that function)
gbe> >         - a return buffer size (pointer to int, so we might fill it in
gbe> >           ourselves)
gbe> depending on UI function.
gbe> (perhaps give a BUF_MEM ?)

Obviously, those parameters wouldn't be needed in all cases, and
sending NULL for them wouldn't be a bad thing...

gbe> >         - a pointer to user data
gbe> A Pointer to function specific data would be better...

Well, actually, I was thinking that this data would just be pass on to
the callback function that the user might define.  You know, a little
like we do with a bunch of other callbacks in OpenSSL :-) (the current
password prompting callback among others...).

gbe> contends should depend on 
gbe> > This function would then do a default thing or call an application-supplied
gbe> > callback that does the right thing.
gbe> perhaps a function table that normally points to some internal functions
gbe> ?

Well, actually, here's where Geoff's idea with a UI_METHOD comes in
really handy, and actually, it can be used to create the "callbacks"
as well...

gbe> To keep it localizeable we should introduce another function:
gbe> 
gbe> const char *UI_GetTextFor(MessageCode,SubCode);

Eeeep, localization...  Just the thought...  No, it's not a bad idea,
but for consistency's sake, there are lots of things that need being
changed to localize OpenSSL.  Think of all the error messages!  And
the way it's currently structured is not locale-friendly, believe me
:-/.

gbe> > In any case, this would probably become a new directory under crypto/,
gbe> > don't you think?  crypto/ui/?
gbe> 1+
gbe> 
gbe> > [it should be plain visible that I was a bit inspired from the
gbe> > HWCryptoHook stuff :-)]
gbe> Perhaps a list of required user interactions could help ?

Absolutely.

-- 
Richard Levitte   \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \      SWEDEN       \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis             -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]