/* crypto/ui/ui.h -*- mode:C; c-file-style: "eay" -*- *//* Written by Richard Levitte (richard@levitte.org) for the OpenSSL * project 2001. *//* ==================================================================== * Copyright (c) 2001 The OpenSSL Project.  All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *    notice, this list of conditions and the following disclaimer.  * * 2. Redistributions in binary form must reproduce the above copyright *    notice, this list of conditions and the following disclaimer in *    the documentation and/or other materials provided with the *    distribution. * * 3. All advertising materials mentioning features or use of this *    software must display the following acknowledgment: *    "This product includes software developed by the OpenSSL Project *    for use in the OpenSSL Toolkit. (http://www.openssl.org/)" * * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to *    endorse or promote products derived from this software without *    prior written permission. For written permission, please contact *    openssl-core@openssl.org. * * 5. Products derived from this software may not be called "OpenSSL" *    nor may "OpenSSL" appear in their names without prior written *    permission of the OpenSSL Project. * * 6. Redistributions of any form whatsoever must retain the following *    acknowledgment: *    "This product includes software developed by the OpenSSL Project *    for use in the OpenSSL Toolkit (http://www.openssl.org/)" * * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE. * ==================================================================== * * This product includes cryptographic software written by Eric Young * (eay@cryptsoft.com).  This product includes software written by Tim * Hudson (tjh@cryptsoft.com). * */#ifndef HEADER_UI_H#define HEADER_UI_H#include <openssl/crypto.h>#include <openssl/safestack.h>#ifdef  __cplusplusextern "C" {#endif/* The UI type is a holder for a specific user interface session.  It can   contain an illimited number of informational or error strings as well   as things to prompt for, both passwords (noecho mode) and others (echo   mode), and verification of the same.  All of these are called strings,   and are further described below. */typedef struct ui_st UI;/* All instances of UI have a reference to a method structure, which is a   ordered vector of functions that implement the lower level things to do.   There is an instruction on the implementation further down, in the section   for method implementors. */typedef struct ui_method_st UI_METHOD;/* All the following functions return -1 or NULL on error and in some cases   (UI_process()) -2 if interrupted or in some other way cancelled.   When everything is fine, they return 0, a positive value or a non-NULL   pointer, all depending on their purpose. *//* Creators and destructor.   */UI *UI_new(void);UI *UI_new_method(const UI_METHOD *method);void UI_free(UI *ui);/* The following functions are used to add strings to be printed and prompt   strings to prompt for data.  The names are UI_{add,dup}_<function>_string   and UI_{add,dup}_input_boolean.   UI_{add,dup}_<function>_string have the following meanings:	add	add a text or prompt string.  The pointers given to these		functions are used verbatim, no copying is done.	dup	make a copy of the text or prompt string, then add the copy		to the collection of strings in the user interface.	<function>		The function is a name for the functionality that the given		string shall be used for.  It can be one of:			input	use the string as data prompt.			verify	use the string as verification prompt.  This				is used to verify a previous input.			info	use the string for informational output.			error	use the string for error output.   Honestly, there's currently no difference between info and error for the   moment.   UI_{add,dup}_input_boolean have the same semantics for "add" and "dup",   and are typically used when one wants to prompt for a yes/no response.   All of the functions in this group take a UI and a prompt string.   The string input and verify addition functions also take a flag argument,   a buffer for the result to end up with, a minimum input size and a maximum   input size (the result buffer MUST be large enough to be able to contain   the maximum number of characters).  Additionally, the verify addition   functions takes another buffer to compare the result against.   The boolean input functions take an action description string (which should   be safe to ignore if the expected user action is obvious, for example with   a dialog box with an OK button and a Cancel button), a string of acceptable   characters to mean OK and to mean Cancel.  The two last strings are checked   to make sure they don't have common characters.  Additionally, the same   flag argument as for the string input is taken, as well as a result buffer.   The result buffer is required to be at least one byte long.  Depending on   the answer, the first character from the OK or the Cancel character strings   will be stored in the first byte of the result buffer.  No NUL will be   added, so the result is *not* a string.   On success, the all return an index of the added information.  That index   is usefull when retrieving results with UI_get0_result(). */int UI_add_input_string(UI *ui, const char *prompt, int flags,	char *result_buf, int minsize, int maxsize);int UI_dup_input_string(UI *ui, const char *prompt, int flags,	char *result_buf, int minsize, int maxsize);int UI_add_verify_string(UI *ui, const char *prompt, int flags,	char *result_buf, int minsize, int maxsize, const char *test_buf);int UI_dup_verify_string(UI *ui, const char *prompt, int flags,	char *result_buf, int minsize, int maxsize, const char *test_buf);int UI_add_input_boolean(UI *ui, const char *prompt, const char *action_desc,	const char *ok_chars, const char *cancel_chars,	int flags, char *result_buf);int UI_dup_input_boolean(UI *ui, const char *prompt, const char *action_desc,	const char *ok_chars, const char *cancel_chars,	int flags, char *result_buf);int UI_add_info_string(UI *ui, const char *text);int UI_dup_info_string(UI *ui, const char *text);int UI_add_error_string(UI *ui, const char *text);int UI_dup_error_string(UI *ui, const char *text);/* These are the possible flags.  They can be or'ed together. *//* Use to have echoing of input */#define UI_INPUT_FLAG_ECHO		0x01/* Use a default password.  Where that password is found is completely   up to the application, it might for example be in the user data set   with UI_add_user_data().  It is not recommended to have more than   one input in each UI being marked with this flag, or the application   might get confused. */#define UI_INPUT_FLAG_DEFAULT_PWD	0x02/* The user of these routines may want to define flags of their own.  The core   UI won't look at those, but will pass them on to the method routines.  They   must use higher bits so they don't get confused with the UI bits above.   UI_INPUT_FLAG_USER_BASE tells which is the lowest bit to use.  A good   example of use is this:	#define MY_UI_FLAG1	(0x01 << UI_INPUT_FLAG_USER_BASE)*/#define UI_INPUT_FLAG_USER_BASE	16/* The following function helps construct a prompt.  object_desc is a   textual short description of the object, for example "pass phrase",   and object_name is the name of the object (might be a card name or   a file name.   The returned string shall always be allocated on the heap with   OPENSSL_malloc(), and need to be free'd with OPENSSL_free().   If the ui_method doesn't contain a pointer to a user-defined prompt   constructor, a default string is built, looking like this:	"Enter {object_desc} for {object_name}:"   So, if object_desc has the value "pass phrase" and object_name has   the value "foo.key", the resulting string is:	"Enter pass phrase for foo.key:"*/char *UI_construct_prompt(UI *ui_method,