\input texinfo @c -*-texinfo-*- @c %**start of header @setfilename assuan.info @macro copyrightnotice Copyright @copyright{} 2002, 2003, 2006, 2007 Free Software Foundation, Inc. @end macro @macro permissionnotice Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. The text of the license can be found in the section entitled ``Copying''. @end macro @include version.texi @settitle Developing with Assuan @c Create a separate index for command line options. @defcodeindex op @c Merge the standard indexes into a single one. @syncodeindex fn cp @syncodeindex vr cp @syncodeindex ky cp @syncodeindex pg cp @syncodeindex tp cp @c A simple macro for optional variables. @macro ovar{varname} @r{[}@var{\varname\}@r{]} @end macro @c printing stuff taken from gcc. @macro gnupgtabopt{body} @code{\body\} @end macro @macro gnupgoptlist{body} @smallexample \body\ @end smallexample @end macro @c Makeinfo handles the above macro OK, TeX needs manual line breaks; @c they get lost at some point in handling the macro. But if @macro is @c used here rather than @alias, it produces double line breaks. @iftex @alias gol = * @end iftex @ifnottex @macro gol @end macro @end ifnottex @c Change the font used for @def... commands, since the default @c proportional one used is bad for names starting __. @tex \global\setfont\defbf\ttbshape{10}{\magstep1} @end tex @c %**end of header @ifnottex @dircategory GNU Libraries @direntry * Assuan: (assuan). An IPC library for non-persistent servers. @end direntry This file documents the use and the internals of Assuan. This is Edition @value{EDITION}, last updated @value{UPDATED}, of @cite{The `Developing with Assuan' Manual}, for Version @value{VERSION}. @sp 1 Published by the Free Software Foundation@* 51 Franklin Street, Fifth Floor@* Boston, MA 02110-1301 USA @sp 1 @copyrightnotice{} @sp 1 @permissionnotice{} @end ifnottex @setchapternewpage odd @titlepage @title Developing with Assuan @subtitle Version @value{VERSION} @subtitle @value{UPDATED} @author by Werner Koch and Marcus Brinkmann @author @code{@{wk,mb@}@@g10code.com} @page @vskip 0pt plus 1filll @copyrightnotice{} @sp 2 @permissionnotice{} @end titlepage @summarycontents @contents @page @ifnottex @node Top @top Introduction @cindex introduction This manual documents how to exploit the Assuan library, a simple interprocess communcation library. @end ifnottex @menu * Introduction:: An introduction to and the motivation behind Assuan. * Assuan:: Description of the Assuan protocol. * Implementation:: Overview of the implementation. * Preparation:: What you should do before using the library. * Generalities:: Initialization code and data types used. * Client code:: How to develop an Assuan client. * Server code:: How to develop an Assuan server. * External I/O Loop:: How to use external I/O event loops. * Utilities:: Utility functions. Miscellaneous * Library Copying:: GNU Lesser General Public License says how you can copy and share Assuan. * Copying:: How you can copy and share this manual. Indices * Index:: Index of concepts and symbol names. @end menu @c @c I N T R O @c @node Introduction @chapter Introduction to Assuan In an ideal world, Assuan would not be necessary. Assuan's primary use is to allow a client to interact with a non-persistent server. Using Assuan, this is accomplished by forking a subprocess and communicating with it via, for example, a pipe or Unix domain socket. This method is neither elegant nor efficient, especially when there is a lot of data spread across several transactions: not only is there a penalty for an increased number of context switches, but also a significant amount of data is @var{memcpy}ed from the client to a file descriptor and from the file descriptor to the server. Despite these and other disadvantages, this type of client/server communication can be useful: the client is completely separate from the server; they are in different address spaces. This is especially important in situations where the server must have a known degree of reliability and data must be protected: as the Assuan protocol is well defined and clients cannot corrupt the servers' address space, auditing becomes much easier. Assuan was developed for use by the GNU Privacy Guard, GnuPG, to prevent potentially buggy clients from unwittingly corrupting sensitive transactions or compromising data such as a secret key. Assuan permits the servers, which do the actual work, e.g. encryption and decryption of data using a secret key, to be developed independently of the user interfaces, e.g. mail clients and other encryption front ends. Like a shared library, the interface is well defined and any number of front ends can use it; however, unlike a shared library, the client cannot see or touch the server's data. As with any modular system, Assuan helps keep the components small, understandable and less error prone. Assuan is not, however, limited to use with GnuPG servers and clients: it was designed to be flexible enough to meet the demands of many transaction based environments with non-persistent servers. @node Assuan @chapter Description of the Assuan protocol. The architecture of the modular GnuPG system is based on several highly specialized modules which compose a network of client/server communication. A common framework for intermodule communication is therefore needed and should be implemented in a library. Goals: @itemize @bullet @item Common framework for module communication @item Easy debugging @item Easy module testing @item Extendible @item Optional authentication and encryption facility @item Usable to access external hardware @end itemize Design criteria: @itemize @bullet @item Client server with back channel @item Use a mainly text based protocol @item Escape certain control characters @item Allow indefinite data length @item Request confidentiality for parts of the communication @item Dummy module to allow direct linking of client and server @item Inline data or descriptor passing for bulk data @item No protection against DoS needed @item Subliminal channels are not an issue @end itemize @node Implementation @chapter Implementation The implementation is line based with a maximum line size of 1000 octets. The default IPC mechanism are Unix Domain Sockets. On a connect request the server responds either with an okay or an error status. For authentication check the server may send an Inquiry Response prior to the first Okay, and it may also issue Status messages. The server must check that the client is allowed to connect, this is done by requesting the credentials for the peer and comparing them to those of the server. This avoids attacks based on wrong socket permissions. It may choose to delay the first response in case of an error. The server never closes the connection - however the lower protocol may do so after some time of inactivity or when the connection is in an error state. All textual messages are assumed to be in UTF-8 unless otherwise noted. @menu * Server responses:: Description of server responses. * Client requests:: Description of client requests. * Error codes:: List of error and status codes. @end menu @node Server responses @section Server responses @table @code @item OK [] Request was successful. @item ERR @var{errorcode} [] Request could not be fulfilled. The error codes are mostly application specific except for a few common ones. @item S @var{keyword} Informational output by the server, still processing the request. @item # Comment line issued only for debugging purposes. Totally ignored. @item D Raw data returned to client. There must be exactly one space after the 'D'. The values for '%', CR and LF must be percent escaped; this is encoded as %25, %0D and %0A. Only uppercase letters should be used in the hexadecimal representation. Other characters may be percent escaped for easier debugging. All these Data lines are considered one data stream up to the OK or ERR response. Status and Inquiry Responses may be mixed with the Data lines. @item INQUIRE @var{keyword} Server needs further information from the client. The client should answer with a command which is allowed after an inquiry. Note that the server does not confirm that client command but either continues processing or ends processing with an error status. Not all commands are allowed. @end table A client should only check the first letter of each line and then skip over to the next token (except for data lines where the raw data starts exactly after 2 bytes). Lines larger than 1000 bytes should be treated as a communication error. (The rationale for having a line length limit is to allow for easier multiplexing of several channels). @node Client requests @section Client requests The server waits for client requests after he sent an Okay or Error. The client should not issue a request in other cases. @example @var{command} @end example @var{command} is a one word string without preceding white space. Parameters are command specific, CR, LF and the percent signs should be percent escaped as described above. To send a backslash as the last character it should also be percent escaped. Percent escaping is allowed anywhere in the parameters but not in the command. The line ends with a CR, LF or just a LF. Not yet implemented feature: If there is a need for a parameter list longer than the line length limit (1000 characters including command and CR, LF), the last character of the line (right before the CR/LF or LF) must be a non-escape encoded backslash. The following line is then expected to be a continuation of the line with the backslash replaced by a blank and the line ending removed. @example D @end example Raw data to the server. There must be exactly one space after the 'D'. The values for '%', CR and LF must be percent escaped; this is encoded as %25, %0D and %0A. Only uppercase letters should be used in the hexadecimal representation. Other characters may be percent escaped for easier debugging. All these Data lines are considered one data stream up to the OKAY or ERROR response. Status and Inquiry Responses may be mixed with the Data lines. @example END @end example Lines beginning with a @code{#} or empty lines are ignored. This is useful to comment test scripts. Although the commands are application specific, some of them are used by all protocols and partly directly supported by the Assuan library: @table @code @item BYE Close the connect, the server will reply with an @code{OK}. @item RESET Reset the connection but not any existing authentication. The server should release all resources associated with the connection. @item END Used by a client to mark the end of raw data. The server may send END to indicate a partial end of data. @item HELP Reserved for future extensions. @item QUIT Reserved for future extensions. @item OPTION Set options for the connection. The syntax of such a line is @display OPTION @var{name} [ [=] @var{value} ] @end display Leading and trailing spaces around @var{name} and @var{value} are allowed but should be ignored. For compatibility reasons, @var{name} may be prefixed with two dashes. The use of the equal sign is optional but suggested if @var{value} is given. @item CANCEL This command is reserved for future extensions. @item AUTH This command is reserved for future extensions. Not yet specified as we don't implement it in the first phase. See my mail to gpa-dev on 2001-10-25 about the rationale for measurements against local attacks. @end table @node Error codes @section Error codes In general Libassuan should be used with gpg-error style error codes. For compatibility reasons and for applications not wanting to use these error codes, the old Assuan error codes may still be used. In fact they are used by default. To switch to gpg-error style error codes, applications should call the @ref{function assuan_set_assuan_err_source} right after startup. @c @c P R E P A R A T I O N @c @node Preparation @chapter Preparation To use `@sc{libassuan}', you have to perform some changes to your sources and the build system. The necessary changes are small and explained in the following sections. @menu * Header:: What header file you need to include. * Building sources:: How to build sources using the library. * Automake:: How to build sources with the help of Automake. * Multi Threading:: How @sc{libassuan} can be used in a MT environment. @end menu @node Header @section Header All interfaces (data types and functions) of @sc{libassuan} are defined in the header file @file{assuan.h}. You must include this in all source files using the library, either directly or through some other header file, like this: @example #include @end example The name space of `@sc{assuan}' is @code{assuan_*} for function and type names and @code{ASSUAN*} for other symbols. In addition the same name prefixes with one prepended underscore are reserved for internal use and should never be used by an application. @node Building sources @section Building sources If you want to compile a source file including the @file{assuan.h} header file, you must make sure that the compiler can find it in the directory hierarchy. This is accomplished by adding the path to the directory in which the header file is located to the compilers include file search path (via the @option{-I} option). However, the path to the include file is determined at the time the source is configured. To solve this problem, @sc{libgcrypt} ships with a small helper program @command{libassuan-config} that knows the path to the include file and other configuration options. The options that need to be added to the compiler invocation at compile time are output by the @option{--cflags} option to @command{libassuan-config}. The following example shows how it can be used at the command line: @example gcc -c foo.c $(libassuan-config --cflags) @end example Adding the output of @samp{libassuan-config --cflags} to the compiler's command line will ensure that the compiler can find the @file{assuan.h} header file. A similar problem occurs when linking the program with the library. Again, the compiler/linker has to find the library files. For this to work, the path to the library files has to be added to the library search path (via the @option{-L} option). For this, the option @option{--libs} to @command{libassuan-config} can be used. For convenience, this option also outputs all other options that are required to link the program with the @sc{libassuan} libraries (in particular, the @option{-lassuan} option). The example shows how to link @file{foo.o} with the @sc{libassuan} library to a program @command{foo}. @example gcc -o foo foo.o $(libassuan-config --libs) @end example Of course you can also combine both examples to a single command by specifying both options to @command{libassuan-config}: @example gcc -o foo foo.c $(libassuan-config --cflags --libs) @end example If your application uses Pth or pthread, you need to pass the option @option{--thread=pth} respective @option{--thread=pthread} to the invocation of @command{libassuan-config}. @node Automake @section Building sources using Automake It is much easier if you use GNU Automake instead of writing your own Makefiles. If you do that you do not have to worry about finding and invoking the @command{libassuan-config} script at all. @sc{libassuan} provides an Automake macro that does all the work for you. @defmac AM_PATH_LIBASSUAN (@ovar{minimum-version}, @ovar{action-if-found}, @ovar{action-if-not-found}) Check whether @sc{libassuan} (at least version @var{minimum-version}, if given) exists on the host system. If it is found, execute @var{action-if-found}, otherwise do @var{action-if-not-found}, if given. Additionally, the function defines @code{LIBASSUAN_CFLAGS} to the flags needed for compilation of the program to find the @file{assuan.h} header file, and @code{LIBASSUAN_LIBS} to the linker flags needed to link the program to the @sc{libassuan} library. @end defmac You can use the defined Autoconf variables like this in your @file{Makefile.am}: @example AM_CPPFLAGS = $(LIBASSUAN_CFLAGS) LDADD = $(LIBASSUAN_LIBS) @end example @defmac AM_PATH_LIBASSUAN_PTH (@ovar{minimum-version}, @ovar{action-if-found}, @ovar{action-if-not-found}) Same as @code{AM_PATH_LIBASSUAN} but checks for the GNU Pth enabled version of the library and defines @code{LIBASSUAN_PTH_CFLAGS} @code{LIBASSUAN_PTH_LIBS} instead. Use this is you are using GNU Pth. Note that you also need to pass the appropriate options for Pth to the compiler and linker. @end defmac @defmac AM_PATH_LIBASSUAN_PTHREAD (@ovar{minimum-version}, @ovar{action-if-found}, @ovar{action-if-not-found}) Same as @code{AM_PATH_LIBASSUAN} but checks for the pthreads enabled version of the library and defines @code{LIBASSUAN_PTHREAD_CFLAGS} @code{LIBASSUAN_PTHREAD_LIBS} instead. Use this is you are using GNU Pth. Note that you also need to pass the appropriate options for Pth to the compiler and linker. @end defmac @node Multi Threading @section Multi Threading The @sc{libgcrypt} library is thread-safe if you adhere to the following requirements: @itemize @bullet @item Run the initialization functions before you actually start to use threads. @item Only one thread at a time may access an @sc{libassuan} context. @item Use @code{assuan_set_assuan_log_stream} to setup a default log stream. @end itemize @c @c G E N E R A L I T I E S @c @node Generalities @chapter Generalities @menu * Data Types:: Data types used by @sc{libassuan}. * Initializing the library:: How to initialize the library. * Reading and Writing:: How to communicate with the peer. @end menu @node Data Types @section Data Types used by the library @sc{libassuan} uses a context approach to keep state. The following data type is used all over the place: @deftp {Data type} assuan_context_t The @code{assuan_context_t} type is a pointer to an object maintained internally by the library. Certain Assuan functions allocate such a context and return it to the caller using this data type. Other functions take this data type to access the state created by these functions. @end deftp @noindent For compatibility with older versions of @sc{libassuan} a data type for error return values exists: @deftp {Data type} assuan_error_t This has originally been an @code{enum} but applications should either view it as an @code{int} or if possible use the @code{gpg_error_t} data type as defined by the @sc{libgpg-error} package. @end deftp @node Initializing the library @section Initializing the library In general the library requires no initialization. There are however some initialization hooks provided which are often useful. These should be called as early as possible and in a multi-threaded application before a second thread is created. If your application uses its own memory allocation functions or wrappers it is good idea to tell @sc{libassuan} about it so it can make use of the same functions or wrappers. You do this with @deftypefun void assuan_set_malloc_hooks (@w{void *(*@var{malloc_func})(size_t)}, @w{void *(*@var{realloc_func})(void *, size_t)}, @w{void (*@var{free_func})(void*)}) You need to provide all three functions. Those functions need to behave exactly as their standard counterparts (@code{malloc}, @code{realloc} and @code{free}). If you write your own functions please take care to set @code{errno} whenever an error has occurred. @end deftypefun @noindent To integrate assuan logging and diagnostics into your own logging system, you may use the following two functions: @deftypefun void assuan_set_assuan_log_stream (FILE *@var{fp}) This sets the stream to which @sc{libassuan} should log messages not associated with a specific context to @var{fp}. The default is to log to @code{stderr}. This default value is also changed by using @code{assuan_set_log_stream} (to set a logging stream for a specific context) unless this function has been used. Obviously this is not thread-safe and thus it is highly recommended to use this function to setup a proper default. @end deftypefun @deftypefun void assuan_set_assuan_log_prefix (@w{const char *@var{text}}) Set the prefix to be used at the start of a line emitted by assuan on the log stream to @var{text}. The default is the empty string. @end deftypefun If you intend to use @sc{libassuan} along with the package @sc{libgpg-error} it is recommended to switch @sc{libassuan} into a mode which directly makes use of error codes provided by @sc{libgpg-error}. Because the Assuan error codes and those of gpg-error overlap, it is required to explicitly request this. You do this by calling the function @anchor{function assuan_set_assuan_err_source} @deftypefun void assuan_set_assuan_err_source (@w{int @var{errsource}}) Enable gpg-error style error codes. @var{errsource} is one of the gpg-error sources. Switching back to the old style mode is not possible. The usual way to call this function is @smallexample assuan_set_assuan_err_source (GPG_ERR_SOURCE_DEFAULT); @end smallexample @end deftypefun @node Reading and Writing @section How to communicate with the peer What would be an IPC library without the ability to read and write data? Not very useful. Libassuan has high level functions to take care of of the more boring stuff but eventually data needs to be written and read. @noindent The basic read and write functions are: @deftypefun assuan_error_t assuan_read_line (@w{assuan_context_t @var{ctx}}, @w{char **@var{line}}, @w{size_t *@var{linelen}}) Read the next line from the client or server and store a pointer to the buffer holding that line at the address @var{line}. The valid length of the lines is stored at the address of @var{linelen}. This buffer is valid until the next read operation on the same context @var{ctx}. You may modify the context of this buffer. The buffer is invalid (i.e. must not be used) if an error is returned. This function returns @code{0} on success or an error code. @end deftypefun @deftypefun assuan_error_t assuan_write_line (@w{assuan_context_t @var{ctx}}, @w{const char *@var{line}}) Write the string @var{line} to the other end. This string needs to be a proper formatted Assuan protocol line and should not include a linefeed. Sending linefeed or Nul characters is not possible and not allowed by the assuan protocol. This function shall not be used for sending data (D) lines. This function returns @code{0} on success or an error code. @end deftypefun @noindent To actually send bulk data lines a specialized function is available: @deftypefun assuan_error_t assuan_send_data (@w{assuan_context_t @var{ctx}}, @w{const void *@var{buffer}}, @w{size_t @var{length}}) This function is used by a server or a client to send @var{length} bytes of bulk data in @var{buffer} to the other end. The data will be escaped as required by the Assuan protocol and may get buffered until a line is full. To force sending the data out @var{buffer} may be passed as @code{NULL} and @var{length} be @code{0}. When used by a client this flush operation does also send the terminating @code{END} command to terminate the response on an ``INQUIRE'' response. Note that the function @code{assuan_transact} takes care of sending this @code{END} itself. @noindent This function returns @code{0} on success or an error code. @end deftypefun @c @c C L I E N T C O D E @c @node Client code @chapter How to develop an Assuan client Depending on the type of the server you want to connect you need to use different functions. For a pipe based server you fork and exec yourself, you use: @deftypefun assuan_error_t assuan_pipe_connect (@w{assuan_context_t *@var{ctx}},@w{const char *@var{name}}, @w{const char *const @var{argv}[]}, @w{int *@var{fd_child_list}}) A call to this functions forks the current process and executes the program @var{name}, passing the arguments given in the NULL-terminated list @var{argv}. A list of file descriptors not to be closed may be given using the @code{-1} terminated array @var{fd_child_list}. On success a new assuan context is returned at @var{ctx}. @end deftypefun If it is not a simple pipe server but one using full-duplex sockets, the full-fledged variant of the above function should be used: @deftypefun assuan_error_t assuan_pipe_connect_ext (@w{assuan_context_t *@var{ctx}},@w{const char *@var{name}}, @w{const char *const @var{argv}[]}, @w{int *@var{fd_child_list}}, @w{void (*@var{atfork}) (void *, int)}, @w{void *@var{atforkvalue}}, @w{unsigned int @var{flags}}) A call to this functions forks the current process and executes the program @var{name}, passing the arguments given in the NULL-terminated list @var{argv}. A list of file descriptors not to be closed may be given using the @code{-1} terminated array @var{fd_child_list}. If @var{name} as well as @var{argv} are given as @code{NULL}, only a fork but no exec is done. Thus the child continues to run. However all file descriptors are closed and some special environment variables are set. To let the caller detect whether the child or the parent continues, the child returns with a @var{ctx} set to @code{NULL}. If @var{atfork} is not NULL, this function is called in the child right after the fork and the value @var{atforkvalue} is passed as the first argument. That function should only act if the second argument it received is @code{0}. Such a fork callback is useful to release additional resources not to be used by the child. @var{flags} controls how the function acts: With a value of @code{0} it expects a simple pipe based server and behaves similar to @code{assuan_pipe_connect}. With a value of @code{1} a sever based on full-duplex pipes is expected. Such pipes are usually created using the @code{socketpair} function. It also enables features only available with such servers. @end deftypefun If you are using a long running server listening either on a TCP or a Unix domain socket, the following function is used to connect to the server: @deftypefun assuan_error_t assuan_socket_connect_ext (@w{assuan_context_t *@var{ctx}}, @w{const char *@var{name}}, @w{pid_t @var{server_pid}}, @w{unsigned int @var{flags}}) Make a connection to the Unix domain socket @var{name} and return a new Assuan context at @var{ctx}. @var{server_pid} is currently not used but may become handy in the future; if you don't know the server's pid, pass @code{-1}. With @var{flags} set to @code{1}, @code{sendmsg} and @code{recvmesg} are used for input and output and thereby enabling the the use of descriptor passing. Connecting to a TCP server is not yet implemented. Standard URL schemes are reserved for @var{name} specifying a TCP server. @end deftypefun @deftypefun assuan_error_t assuan_socket_connect (@w{assuan_context_t *@var{ctx}}, @w{const char *@var{name}}, @w{pid_t @var{server_pid}}) Same as above but no way to specify flags. @end deftypefun Finally, after using the Assuan connection, the resources should be deallocated: @deftypefun void assuan_disconnect (@w{assuan_context_t @var{ctx}}) Close the connection described by the Assuan context @var{ctx} and release all resources. This function also tries to send the BYE command to the server but won't fail on error. It is explicitly allowed to pass @code{NULL} for @var{ctx}, in which case the function does nothing. @end deftypefun Now that we have a connection to the server, all work may be conveniently done using a couple of callbacks and the transact function: @deftypefun assuan_error_t assuan_transact (@w{assuan_context_t @var{ctx}}, @w{const char *@var{command}}, @w{int (*@var{data_cb})(void *, const void *, size_t)}, @w{void *@var{data_cb_arg}}, @w{int (*@var{inquire_cb})(void*, const char *)}, @w{void *@var{inquire_cb_arg}}, @w{int (*@var{status_cb})(void*, const char *)}, @w{void *@var{status_cb_arg}}) Here @var{ctx} is the Assuan context opened by one of the connect calls. @var{command} is the actual one liner Assuan command. It shall not end with a line feed and its length is limited to @code{ASSUAN_LINELENGTH} (~1000 bytes) @var{data_cb} is called by Libassuan for data lines; @var{data_cb_arg} is passed to it along with the data and the length. [FIXME: needs more documentation]. @var{inquire_cb} is called by Libassuan when the server requests additional information from the client while processing the command. This callback shall check the provided inquiry name and send the data as requested back using the @code{assuan_write_data}. The server passed @var{inquiry_cb_arg} along with the inquiry name to the callback. @var{status_cb} is called by Libassuan for each status line it receives from the server. @var{status_cb_arg} is passed along with the status line to the callback. The function returns @code{0} success or an error code. The error code may be the one one returned by the server in error lines or one generated by the callback functions. @end deftypefun Libassuan supports descriptor passing on some platforms. The next two functions are used with this feature: @anchor{function assuan_sendfd} @deftypefun assuan_error_t assuan_sendfd (@w{assuan_context_t @var{ctx}}, @w{int @var{fd}}) Send the descriptor @var{fd} to the peer using the context @var{ctx}. Note, that calling this function with a @var{ctx} of @code{NULL} and @var{fd} of @code{-1} is a valid runtime test to check whether descriptor passing is available on the platform. The descriptor must be sent before the command is issued that makes use of the descriptor. @end deftypefun @anchor{fun-assuan_receivedfd} @deftypefun assuan_error_t assuan_receivefd (@w{assuan_context_t @var{ctx}}, @w{int *@var{fd}}) Receive a descriptor pending for the context @var{ctx} from the peer. The descriptor must be pending before this function is called. To accomplish this, the peer needs to use @code{assuan_sendfd} before the trigger is sent (e.g. using @code{assuan_write_line ("INPUT FD")}. @end deftypefun @c @c S E R V E R C O D E @c @node Server code @chapter How to develop an Assuan server Implementing a server for Assuan is a bit more complex than a client. However it is a straightforward task we are going to explain using a commented example. @noindent The list of the implemented server commands is defined by a table like: @smallexample static struct @{ const char *name; int (*handler)(assuan_context_t, char *line); @} command_table[] = @{ @{ "FOO", cmd_foo @}, @{ "BAR", cmd_bar @}, @{ "INPUT", NULL @}, @{ "OUTPUT", NULL @}, @{ NULL @}@}; @end smallexample For convenience this table is usually put after the actual command handlers (cmd_foo, cmd_bar) or even put inside the command_handler. Note that commands with the name ``INPUT'' and ``OUTPUT'' do not require a handler because Libassuan provides a default handler for them. It is however possible to assign a custom handler. A prerequisite for this example code is that a client has already connected to the server. Often there are two modes combined in one program: A pipe based server, where a client has forked the server process, or a Unix domain socket based server that is listening on the socket. @example void command_handler (int fd) @{ int i, rc; assuan_context_t ctx; if (fd == -1) @{ int filedes[2]; filedes[0] = 0; filedes[1] = 1; rc = assuan_init_pipe_server (&ctx, filedes); @} else rc = assuan_init_socket_server_ext (&ctx, fd, 2); if (rc) @{ fprintf (stderr, "server init failed: %s\n", gpg_strerror(rc)); return; @} @end example @noindent This is the first part of the command handler. In case this is called as a pipe based server, @var{fd} will be based as @code{fd} and the code assumes that the server's @code{stdin} and @code{stdout} file handles are connected to a pipe. The initialization is thus done using the function: @deftypefun assuan_error_t assuan_init_pipe_server (@w{assuan_context_t *@var{r_ctx}}, @w{int @var{filedes}[2]}) The function takes the two file descriptors from @var{filedes} and returns a new Assuan context at @var{r_ctx}. As usual, a return value of @code{0} indicates success and a failure is indicated by a returning an error code. In case of error, @code{NULL} will be stored at @var{r_ctx}. In case the server has been called using a bi-directional pipe (socketpair), @var{filedes} is ignored and the file descriptor is taken from the environment variable @env{_assuan_connection_fd}. You won't need to know that because @code{assuan_pipe_connect_ext}, used by the client to connect to such a server, automagically sets this variable. @end deftypefun @noindent If a file descriptor has been passed, the assuan context gets initialized by the function: @deftypefun assuan_error_t assuan_init_socket_server_ext (@w{assuan_context_t *@var{r_ctx}}, @w{int @var{fd}}, @w{unsigned int @var{flags}}) The function takes the file descriptor @var{fd} which is expected to be associated with a socket and returns a new Assuan context at @var{r_ctx}. The following bits are currently defined for @var{flags}: @table @code @item Bit 0 If set, @code{sendmsg} and @code{recvmesg} are used for input and output and thus enabling the use of descriptor passing. @item Bit 1 If set, @var{fd} refers to an already accepted socket. That is, Libassuan won't call @var{accept} for it. It is suggested to set this bit as it allows better control of the connection state. @end table As usual, a return value of @code{0} indicates success and a failure is indicated by a returning an error code. In case of error, @code{NULL} will be stored at @var{r_ctx}. @end deftypefun @noindent After error checking, the implemented assuan commands are registered with the server. @example for (i = 0; command_table[i].name; i++) @{ rc = assuan_register_command (ctx, command_table[i].name, command_table[i].handler); if (rc) @{ fprintf (stderr, "register failed: %s\n", gpg_strerror (rc)); assuan_deinit_server (ctx); return; @} @} @end example @deftypefun assuan_error_t assuan_register_command (@w{assuan_context_t @var{ctx}}, @w{const char *@var{cmd_string}}, @w{int (*@var{handler}) (assuan_context_t, char *)}) This registers the command named @var{cmd_string} with the Assuan context @var{ctx}. @var{handler} is the function called by Libassuan if this command is received from the client. @var{NULL} may be used for @var{handler} to use a default handler (this only works with a few pre-defined commands). Note that several default handlers have already been registered when the context has been created: ``NOP'', ``CANCEL'', ``OPTION'', ``BYE'', ``AUTH'', ``RESET'' and ``END''. It is possible, but not recommended, to override these commands. @end deftypefun @deftypefun assuan_error_t assuan_register_post_cmd_notify (@w{assuan_context_t @var{ctx}}, @w{void (*@var{fnc})(assuan_context_t)}, @w{int @var{err}}) Register a function to be called right after a command has been processed. @var{err} is the result code from the last internal assuan operation and not the one returned by the handler. It may be used for command-related cleanup. @end deftypefun @deftypefun assuan_error_t assuan_register_bye_notify (@w{assuan_context_t @var{ctx}}, @w{void (*@var{fnc})(assuan_context_t)}) Register function @var{fnc} with context @var{ctx} to be called right before the standard handler for the ``BYE'' command is being called. @end deftypefun @deftypefun assuan_error_t assuan_register_reset_notify (@w{assuan_context_t @var{ctx}}, @w{void (*@var{fnc})(assuan_context_t)}) Register function @var{fnc} with context @var{ctx} to be called right before the standard handler for the ``RESET'' command is being called. @end deftypefun @deftypefun assuan_error_t assuan_register_cancel_notify (@w{assuan_context_t @var{ctx}}, @w{void (*@var{fnc})(assuan_context_t)}) Register function @var{fnc} with context @var{ctx} to be called right before the standard handler for the ``RESET'' command is being called. @end deftypefun @deftypefun assuan_error_t assuan_register_option_handler (@w{assuan_context_t @var{ctx}}, @w{int (*@var{fnc})(assuan_context_t, const char*, const char*)}) Register function @var{fnc} with context @var{ctx} for processing options. That function is being called with the context, the name and the value of the option. Leading and trailing spaces are removed from the name and the value. The optional leading two dashes of the name are removed as well. If no value has been given, an empty string is passed. The function needs to return @code{0} on success or an error code. @end deftypefun @deftypefun assuan_error_t assuan_register_input_notify (@w{assuan_context_t @var{ctx}}, @w{void (*@var{fnc})(assuan_context_t, const char*)}) Although the input function may be overridden with a custom handler, it is often more convenient to use the default handler and to know whether an ``INPUT'' command has been seen and successfully parsed. The second argument passed to that function is the entire line. Because that line has already been parsed when the function gets called, a file descriptor set with the ``INPUT'' command may already be used. That file descriptor is available by calling @code{assuan_get_input_fd}. @end deftypefun @deftypefun assuan_error_t assuan_register_output_notify (@w{assuan_context_t @var{ctx}}, @w{void (*@var{fnc})(assuan_context_t, const char*)}) Although the output function may be overridden with a custom handler, it is often more convenient to use the default handler and to know whether an ``OUTPUT'' command has been seen and successfully parsed. The second argument passed to that function is the entire line. Because that line has already been parsed when the function gets called, a file descriptor set with the ``OUTPUT'' command may already be used. That file descriptor is available by calling @code{assuan_get_output_fd}. @end deftypefun @deftypefun assuan_error_t assuan_set_hello_line (@w{assuan_context_t @var{ctx}}, @w{const char *@var{line}}) This is not actually a register function but may be called also after registering commands. It changes the ``Hello'' line, sent by the server to the client as a first response, from a default string to the string @var{line}. For logging purposes, it is often useful to use such a custom hello line which may tell version numbers and such. Linefeeds are allowed in this string, however, each line needs to be shorter than the Assuan line length limit. @end deftypefun @noindent As a last initialization step, debugging may be enabled for the current connection. This is done using @deftypefun void assuan_set_log_stream (@w{assuan_context_t @var{ctx}}, @w{FILE *@var{fp}}) Enable debugging for the context @var{ctx} and write all debugging output to the stdio stream @var{fp}. If the default log stream (used for non-context specific events) has not yet been set, a call to this functions implicitly sets this stream also to @var{fp}. @end deftypefun @noindent Now that everything has been setup, we can start to process our clients requests. @example for (;;) @{ rc = assuan_accept (ctx); if (rc == -1) break; else if (rc) @{ fprintf (stderr, "accept problem: %s\n", gpg_strerror (rc)); break; @} rc = assuan_process (ctx); if (rc) @{ fprintf (stderr, "processing failed: %s\n", gpg_strerror (rc)); continue; @} @} assuan_deinit_server (ctx); @} @end example @noindent For future extensibility and to properly detect the end of the connection the core of the server should loop over the accept and process calls. @deftypefun assuan_error_t assuan_accept (@w{assuan_context_t @var{ctx}}) A call to this function cancel any existing connection and waits for a connection from a client (that might be skipped, depending on the type of the server). The initial handshake is performed which may include an initial authentication or encryption negotiation. On success @code{0} is returned. An error code will be returned if the connection could for some reason not be established. An error code of @code{-1} indicates the end of the connection. @end deftypefun @deftypefun assuan_error_t assuan_process (@w{assuan_context_t @var{ctx}}) This function is used to handle the Assuan protocol after a connection has been established using @code{assuan_accept}. It is the main protocol handler responsible for reading the client commands and calling the appropriate handlers. The function returns @code{0} on success or an error code if something went seriously wrong. Error codes from the individual command handlers, i.e. operational error, are not seen here. @end deftypefun @noindent After the loop has terminated, the Assuan context needs to be released: @deftypefun void assuan_deinit_server (@w{assuan_context_t @var{ctx}}) Releases the resources described by the Assuan context @var{ctx} It is explicitly allowed to pass @code{NULL} for @var{ctx}, in which case the function does nothing. @end deftypefun @noindent That is all needed for the server code. You only need to come up with the code for the individual command handlers. Take care that the line passed to the command handlers is allocated statically within the context and calls to Assuan functions may modify that line. You are also allowed to modify that line which makes parsing much easier. @c @c E x t e r n a l I / O L o o p s @c @node External I/O Loop @chapter How to use external I/O event loops The above implementations of an Assuan client and server are synchronous, insofar the main routines block until a request or client connection is completely processed. In some programs, for example GUI applications, this is undesirable. Instead, Assuan operations should be non-blocking, and the caller should be able to poll all involved file descriptors to determine when the next Assuan function can be invoked without blocking. To make this possible, client and server have to adhere to some rules: @itemize @bullet @item Either partner should always write full lines. If partial lines are written, the remainder of the line should b sent without delay. @item Either partner should eagerly receive status messages. While receiving and sending bulk data may be delayed, the status communication channel is different: Both partners may send status messages in blocking mode at any time the protocol allows them to send such status messages. To ensure that these send operations do not actually block the sender, the recipient must be ready to receive without undue delay. @item If descriptor passing is used over a socket, the descriptor must be sent after the corresponding command without undue delay. @end itemize Together, these restrictions allow to limit the need for asynchronous I/O operations to bulk data and the inbound status file descriptor. In addition to the above rules, client and server should adhere to the following implementation guidelines. @menu * External I/O Loop Client:: External I/O event loops in the client. * External I/O Loop Server:: External I/O event loops in the server. @end menu @node External I/O Loop Client @section External I/O event loops in the client. The reference implementation for using external I/O event loops in the client is the GPGME library, which exports its own external I/O event loop mechanism and utilizes the Assuan library transparently for the user. The following steps document how GPGME achieves this. @enumerate @item Before connecting, set up pipes for bulk data transfer (using the INPUT/OUTPUT commands, for example). These are passed to the server either by inheritance (using a pipe server) or by FD passing (using a socket server). @item Then you need to connect to the server. GPGME uses a pipe server, so it just spawns a server process, which is a non-blocking operation. FIXME: Currently, using a client with external event loop over a socket connection is not supported. It is easy to support (we just need a variation of @code{assuan_socket_connect} which takes an already connected socket FD and turns it into an Assuan context), so if you need this let us know. @item After connecting, get the inbound status FD with @code{assuan_get_active_fds} (the first one returned is the status FD). This FD can be duplicated if it is convenient (GPGME does this to be able to close this FD and associated callback handlers without disrupting Assuan's internals). @item Then register the Assuan inbound status FD and all bulk data FDs with the I/O event mechanism. In general, this requires setting up callback handlers for these FDs and registering them with the main event loop. @item When bulk data FDs become ready, you can simply perform the corresponding read or write operations. When the inbound status FD becomes ready, you can receive the next server line with assuan_read_line(). @item You should close and unregister the bulk data FDs when you wrote all data (for outbound FDs) or receive an EOF (for inbound FDs). When you receive an ERR from the server, or an OK for the final operation, you can unregister the inbound status FD and call @code{assuan_disconnect} to close it. @item As noted above, all send operations on the outbound status FD are done immediate with blocking. In GPGME, this has never caused any problems. @item The @code{INQUIRE} function can be handled in two ways: If the requested data is immediately available, the client can just send the data blockingly. If the requested data needs to be fetched from a blocking source, a callback handler can be registered for the FD with the main event loop. GPGME does not support the @code{INQUIRE} function, so we do not have any practical experience with this. @end enumerate Currently, the client can not cancel a pending operation gracefully. It can, however, disconnect from the server at any time. It is the responsibility of the server to periodically send status messages to the client to probe if the connection remains alive. @node External I/O Loop Server @section External I/O event loops in the server. Currently, no Assuan server exists which uses external I/O event loops. However, the following guidelines should lead to a usable implementation: @enumerate @item For socket servers: You can not use @code{assuan_accept}, so you should just implement the bind/connect/listen/accept stage yourself. You can register the listen FD with your main event loop, accept the connection when it becomes ready, and finally call @code{assuan_init_socket_server_ext} with the final argument being 2 to create an Assuan context for this connection. This way you can also handle multiple connections in parallel. The reference implementation for this approach is DirMngr. For pipe servers: @code{assuan_init_pipe_server} creates an Assuan context valid for the pipe FDs. @item Once you have a context for a single connection, you can get the inbound status FD with @code{assuan_get_active_fds} (the first one returned is the status FD). This FD can be duplicated if it is convenient. Every time the inbound status FD is readable, you should invoke the function @code{assuan_process_next} (see below) to process the next incoming message. @code{assuan_process_next} processes as many status lines as can be received by a single @code{read} operation. When it returns, the inbound status FD may still be readable, but Assuan does not check this. The function @code{assuan_process_next} returns 0 if it can not make progress reliably, and it returns an end of file error code if the client closed the connection. See below for more information on this function. @item The command will be dispatched by @code{assuan_process_next} just as with @code{assuan_process}, however, you will want to implement the command handlers in such a way that they do not block. For example, the command handler may just register the bulk data FDs with the main event loop and return. When the command is finished, irregardless if this happens directly in the command handler or later, you must call @code{assuan_process_done} with an appropriate error code (or 0 for success) to return an appropriate status line to the client. You can do this at the end of the command handler, for example by ending it with @code{return assuan_process_done (error_code);}. Another possibility is to invoke @code{assuan_process_done} from the place in the code which closes the last active bulk FD registered with the main event loop for this operation. @end enumerate It is not possible to use @code{assuan_inquire} in a command handler, as this function blocks on receiving the inquired data from the client. Instead, the asynchronous version @code{assuan_inquire_ext} needs to be used (see below), which invokes a callback when the client provided the inquired data. A typical usage would be for the command handler to register a continuation with @code{assuan_inquire_ext} and return 0. Eventually, the continuation would be invoked by @code{assuan_process_next} when the client data arrived. The continuation could complete the command and eventually call @code{assuan_process_done}. Cancellation is supported by returning an appropriate error code to the client with @code{assuan_process_done}. For long running operations, the server should send progress status messages to the client in regular intervals to notice when the client disconnects. @deftypefun assuan_error_t assuan_process_next (@w{assuan_context_t @var{ctx}}) This is the same as @code{assuan_process} but the caller has to provide the outer loop. He should loop as long as the return code is zero and stop otherwise; @code{-1} or @code{GPG_ERR_EOF} indicate a regular end. @end deftypefun @deftypefun assuan_error_t assuan_inquire_ext (@w{assuan_context_t @var{ctx}}, @w{const char *@var{keyword}}, @w{unsigned char **@var{r_buffer}}, @w{size_t *@var{r_length}}, @w{size_t @var{maxlen}}, @w{int (*@var{cb}) (void *cb_data, int rc)}, @w{void *@var{cb_data}}) This is the same as @code{assuan_inquire} but the caller has to provide the outer loop (using @code{assuan_process_next}). The caller should specify a continuation with @var{cb}, which receives @var{cb_data} as its first argument. @end deftypefun @c @c U T I L I T I E S @c @node Utilities @chapter Utility functions @noindent There are a lot of helper functions to make writing Assuan code easier. Some of these functions provide information not available with the general functions. @deftypefun void assuan_set_pointer (@w{assuan_context_t @var{ctx}}, @w{void *@var{pointer}}) Store the arbitrary pointer value @var{pointer} into the context @var{ctx}. This is useful to provide command handlers with additional application context. @end deftypefun @deftypefun void* assuan_get_pointer (@w{assuan_context_t @var{ctx}}) This returns the pointer for context @var{ctx} which has been set using the above function. A common way to use it is by setting the pointer before starting the processing loop and to retrieve it right at the start of a command handler: @smallexample static int cmd_foo (assuan_context_t ctx, char *line) @{ ctrl_t ctrl = assuan_get_pointer (ctx); ... @} @end smallexample @end deftypefun @deftypefun assuan_error_t assuan_write_status (@w{assuan_context_t @var{ctx}}, @w{const char *@var{keyword}}, @w{const char *@var{text}}) This is a convenience function for a server to send a status line. You need to pass it the @var{keyword} and the content of the status line in @var{text}. @end deftypefun @deftypefun assuan_error_t assuan_inquire (@w{assuan_context_t @var{ctx}}, @w{const char *@var{keyword}}, @w{unsigned char **@var{r_buffer}}, @w{size_t *@var{r_length}}, @w{size_t @var{maxlen}}) A server may use this function to inquire data from a client. It sends an ``INQUIRE'' command back to the server and returns the response conveniently in a newly allocated buffer. You need to pass at least the server's context @var{ctx} and the @var{keyword} describing the requested data. All other parameters may be @code{NULL} or @code{0}, although this is rarely useful. On success the result is stored in a newly allocated buffer stored at @var{r_buffer}. The length of the data is stored at @var{r_length}. If @var{maxlen} has not been given as @code{0}, it describes an upper size limited of the expected data. If the client returns too much data the function fails and the error code @code{GPG_ERR_ASS_TOO_MUCH_DATA} will be returned. @end deftypefun @deftypefun FILE* assuan_get_data_fp (@w{assuan_context_t @var{ctx}}) Return a stdio stream for the Assuan context @var{ctx}. This stream may then be used for data output (assuan_write_data). The stream is valid until the end of the current handler. Calling @code{fclose} for that stream is not required. Assuan does all the buffering needed to insert the status line as well as the required line wrapping and quoting for data lines. This function is only available on systems supporting either @code{funopen} or @code{fopencookie}. If it is not supported @code{NULL} is returned and @code{errno} is set to @code{ENOSYS}. @end deftypefun @deftypefun assuan_error_t assuan_set_okay_line (@w{assuan_context_t @var{ctx}}, @w{const char *@var{line}}) Set the text used for the next ``OK'' response to @var{line}. This is sometimes useful to send additional human readable information along with the OK line. The string is automatically reset at the end of the current handler. @end deftypefun @deftypefun assuan_error_t assuan_command_parse_fd (@w{assuan_context_t @var{ctx}}, @w{char *@var{line}}, @w{int *@var{rfd}}) This is the core of the default ``INPUT'' and ``OUTPUT'' handler. It may be used in custom commands as well to negotiate a file descriptor. If @var{line} contains @code{FD=@var{n}}, it returns @var{n} in @var{rfd} assuming a local file descriptor. If @var{line} contains just @code{FD} it returns a file descriptor at @var{rfd}; this file descriptor needs to have been sent by the client right before using @code{assuan_sendfd}. On W32 systems the returned file descriptor is a system handle and not a libc low level I/O file descriptor. Thus applications need to use @code{_open_osfhandle} before they can pass this descriptor to standard functions like @code{fdopen} or @code{dup}. @end deftypefun @deftypefun int assuan_get_input_fd (@w{assuan_context_t @var{ctx}}) Return the file descriptor sent by the client using the last ``INPUT'' command. Returns @code{-1} if no file descriptor is available. @end deftypefun @deftypefun int assuan_get_output_fd (@w{assuan_context_t @var{ctx}}) Return the file descriptor sent by the client using the last ``OUTPUT'' command. Returns @code{-1} if no file descriptor is available. @end deftypefun @deftypefun assuan_error_t assuan_close_input_fd (@w{assuan_context_t @var{ctx}}) Close the file descriptor set by the last ``INPUT'' command. This function has the advantage over a simple @code{close} that it can do some sanity checks and make sure that a following @code{assuan_get_input_fd} won't return an already closed descriptor. @end deftypefun @deftypefun assuan_error_t assuan_close_output_fd (@w{assuan_context_t @var{ctx}}) Close the file descriptor set by the last ``OUTPUT'' command. This function has the advantage over a simple @code{close} that it can do some sanity checks and make sure that a following @code{assuan_get_input_fd} won't return an already closed descriptor. @end deftypefun @deftypefun int assuan_set_error (@w{assuan_context_t @var{ctx}}, @w{int @var{err}}, @w{const char *@var{text}}) This is a helper to provide a more descriptive error text with ``ERR'' lines. For this to work, the text needs to be stored in the context @var{ctx} while still being in the command handler. This function is commonly called this way @smallexample return assuan_set_error (ctx, err, "commands needs 5 arguments"); @end smallexample The value @var{err} is passed through and thus the return value of the command handler in the example. The provided text further explains that error code to humans. @end deftypefun @deftypefun void assuan_set_flag (@w{assuan_context_t @var{ctx}}, @w{assuan_flag_t @var{flag}}, @w{int @var{value}}) Set the the @var{flag} for context @var{ctx} to @var{value}. Values for flags are usually 1 or 0 but certain flags might need other values. @deftp {Data type} assuan_flag_t The flags are all named and collected in an @code{enum} for better readability. Currently only one flag is defined: @table @code @item ASSUAN_NO_WAITPID When using a pipe server, by default Libassuan will wait for the forked process to die in @code{assuan_disconnect}. In certain cases this is not desirable. By setting this flag, a call to @code{waitpid} will be suppressed and the caller is responsible to cleanup the child process. @item ASSUAN_CONFIDENTIAL Uses to return the state of the confidential logging mode. For changing this mode the functions @code{assuan_begin_confidential} and @code{assuan_end_confidential} should be used. @end table @end deftp @end deftypefun @deftypefun int assuan_get_flag (@w{assuan_context_t @var{ctx}}, @w{assuan_flag_t @var{flag}}) Return the value of @var{flag} in context @var{ctx}. @end deftypefun @deftypefun @w{const char*} assuan_strerror (@w{assuan_error_t @var{err}}) This function returns a textual representation of the given error code @var{err}. If this is an unknown value, a string with the value is returned. (Beware: it is hold in a static buffer). It is suggested that gpg-error style error numbers should be used and thus @code{gpg_strerror} be called. @xref{function assuan_set_assuan_err_source}, on how to enable these error codes. @end deftypefun @deftypefun pid_t assuan_get_pid (@w{assuan_context_t @var{ctx}}) This function returns the pid of the connected connected peer. If that pid is not known @code{-1} is returned. Note that it is not always possible to learn the pid of the other process. For a pipe based server the client knows it instantly and a mechanism is in place to let the server learn it. For socket based servers the pid is only available on systems providing the ``SO_PEERCRED'' socket option @footnote{to our knowledge only the Linux kernel has this feature}. @end deftypefun @deftypefun assuan_error_t assuan_get_peercred (@w{assuan_context_t @var{ctx}}, @w{pid_t *@var{pid}}, @w{uid_t *@var{uid}}, @w{gid_t *@var{pid}}) Return user credentials of the peer. This will work only on certain systems and only when connected over a socket. If you are not interested in some of the values, pass @code{NULL} instead of the address of an appropriate variable. @var{pid}, @var{uid} and @var{gid} are only set if the function succeeds and returns with @code{0}. As of now only the server is able to retrieve this information. Note, that for getting the pid of the peer @code{assuan_get_pid} is usually better suited. @end deftypefun @deftypefun int assuan_get_active_fds (@w{assuan_context_t @var{ctx}}, @w{int @var{what}}, @w{int *@var{fdarray}}, @w{int @var{fdarraysize}}) Return all active file descriptors for the context @var{ctx}. This function can be used to select on the file descriptors and to call @code{assuan_process_next} if there is an active one. The first descriptor in the array is the one used for the command connection. Currently @var{what} needs to be @code{0} to return descriptors used for reading, @code{1} will eventually be used to return descriptors used for writing. @var{fdarray} is an array of integers provided by the caller; @var{fdarraysize} gives the size of that array. On success the number of active descriptors are returned. These active descriptors are then stored in @var{fdarray}. On error @code{-1} is returned; the most likely reason for this is a too small @var{fdarray}. Note that on W32 systems the returned file descriptor is a system handle and not a libc low level I/O file descriptor. @end deftypefun @deftypefun int assuan_pending_line (@w{assuan_context_t @var{ctx}}) A call to this function return true if a full line has been buffered and thus an entire assuan line may be read without triggering any actual I/O. @end deftypefun @deftypefun void assuan_set_io_monitor (@w{assuan_context_t @var{ctx}}, @w{unsigned int} (*@var{monitor})(@w{assuan_context_t @var{ctx}}, @w{int @var{direction}}, @w{const char *@var{line}}, @w{size_t @var{linelen}})) This function registers an I/O monitor for the context @var{ctx}. Such a monitor function is called right after a line has been received or just before it is send. With @var{direction} set to 1 the monitor has been called for an output operation; 0 obviosuly means it has been called for an input operation. If the monitor sets bit 0 in the return value, any active logging of the line will be suppressed. With bit 1 set, the entire line will be ignored. @end deftypefun @deftypefun void assuan_begin_confidential (@w{assuan_context_t @var{ctx}}) Put the logging feature into confidential mode. This is to avoid logging of sensitive data. @end deftypefun @deftypefun void assuan_end_confidential (@w{assuan_context_t @var{ctx}}) Get the logging feature out of confidential mode. All data will be logged again (if logging is enabled). @end deftypefun @deftypefun FILE* assuan_get_assuan_log_stream (void) Return the stream which is currently being using for global logging. @end deftypefun @deftypefun @w{const char*} assuan_get_assuan_log_prefix (void) Return the prefix to be used at the start of a line emitted by assuan on the log stream. The default implementation returns the empty string. @end deftypefun @c --------------------------------------------------------------------- @c Legal BS @c --------------------------------------------------------------------- @include lgpl.texi @include gpl.texi @c --------------------------------------------------------------------- @c Indexes @c --------------------------------------------------------------------- @node Index @unnumbered Index @printindex cp @c --------------------------------------------------------------------- @c Epilogue @c --------------------------------------------------------------------- @bye