application do that.
NOTE: there's no requirement for other UI_METHODs to avoid this kind
of loop. For example, a GUI UI_METHOD would probably check the
lengths of the answers from within instead of being constantly
redisplayed for everything that is wrong.
Implement UI controls. Current controls are the possibility to output
the OpenSSL error stack on the same channel from within UI_process()
and to check if the same user interface can be redone without being
rebuilt (this is often more a question of philosophy than
technicalities).
prompting, application-defined prompts, the possibility to use
defaults (for example default passwords from somewhere else) and
interrupts/cancelations.
In the new crypto/ui/, this was changed into tty (which is usually
/dev/tty), i.e. the FILE * used for reading passwords from the user.
However stdio buffering for read/write streams is not without pitfalls
(passwords would be echoed on some systems).
To avoid problems, split tty into tty_in and tty_out (which are
opened separately).
(for new functions...). One might still want to be able to pass down
a user-data pointer to be used by the UI. However, ex_data doesn't
quite cut it, since that means the appropriate index to it might need
to be shared between parts that aren't really related in that sense,
and would require the currently hidden (static) index holders to be
uncovered. Not a good thing. Therefore, add the possibility to add a
user-data pointer to a UI.
For some unknown reason fopen("con", "w") is the
only way to make this work. Using "r+" and "w+"
causes the fopen call to fail and the fallback
(using stdin) doesn't work because writing to stdin
fails.
like des_read_password and friends (backward compatibility functions
using this new API are provided). The purpose is to remove prompting
functions from the DES code section as well as provide for prompting
through dialog boxes in a window system and the like.
