Richard Levitte - VMS Whacker wrote:
Hallo Richard,
> From: Goetz Babin-Ebell <[EMAIL PROTECTED]>
> 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.)
[...]
>
> Hmm, I thought this would be handled inside the general function,
> depending on the command number... But hey, matter of taste...
Agree,
but a seperate function for user autentification would be good...
> 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...
But will the generated string fit the output ?
A PIN Pad with a 16x2 LCD requires another layout than a GUI...
> 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.
Another Message ?
UI_GetAut(TXT_AUT_CLIENT,...)
UI_GetAut(TXT_AUT_LASTTRY,...)
> 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...).
typedef struct
{
unsigned long type; /* type == UI_TYPE_AUTHDATA means is
UI_AuthData */
unsigned int minAuthLen;
unsigned int maxAuthLen;
char *authBuffer; /* will contain user authentication */
int verify;
const char *AuthIDName; /* contains name of key */
void *userData;
} UI_AuthData;
> 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
> :-/.
I know...
But the UI seems to be a good place to start...
> gbe> Perhaps a list of required user interactions could help ?
>
> Absolutely.
Let's start:
UI is needed for:
1. user authentication (pass phrase, PIN,...)
(should be able to give a name/ID for the requested authentification)
2. new user authentification (new pass prase, with verify)
3. give some information about the current state
(only print/log some data, don't wait for input)
What else ?
By
Goetz
--
Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
