Re: Harmonising OpenSSL UI handling...

[Richard Levitte - VMS Whacker]

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

gbe> Richard Levitte - VMS Whacker wrote:
gbe> Hallo Richard,
gbe> > From: Goetz Babin-Ebell <[EMAIL PROTECTED]>
gbe> > gbe> 1. InsertString:   ask the user for a string
gbe> > gbe> 1.1        InsertPass:     special case: ask for a passphrase
gbe> > gbe> (1.2       InsertFile:     special case: ask for file name, could be 
handled with
gbe> > gbe> 1.)
gbe> [...]
gbe> > 
gbe> > Hmm, I thought this would be handled inside the general function,
gbe> > depending on the command number...  But hey, matter of taste...
gbe> 
gbe> Agree,
gbe> but a seperate function for user autentification would be good...

Exactly what do you mean?  If it's the separation between strings,
passphrases and file (and whatever), it's still just a string, with
the only real difference that prompting for a password requires no
echo.

But, I'm currently designing a UI_METHOD that has separate methods for
reading a string and reading a passphrase.

gbe> > gbe> >         - a prompt string
gbe> > gbe> should be generated in the UI
gbe> > 
gbe> > I disagree, there's no way to get it general enough.  A simple string
gbe> > completely generated by the caller is a better way to maximise
gbe> > generality.  Otherwise, I can almost guarantee that we will see some
gbe> > ugly tweaking, or this part being hacked into until clumsiness is
gbe> > irrevocably reached.  Seen it too many times already...
gbe> 
gbe> But will the generated string fit the output ?
gbe> A PIN Pad with a 16x2 LCD requires another layout than a GUI...

Hmm, good point.  Perhaps one should have the applicatoin check the
maximum size and have it adapt?

gbe> > gbe> >         - a "wrong" string (eh, "That was the wrong password", f. 
example?)
gbe> > gbe> should be handled in the UI (another call ?)
gbe> > 
gbe> > Really?  And how would it determine if something was previously wrong?
gbe> > I was thinking of the UI as a pretty stateless thingy.  A bit
gbe> > according to the KISS principle.
gbe> Another Message ?
gbe>    UI_GetAut(TXT_AUT_CLIENT,...)
gbe>    UI_GetAut(TXT_AUT_LASTTRY,...)

I'm not sure I got that.  For example, you might want to include an
error text in a prompt dialog box, a little like the default XDM login
screen works (it will say that you weren't authenticated and at the
same time prompt again).  That's why I think the prompting routines
need to know about that info as well...

gbe> > gbe> >         - a pointer to user data
gbe> > gbe> A Pointer to function specific data would be better...
gbe> > 
gbe> > Well, actually, I was thinking that this data would just be pass on to
gbe> > the callback function that the user might define.  You know, a little
gbe> > like we do with a bunch of other callbacks in OpenSSL :-) (the current
gbe> > password prompting callback among others...).
gbe> 
gbe> typedef struct
gbe> {
gbe>    unsigned long type;     /* type == UI_TYPE_AUTHDATA means is
gbe> UI_AuthData */
gbe>    unsigned int minAuthLen;
gbe>    unsigned int maxAuthLen;
gbe>    char *authBuffer;       /* will contain user authentication */
gbe>    int verify;
gbe>    const char *AuthIDName; /* contains name of key */
gbe>    void *userData;
gbe> } UI_AuthData;

I think we were thinking about different things, but now that I've
started on UI_METHOD, the need for callbacks has decreased (actually,
slammed down to zero :-)).

gbe> > gbe> const char *UI_GetTextFor(MessageCode,SubCode);
gbe> > 
gbe> > Eeeep, localization...  Just the thought...  No, it's not a bad idea,
[...]
gbe> I know...
gbe> But the UI seems to be a good place to start...

Hmm, true...  Gotta learn how those things work (is there a standard
at all?)

gbe> 1. user authentication (pass phrase, PIN,...)
gbe>    (should be able to give a name/ID for the requested authentification)

Check.

gbe> 2. new user authentification (new pass prase, with verify)

Ah...  check.

gbe> 3. give some information about the current state
gbe>    (only print/log some data, don't wait for input)

Check.

gbe> What else ?

Doesn't have to be decided all at once, there's room for extensions...

-- 
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]