     [file version.texi not included]

This file documents the use and the internals of Assuan.

This is Edition EDITION, last updated UPDATED, of The `Developing with Assuan' Manual, for Version VERSION.

Published by the Free Software Foundation

51 Franklin Street, Fifth Floor

Boston, MA 02110-1301 USA

Copyright © 2001--2013 Free Software Foundation, Inc.

Copyright © 2001--2015 g10 Code GmbH

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''.

Introduction
************

This manual documents how to exploit the Assuan library, a simple interprocess communcation library.

Introduction to Assuan
**********************

Assuan is an extensible inter-process communication (IPC) protocol and library.  It is designed for point-to-point communication and it doesn't provide a naming system.  To contact a server, either the client must know how to locate the server, e.g., via a well-known Unix domain socket, or, if the server is transient, how to start it.  In the latter case, Assuan provides functionality to start the server process.

In Assuan, communication is typically either via a pipe or a 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 a significant amount of data is MEMCPYed 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 is useful: the client is separated from the server: they run 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.

Description of the Assuan protocol.
***********************************

The architecture of the modular GnuPG system is based on several highly specialized modules which form a network of clients and servers.  A common framework for intermodule communication is therefore needed and implemented as a library.

Goals:

  * Common framework for module communication

  * Easy debugging

  * Easy module testing

  * Extensible

  * Optional authentication and encryption facility

  * Usable to access external hardware

Design criteria:

  * Client/Server with back channel

  * Use a mainly text based protocol

  * Escape certain control characters

  * Allow indefinite data length

  * Request confidentiality for parts of the communication

  * Dummy module to allow direct linking of client and server

  * Inline data or descriptor passing for bulk data

  * No protection against DoS needed

  * Subliminal channels are not an issue

Implementation
**************

The implementation is line based with a maximum line size of 1000 octets.  The default IPC mechanism is Unix Domain Sockets.

On connect, the server responds either with okay or an error status. To perform an authentication check, the server may send an Inquiry response prior to the first Okay.  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 with the server's credentials.  This avoids attacks based on wrong socket permissions.

The server may choose to delay the first response in case of an error. The server, however, never closes the connection, however, the lower protocol may do so after some time of inactivity or when the connection enters an error state.

All textual messages are assumed to be in UTF-8 unless otherwise noted.

Server responses
================

OK  [<arbitrary debugging information>]
     Request was successful.

ERR ERRORCODE [<human readable error description>]
     Request could not be fulfilled.  The possible error codes are defined by libgpg-error.

S KEYWORD <status information depending on keyword>
     Informational output by the server, which is still processing the request.  A client may not send such lines to the server while processing an Inquiry command.  KEYWORD shall start with a letter or an underscore.

# <string>
     Comment line issued only for debugging purposes.  Totally ignored.

D <raw data>
     Raw data returned to client. There must be exactly one space after the 'D'.  The values for '%', CR and LF must be percent escaped; these are encoded as %25, %0D and %0A, respectively.  Only uppercase letters should be used in the hexadecimal representation.  Other characters may be percent escaped for easier debugging.  All 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.

INQUIRE KEYWORD <parameters>
     The server needs further information from the client.  The client should respond with data (using the ``D'' command and terminated by ``END'').  Alternatively, the client may cancel the current operation by responding with ``CAN''.

Consider the following examples (lines prefixed with S indicate text that the server sends; lines prefixed with C indicate text that the client sends):

     S: INQUIRE foo
     C: D foo bar
     C: D bar baz
     C: END
     [Server continues normal work]

This implements a callback to the client:

     S: INQUIRE foo
     C: END
     [Server continues]

and:

     S: INQUIRE foo
     C: CAN
     [Server terminates the operaion and in most cases returns an ERR to the client.]

But, CAN may also mean ``I have no data for you, try to get it from elsewhere.''

Note: lines longer 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.)

Client requests
===============

The server waits for client requests after sending an Okay or Error. The client should not issue a request in other cases.

     COMMAND <parameters>

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 pair 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 unescaped (i.e., literal) 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.

     D <raw data>

Sends raw data to the server.  There must be exactly one space after the 'D'.  The values for '%', CR and LF must be percent escaped. These are encoded as %25, %0D and %0A, respectively.  Only uppercase letters should be used in the hexadecimal representation.  Other characters may be percent escaped for easier debugging.  All 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.

     END

Lines beginning with a # 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 supported by the Assuan library:

BYE
     Close the connection.  The server will respond with OK.

RESET
     Reset the connection but not any existing authentication.  The server should release all resources associated with the connection.

END
     Used by a client to mark the end of raw data.  The server may send END to indicate a partial end of data.

HELP
     Lists all commands that the server understands as comment lines on the status channel.

QUIT
     Reserved for future extensions.

OPTION
     Set options for the connection.  The syntax of such a line is

            OPTION NAME [ [=] VALUE ]

     Leading and trailing spaces around NAME and VALUE are allowed but should be ignored.  For compatibility reasons, NAME may be prefixed with two dashes.  The use of the equal sign is optional but suggested if VALUE is given.

CANCEL
     This command is reserved for future extensions.

AUTH
     This command is reserved for future extensions.  Not yet specified as we don't implement it in the first phase.  See Werner's mail to gpa-dev on 2001-10-25 about the rationale for measurements against local attacks.

NOP
     No operation.  Returns OK without any action.

Error codes
===========

Libassuan is used with gpg-error style error codes.  It is recommended to set the error source to a different value from the default GPG_ERR_SOURCE_UNKNOWN by calling function assuan_set_gpg_err_source early.

Preparation
***********

To use ASSUAN, you have to make some changes to your sources and the build system.  The necessary changes are small and explained in the following sections.

Header
======

All interfaces (data types and functions) of libassuan are defined in the header file assuan.h.  You must include this in all source files using the library, either directly or through some other header file, like this:

     #include <assuan.h>

The namespace of libassuan is assuan_* for function and type names and 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.

Because libassuan makes use of the GPG Error library, using libassuan will also use the GPG_ERR_* namespace directly, and the gpg_err* and gpg_str* namespaces indirectly.

Building sources
================

If you want to compile a source file including the 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 -I option).

However, the path to the include file is determined at the time the source is configured.  To solve this problem, libassuan ships with a small helper program 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 --cflags option to libassuan-config.  The following example shows how it can be used at the command line:

     gcc -c foo.c $(libassuan-config --cflags)

Adding the output of libassuan-config --cflags to the compiler's command line will ensure that the compiler can find the 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 -L option).  For this, the option --libs to libassuan-config can be used.  For convenience, this option also outputs all other options that are required to link the program with the libassuan libraries (in particular, the -lassuan option).  The example shows how to link foo.o with the libassuan library to a program foo.

     gcc -o foo foo.o $(libassuan-config --libs)

You can also combine both examples to a single command by specifying both options to libassuan-config:

     gcc -o foo foo.c $(libassuan-config --cflags --libs)

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 libassuan-config script at all.  libassuan provides an Automake macro that does all the work for you.

 -- Macro: AM_PATH_LIBASSUAN ([minimum-version], [action-if-found], [action-if-not-found])
     Check whether libassuan (at least version MINIMUM-VERSION, if given) exists on the host system.  If it is found, execute ACTION-IF-FOUND, otherwise do ACTION-IF-NOT-FOUND, if given.

     Additionally, the function defines LIBASSUAN_CFLAGS to the flags needed for compilation of the program to find the assuan.h header file, and LIBASSUAN_LIBS to the linker flags needed to link the program to the libassuan library.

You can use the defined Autoconf variables like this in your Makefile.am:

     AM_CPPFLAGS = $(LIBASSUAN_CFLAGS)
     LDADD = $(LIBASSUAN_LIBS)

Multi Threading
===============

The libassuan library is designed so that it can be used in a threaded application, if some rules are followed.

  * Run the initialization functions before you actually start to use threads.  Specifically, the functions assuan_set_gpg_err_source, assuan_set_malloc_hooks and assuan_set_log_cb should not be called concurrently with assuan_new.  Use assuan_new_ext instead or ensure proper serialization.

  * Only one thread at a time may access an libassuan context.

  * If you use the default log handler, use assuan_set_assuan_log_stream to setup a default log stream.

  * If you have callback functions shared by multiple functions, the callback function must be reentrant for that purpose. libassuan does not serialize invocation of callback functions across contexts.

Generalities
************

Data Types used by the library
==============================

ASSUAN uses a so-called context to store a connection's state. The following data type is used for that:

 -- Data type: assuan_context_t
     The assuan_context_t type is a pointer to an object maintained internally by the library.  Contexts are allocated with assuan_new or assuan_new_ext and released with assuan_release.  Other functions take this data type to access the state created by these functions.

 -- Data type: assuan_fd_t
     The assuan_fd_t is a file descriptor (in Unix) or a system handle (in Windows).  The special value ASSUAN_INVALID_FD is used to specify invalid Assuan file descriptors.

 -- Function: assuan_fd_t assuan_fdopen (int FD)
     Create an assuan file descriptor from a POSIX (libc) file descriptor FD.  On Unix, this is equivalent to dup, while on Windows this will retrieve the underlying system handle with _get_osfhandle and duplicate that.

Initializing the library
========================

Libassuan makes use of Libgpg-error and assumes that Libgpg-error has been initialized.  In general gpgrt_check_version should be called to guarantee this; the Libgpg-error manual for details.

Libassuan itself 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.

These functions initialize default values that are used at context creation with assuan_new.  As there can only be one default, all values can also be set directly with assuan_new_ext or with context-specific functions after context creation.

If your application uses its own memory allocation functions or wrappers it is good idea to tell libassuan about it so it can make use of the same functions or wrappers:

 -- Data type: struct assuan_malloc_hooks
     This structure is used to store the memory allocation callback interface functions.  It has the following members, whose semantics are identical to the corresponding system functions:

     void *(*malloc) (size_t cnt)
          This is the function called by ASSUAN to allocate memory for a context.

     void *(*realloc) (void *ptr, size_t cnt)
          This is the function called by ASSUAN to reallocate memory for a context.

     void (*free) (void *ptr)
          This is the function called by ASSUAN to release memory for a context.

 -- Data type: assuan_malloc_hooks_t
     This is a pointer to a struct assuan_malloc_hooks.

 -- Function: void assuan_set_malloc_hooks (assuan_malloc_hooks_t MALLOC_HOOKS)
     This function sets the default allocation hooks for new contexts allocated with assuan_new.  You need to provide all three functions.  Those functions need to behave exactly as their standard counterparts malloc, realloc and free.  If you write your own functions, please take care to set errno whenever an error has occurred.

 -- Function: assuan_malloc_hooks_t assuan_get_malloc_hooks ()
     This function gets the default allocation hooks for new contexts allocated with assuan_new.  The result structure is statically allocated and should not be modified.

The ASSUAN library uses libgpg-error error values, which consist and error code and an error source.  The default source used by contexts allocated with assuan_new can be set with the following function.

 -- Function: void assuan_set_gpg_err_source (gpg_err_source_t ERR_SOURCE)
     This function sets the default error source for errors generated by contexts allocated with assuan_new.

     One way to call this function is

          assuan_set_gpg_err_source (GPG_ERR_SOURCE_DEFAULT);

 -- Function: gpg_err_source_t assuan_get_gpg_err_source (void)
     This function gets the default error source for errors generated by contexts allocated with assuan_new.

To integrate assuan logging and diagnostics into your own logging system, you may use the following two functions:

 -- Data type: int (*assuan_log_cb_t) (assuan_context_t CTX, void *HOOK_VALUE, unsigned int CAT, const char *MSG)
     The user-provided callback function takes a context CTX, for which the message MSG was generated, and a hook value HOOK_VALUE that was supplied when the log handler was registered for the context with assuan_set_log_cb, and a category CAT.  The category is one of:

     ASSUAN_LOG_INIT

     ASSUAN_LOG_CTX

     ASSUAN_LOG_ENGINE

     ASSUAN_LOG_DATA
          RFU

     ASSUAN_LOG_SYSIO
          Log lowlevel I/O data.

     ASSUAN_LOG_CONTROL
          Log the control channel.

     The user may then, depending on the category, write the message to a log file or treat it in some other way.

     If MSG is a null pointer, then no message should be logged, but the function should return 1 if it is interested in log messages with the category CAT.  If it is not interested, 0 should be returned.  This allows libassuan to suppress the generation of expensive debug output.

 -- Function: void assuan_set_log_cb (assuan_log_cb_t LOG_CB, void *LOG_CB_DATA)
     This function sets the default logging handler for log messages generated by contexts allocated with assuan_new.

 -- Function: void assuan_get_log_cb (assuan_log_cb_t *LOG_CB, void **LOG_CB_DATA)
     This function gets the default logging handler for log messages generated by contexts allocated with assuan_new.

You do not need to set a log handler, as ASSUAN provides a configurable default log handler that should be suitable for most purposes.  Logging can be disabled completely by setting the log handler to a null pointer.

Default Log Handler
===================

The default log handler can be configured by the following functions:

 -- Function: void assuan_set_assuan_log_prefix (const char *TEXT)
     Set the prefix to be used at the start of a line emitted by assuan on the log stream to TEXT.  The default is the empty string.

 -- Function: 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.

 -- Function: void assuan_set_assuan_log_stream (FILE *FP)
     This sets the default log stream to which libassuan should log messages not associated with a specific context to FP.  The default is to log to stderr.  This default value is also changed by using 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.

 -- Function: FILE * assuan_get_assuan_log_stream (void)
     Return the stream which is currently being using for global logging.

The log stream used by the default log handler can also be set on a per context basis.

 -- Function: void assuan_set_log_stream (assuan_context_t CTX, FILE *FP)
     Enable debugging for the context CTX and write all debugging output to the stdio stream 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 FP.

How to work with contexts
=========================

Some operations work globally on the library, but most operate in a context, which saves state across operations.  To allow the use of libassuan in mixed environments, such as in a library using GPGME and an application using GPGME, the context is very extensive and covers utilitary information like memory allocation callbacks as well as specific information associated with client/server operations.

 -- Function: gpg_error_t assuan_new (assuan_context_t *CTX_P)
     The function assuan_new creates a new context, using the global default memory allocation, log handler and libgpg-error source. It is equivalent to

          gpg_error_t err;
          assuan_log_cb_t log_cb;
          void *log_cb_data;

          assuan_get_log_cb (&log_cb, &log_cb_data);
          err = assuan_new_ext (ctx_p, assuan_get_gpg_err_source (),
                                assuan_get_malloc_hooks (), log_cb, log_cb_data);

     As you can see, this is not thread-safe.  Take care not to modify the memory allocation hooks or log callback handler concurrently with assuan_new.

     The function returns an error if a memory allocation error occurs, and 0 with the new context in CTX_P otherwise.

 -- Function: gpg_error_t assuan_new_ext (assuan_context_t *CTX_P, gpg_err_source_t ERR_SOURCE, assuan_malloc_hooks_t MALLOC_HOOKS, assuan_log_cb_t LOG_CB, void *LOG_CB_DATA)
     The function assuan_new_ext creates a new context using the supplied libgpg-error error source ERR_SOURCE, the memory allocation hooks MALLOC_HOOKS and the log handler LOG_CB with the user data LOG_CB_DATA.

After the context has been used, it can be destroyed again.

 -- Function: void assuan_release (assuan_context_t ctx)
     The function assuan_release destroys the context CTX and releases all associated resources.

Other properties of the context beside the memory allocation handler, the log handler, and the libgpg-error source can be set after context creation.  Here are some of them:

 -- Function: void assuan_set_pointer (assuan_context_t CTX, void *POINTER)

     Store the arbitrary pointer value POINTER into the context CTX.  This is useful to provide command handlers with additional application context.

 -- Function: void* assuan_get_pointer (assuan_context_t CTX)

     This returns the pointer for context 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:

          static int
          cmd_foo (assuan_context_t ctx, char *line)
          {
            ctrl_t ctrl = assuan_get_pointer (ctx);
            ...
          }

 -- Function: void assuan_set_flag (assuan_context_t CTX, assuan_flag_t FLAG, int VALUE)

     Set the the FLAG for context CTX to VALUE.  Values for flags are usually 1 or 0 but certain flags might need other values.

      -- Data type: assuan_flag_t
          The flags are all named and collected in an enum for better readability. Available flags are:

          ASSUAN_NO_WAITPID
               When using a pipe server, by default Libassuan will wait for the forked process to die in assuan_release.  In certain cases this is not desirable.  By setting this flag, a call to waitpid will be suppressed and the caller is responsible to cleanup the child process.

          ASSUAN_CONFIDENTIAL
               Use to return the state of the confidential logging mode.

          ASSUAN_NO_FIXSIGNALS
               Do not modify signal handler for SIGPIPE.

          ASSUAN_CONVEY_COMMENTS
               If enabled comment lines are passed to the status callback of the assuan_transact.

          ASSUAN_FORCE_CLOSE
               Setting this flag forces the next command to assume that the connection has been closed.  This breaks the command processing loop and may be used as an implicit BYE command.  VALUE is ignored and thus it is not possible to clear this flag.

 -- Function: int assuan_get_flag (assuan_context_t CTX, assuan_flag_t FLAG)
     Return the value of FLAG in context CTX.

 -- Function: void assuan_begin_confidential (assuan_context_t CTX)
     Put the logging feature into confidential mode.  This is to avoid logging of sensitive data.

     This is identical to:

          assuan_set_flag (ctx, ASSUAN_CONFIDENTIAL, 1);

 -- Function: void assuan_end_confidential (assuan_context_t CTX)
     Get the logging feature out of confidential mode.  All data will be logged again (if logging is enabled).

     This is identical to:

          assuan_set_flag (ctx, ASSUAN_CONFIDENTIAL, 0);

 -- Data type: struct assuan_system_hooks
     This structure is used to store the system callback interface functions.  It has the following members, whose semantics are similar to the corresponding system functions, but not exactly equivalent.

     int version
          The user should set this to ASSUAN_SYSTEM_HOOKS_VERSION.  This indicates to the library which members of this structure are present in case of future extensions.  The user should initialize the whole structure with zero bytes.

     void (*usleep) (assuan_context_t ctx, unsigned int usec)
          This is the function called by ASSUAN to sleep for USEC microseconds.

     int (*pipe) (assuan_context_t ctx, assuan_fd_t fd[2], int inherit_idx)
          This is the function called by ASSUAN to create a pipe.  The returned file descriptor fd[inherit_idx] must be inheritable by the child process (under Windows, this requires some extra work).

     int (*close) (assuan_context_t ctx, assuan_fd_t fd)
          This is the function called by ASSUAN to close a file descriptor created through the system functions.

     ssize_t (*read) (assuan_context_t ctx, assuan_fd_t fd, void *buffer, size_t size)
          This is the function called by ASSUAN to read data from a file descriptor.  It is functionally equivalent to the system read function.

     ssize_t (*write) (assuan_context_t ctx, assuan_fd_t fd, const void *buffer, size_t size)
          This is the function called by ASSUAN to write data to a file descriptor.  It is functionally equivalent to the system write function.

     int (*recvmsg) (assuan_context_t ctx, assuan_fd_t fd, assuan_msghdr_t msg, int flags)
          This is the function called by ASSUAN to receive a message from a file descriptor.  It is functionally equivalent to the system recvmsg function.

     int (*sendmsg) (assuan_context_t ctx, assuan_fd_t fd, const assuan_msghdr_t msg, int flags);
          This is the function called by ASSUAN to send a message to a file descriptor.  It is functionally equivalent to the system sendmsg function.

     int (*spawn) (assuan_context_t ctx, pid_t *r_pid, const char *name, const char **argv, assuan_fd_t fd_in, assuan_fd_t fd_out, assuan_fd_t *fd_child_list, void (*atfork) (void *opaque, int reserved), void *atforkvalue, unsigned int flags)
          This is the function called by ASSUAN to spawn a child process. The stdin and stdout file descriptors are provided in fd_in and fd_out respectively, but can be set to ASSUAN_INVALID_FD, in which case they are set to /dev/null.  On systems which use fork and exec, the atfork function should be called with atforkvalue and 0 for flags in the child process right after fork returns.  fd_child_list is a ASSUAN_INVALID_FD terminated array (or NULL) and specifies file descriptors to be inherited by the child process.

          A special situation occurs if name is a null pointer, in which case the process should just fork but not call exec.  In this case, *argv should be set to "client" in the parent process and "server" in the child process.

          Flags is the bit-wise OR of some (or none) of the following flags:

          ASSUAN_SPAWN_DETACHED
               If set and there is a need to start the server it will be started as a background process.  This flag is useful under W32 systems, so that no new console is created and pops up a console window when starting the server.  On W32CE systems this flag is ignored.

     pid_t (*waitpid) (assuan_context_t ctx, pid_t pid, int action, int *status, int options)
          This is the function called by ASSUAN to wait for the spawned child process PID to exit, or, if ACTION is 1, to just release all resources associated with PID (required on Windows platforms).  If ACTION is 0, this is equivalent to waitpid.

     int (*socketpair) (assuan_context_t ctx, int namespace, int style, int protocol, assuan_fd_t filedes[2])
          This is the function called by ASSUAN to create a socketpair.  It is equivalent to socketpair.

 -- Function: void assuan_set_system_hooks (assuan_system_hooks_t SYSTEM_HOOKS)
     Set the default system hooks to use.  There is currently no way to reset to the default system hooks.

 -- Function: void assuan_sock_set_system_hooks (assuan_system_hooks_t SYSTEM_HOOKS)
     The socket subsystem uses an internal context which uses the default system hooks.  This function allows to change these system hooks.  The function is not thread-safe and only useful if a certain order of assuan and assuan socket initializations are required.

 -- Function: void assuan_ctx_set_system_hooks (assuan_context_t CTX, assuan_system_hooks_t SYSTEM_HOOKS)
     Set the system hooks for context CTX.  There is currently no way to reset to the default system hooks, create a new context for that.

The following system hook collections are defined by the library for your convenience:

ASSUAN_SYSTEM_NPTH
     System hooks suitable for use with the nPth library.

ASSUAN_SYSTEM_NPTH_IMPL
     The implementation of system hooks for use with the nPth library. This must be invoked once somewhere in the application, and defines the structure that is referenced by ASSUAN_SYSTEM_NPTH.

ASSUAN_SYSTEM_PTH
     System hooks suitable for use with the GNU Pth library.

ASSUAN_SYSTEM_PTH_IMPL
     The implementation of system hooks for use with the GNU Pth library. This must be invoked once somewhere in the application, and defines the structure that is referenced by ASSUAN_SYSTEM_PTH.

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.

The basic read and write functions are:

 -- Function: gpg_error_t assuan_read_line (assuan_context_t CTX, char **LINE, size_t *LINELEN)

     Read the next line written by the peer to the control channel and store a pointer to the buffer holding that line at the address LINE. The valid length of the lines is stored at the address of LINELEN. This buffer is valid until the next read operation on the same context 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 0 on success or an error value.

 -- Function: gpg_error_t assuan_write_line (assuan_context_t CTX, const char *LINE)

     Write the string LINE to the other end on the control channel. 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 0 on success or an error value.

To actually send bulk data lines a specialized function is available:

 -- Function: gpg_error_t assuan_send_data (assuan_context_t CTX, const void *BUFFER, size_t LENGTH)

     This function is used by a server or a client to send LENGTH bytes of bulk data in BUFFER to the other end on the control channel. The data will be escaped as required by the Assuan protocol and may get buffered until a line is full.  To flush any pending data, BUFFER may be passed as NULL and LENGTH be 0.

     When used by a client, this flush operation does also send the END command to terminate the response on an INQUIRE request.  Note that the function assuan_transact takes care of sending this END itself.

     This function returns 0 on success or an error value.

The input and output of data can be controlled at a higher level using an I/O monitor.

 -- Data type: unsigned int (*assuan_io_monitor_t) (assuan_context_t CTX, void *HOOK_VALUE, int INOUT, const char *LINE, size_t LINELEN)
     The monitor function is called right after a line has been received, if INOUT is ASSUAN_IO_FROM_PEER, or just before it is send, if INOUT is ASSUAN_IO_TO_PEER.  The HOOK_VALUE is provided by the user when registering the I/O monitor function with a context using assuan_set_io_monitor. The callback function should return the bitwise OR of some (or none) of the following flags:

     ASSUAN_IO_MONITOR_NOLOG
          Active logging of this line is suppressed.  This can reduce debug output in the case of a frequent message.

     ASSUAN_IO_MONITOR_IGNORE
          The whole output line is discarded.

 -- Function: void assuan_set_io_monitor (assuan_context_t CTX, assuan_io_monitor_t IO_MONITOR, void *HOOK_DATA)
     This function registers an I/O monitor IO_MONITOR for the context CTX with the hook value HOOK_DATA.

How to develop an Assuan client
*******************************

Depending on the type of the server you want to connect you need to use different functions.

If the peer is not a simple pipe server but one using full-duplex sockets, the full-fledged variant of the above function should be used:

 -- Function: gpg_error_t assuan_pipe_connect (assuan_context_t CTX,const char *NAME, const char *ARGV[], assuan_fd_t *FD_CHILD_LIST, void (*ATFORK) (void *, int), void *ATFORKVALUE, unsigned int FLAGS)

     A call to this functions forks the current process and executes the program NAME, passing the arguments given in the NULL-terminated list ARGV.  A list of file descriptors not to be closed may be given using the ASSUAN_INVALID_FD terminated array FD_CHILD_LIST.

     If NAME is a null pointer, 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 parent returns with "client" returned in ARGV and the child returns with "server" in ARGV.  This feature is only available on POSIX platforms.

     If ATFORK is not NULL, this function is called in the child right after the fork and the value ATFORKVALUE is passed as the first argument.  That function should only act if the second argument it received is 0.  Such a fork callback is useful to release additional resources not to be used by the child.

     FLAGS is a bit vector and controls how the function acts:

     ASSUAN_PIPE_CONNECT_FDPASSING
          If cleared a simple pipe based server is expected.  If set a server based on full-duplex pipes is expected.  Such pipes are usually created using the socketpair function.  It also enables features only available with such servers.

     ASSUAN_PIPE_CONNECT_DETACHED
          If set and there is a need to start the server it will be started as a background process.  This flag is useful under W32 systems, so that no new console is created and pops up a console window when starting the server.  On W32CE systems this flag is ignored.

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:

 -- Function: gpg_error_t assuan_socket_connect (assuan_context_t CTX, const char *NAME, pid_t SERVER_PID, unsigned int FLAGS)

     Make a connection to the Unix domain socket NAME using the already-initialized Assuan context at CTX.  SERVER_PID is currently not used but may become handy in the future; if you don't know the server's process ID (PID), pass ASSUAN_INVALID_PID. With FLAGS set to ASSUAN_SOCKET_CONNECT_FDPASSING, sendmsg and recvmesg are used for input and output and thereby enable the use of descriptor passing.

     Connecting to a TCP server is not yet implemented.  Standard URL schemes are reserved for NAME specifying a TCP server.

Now that we have a connection to the server, all work may be conveniently done using a couple of callbacks and the transact function:

 -- Function: gpg_error_t assuan_transact (assuan_context_t CTX, const char *COMMAND, gpg_error_t (*DATA_CB)(void *, const void *, size_t), void *DATA_CB_ARG, gpg_error_t (*INQUIRE_CB)(void*, const char *), void *INQUIRE_CB_ARG, gpg_error_t (*STATUS_CB)(void*, const char *), void *STATUS_CB_ARG)

     Here CTX is the Assuan context opened by one of the connect calls.  COMMAND is the actual Assuan command string.  It shall not end with a line feed and its length is limited to ASSUAN_LINELENGTH (~1000 bytes)

     DATA_CB is called by Libassuan for data lines; DATA_CB_ARG is passed to it along with the data and the length.  [FIXME: needs more documentation].

     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 assuan_send_data.  The server passed INQUIRY_CB_ARG along with the inquiry name to the callback.

     STATUS_CB is called by Libassuan for each status line it receives from the server.  STATUS_CB_ARG is passed along with the status line to the callback.

     The function returns 0 success or an error value.  The error value may be the one one returned by the server in error lines or one generated by the callback functions.

Libassuan supports descriptor passing on some platforms.  The next two functions are used with this feature:

 -- Function: gpg_error_t assuan_sendfd (assuan_context_t CTX, assuan_fd_t FD)

     Send the descriptor FD to the peer using the context CTX. The descriptor must be sent before the command is issued that makes use of the descriptor.

     Note that calling this function with a CTX of NULL and FD of ASSUAN_INVALID_FD can be used as a runtime test to check whether descriptor passing is available on the platform: 0 is returned if descriptor passing is available, otherwise an error with the error code GPG_ERR_NOT_IMPLEMENTED is returned.

 -- Function: gpg_error_t assuan_receivefd (assuan_context_t CTX, assuan_fd_t *FD)

     Receive a descriptor pending for the context CTX from the peer. The descriptor must be pending before this function is called.  To accomplish this, the peer needs to use assuan_sendfd before the trigger is sent (e.g. using assuan_write_line ("INPUT FD").

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.

The list of the implemented server commands is defined by a table like:

       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 }};

For convenience this table is usually put after the actual command handlers (cmd_foo, cmd_bar) or even put inside command_handler (see below).  Note that the commands 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.

     void
     command_handler (int fd)
     {
       gpg_error_t rc;
       int i;
       assuan_context_t ctx;

       rc = assuan_new (&ctx);
       if (rc)
         {
           fprintf (stderr, "server context creation failed: %s\n",
                    gpg_strerror(rc));
           return;
         }

       if (fd == -1)
         {
           assuan_fd_t filedes[2];

           filedes[0] = assuan_fd_from_posix_fd (0);
           filedes[1] = assuan_fd_from_posix_fd (1);
           rc = assuan_init_pipe_server (ctx, filedes);
         }
       else
         rc = assuan_init_socket_server (ctx, fd, ASSUAN_SOCKET_SERVER_ACCEPTED);
       if (rc)
         {
           fprintf (stderr, "server init failed: %s\n", gpg_strerror (rc));
           return;
         }

This is the first part of the command handler.  We start off by allocating a new Assuan context with assuan_new. See function assuan_new.

In case this is called as a pipe based server, FD will be based as FD and the code assumes that the server's stdin and stdout file handles are connected to a pipe.  The initialization is thus done using the function:

 -- Function: gpg_error_t assuan_init_pipe_server (assuan_context_t CTX, assuan_fd_t FILEDES[2])

     This function takes the two file descriptors from FILEDES and returns a new Assuan context at R_CTX.  As usual, a return value of 0 indicates success and a failure is indicated by returning an error value.  In case of error, NULL will be stored at R_CTX.

     In case the server has been called using a bi-directional pipe (socketpair), FILEDES is ignored and the file descriptor is taken from the environment variable _assuan_connection_fd.  You generally don't need to know this, because assuan_pipe_connect, which is called by the client to connect to such a server, automagically sets this variable.

 -- Function: gpg_error_t assuan_init_socket_server (assuan_context_t CTX, assuan_fd_t FD, unsigned int FLAGS)

     This function takes the file descriptor FD, which is expected to be associated with a socket, and an Assuan context CTX.  The following bits are currently defined for FLAGS:

     ASSUAN_SOCKET_SERVER_FDPASSING
          If set, sendmsg and recvmesg are used for input and output, which enables the use of descriptor passing.

     ASSUAN_SOCKET_SERVER_ACCEPTED
          If set, FD refers to an already accepted socket.  That is, Libassuan won't call ACCEPT for it.  It is suggested to set this bit as it allows better control of the connection state.

     As usual, a return value of 0 indicates success and a failure is indicated by returning an error value.

On the Windows platform the following function needs to be called after assuan_init_socket_server:

 -- Function: void assuan_set_sock_nonce (
     assuan_context_t CTX,
     assuan_sock_nonce_t *NONCE)

     Save a copy of NONCE in context CTX.  This should be used to register the server's nonce with a context established by assuan_init_socket_server.  It is technically only needed for Windows, but it does no harm to use it on other systems.

After error checking, the implemented assuan commands are registered with the server.

       for (i = 0; command_table[i].name; i++)
         {
           rc = assuan_register_command (ctx,
                                         command_table[i].name,
                                         command_table[i].handler, NULL);
           if (rc)
             {
               fprintf (stderr, "register failed: %s\n", gpg_strerror (rc));
               assuan_release (ctx);
               return;
             }
         }

 -- Data type: gpg_error_t (*assuan_handler_t) (assuan_context_t CTX, char *LINE)
     This is the function invoked by ASSUAN for various command related callback functions.  Some of these callback functions have a different type, but most use assuan_handler_t.

 -- Function: gpg_error_t assuan_register_command (assuan_context_t CTX, const char *CMD_STRING, assuan_handler_t HANDLER, const char *HELP_STRING)

     This registers the command named CMD_STRING with the Assuan context CTX.  HANDLER is the function called by Libassuan if this command is received from the client.  NULL may be used for 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.

     HELP_STRING is a help string that is used for automatic documentation.  It should contain a usage line followed by an empty line and a complete description.

 -- Function: gpg_error_t assuan_register_post_cmd_notify (assuan_context_t CTX, void (*FNC)(assuan_context_t), gpg_error_t ERR)

     Register a function to be called right after a command has been processed.  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.

 -- Function: gpg_error_t assuan_register_bye_notify (assuan_context_t CTX, assuan_handler_t HANDLER)

     Register function FNC with context CTX to be called right before the standard handler for the BYE command is being called.

 -- Function: gpg_error_t assuan_register_reset_notify (assuan_context_t CTX, assuan_handler_t HANDLER)

     Register function FNC with context CTX to be called right before the standard handler for the RESET command is being called.

 -- Function: gpg_error_t assuan_register_cancel_notify (assuan_context_t CTX, assuan_handler_t HANDLER)

     Register function FNC with context CTX to be called right before the standard handler for the RESET command is being called.

 -- Function: gpg_error_t assuan_register_option_handler (assuan_context_t CTX, gpg_error_t (*FNC)(assuan_context_t, const char*, const char*))

     Register function FNC with context 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 0 on success or an error code.

 -- Function: gpg_error_t assuan_register_input_notify (assuan_context_t CTX, assuan_handler_t HANDLER)

     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 assuan_get_input_fd.  If the notification function returns an error, the input fd does not change.

 -- Function: gpg_error_t assuan_register_output_notify (assuan_context_t CTX, assuan_handler_t HANDLER)

     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 assuan_get_output_fd. If the notification function returns an error, the output fd does not change.

 -- Function: gpg_error_t assuan_set_hello_line (assuan_context_t CTX, const char *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 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.

Now that everything has been setup, we can start to process our clients requests.

       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_release (ctx);
     }

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.

 -- Function: gpg_error_t assuan_accept (assuan_context_t 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 0 is returned.  An error value will be returned if the connection could for some reason not be established.  An error code of GPG_ERR_EOF indicates the end of the connection.

 -- Function: gpg_error_t assuan_process (assuan_context_t CTX)

     This function is used to handle the Assuan protocol after a connection has been established using assuan_accept.  It is the main protocol handler responsible for reading the client commands and calling the appropriate handlers.  The function returns 0 on success or an error value if something went seriously wrong.  Error values from the individual command handlers, i.e. operational error, are not seen here.

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.

How to use external I/O event loops
***********************************

The above implementations of an Assuan client and server are synchronous, insofar as 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:

  * Either partner should always write full lines.  If partial lines are written, the remainder of the line should be sent without delay.

  * 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.

  * If descriptor passing is used over a socket, the descriptor must be sent after the corresponding command without undue delay.

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.

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.

 1. 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).

 2. 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 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.

 3. After connecting, get the inbound status FD with 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).

 4. 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.

 5. 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().

 6. 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 assuan_release.

 7. As noted above, all send operations on the outbound status FD are done immediate with blocking.  In GPGME, this has never caused any problems.

 8. The 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 INQUIRE function, so we do not have any practical experience with this.

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.

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:

 1. For socket servers: You can not use 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 assuan_init_socket_server with the final argument being ASSUAN_SOCKET_SERVER_ACCEPTED 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: assuan_init_pipe_server creates an Assuan context valid for the pipe FDs.

 2. Once you have a context for a single connection, you can get the inbound status FD with 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 assuan_process_next (see below) to process the next incoming message.  assuan_process_next processes as many status lines as can be received by a single read operation.  When it returns, the inbound status FD may still be readable, but Assuan does not check this.

     The function assuan_process_next returns 0 if it can not make progress reliably, and it returns true in done if the client closed the connection.  See below for more information on this function.

 3. The command will be dispatched by assuan_process_next just as with 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 assuan_process_done with an appropriate error value (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 return assuan_process_done (error_code);.  Another possibility is to invoke 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.

It is not possible to use assuan_inquire in a command handler, as this function blocks on receiving the inquired data from the client.  Instead, the asynchronous version 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 assuan_inquire_ext and return 0.  Eventually, the continuation would be invoked by assuan_process_next when the client data arrived.  The continuation could complete the command and eventually call assuan_process_done.

Cancellation is supported by returning an appropriate error value to the client with 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.

 -- Function: gpg_error_t assuan_process_next (assuan_context_t CTX, int *DONE)
     This is the same as assuan_process but the caller has to provide the outer loop.  He should loop as long as the return code is zero and DONE is false.

 -- Function: gpg_error_t assuan_process_done (assuan_context_t CTX, gpg_error_t RC)
     Finish a pending command and return the error code RC to the client.

 -- Function: gpg_error_t assuan_inquire_ext (assuan_context_t CTX, const char *KEYWORD, size_t MAXLEN, gpg_error_t (*CB) (void *cb_data, gpg_error_t rc, unsigned char *buffer, size_t buffer_len), void *CB_DATA)
     This is similar to assuan_inquire but the caller has to provide the outer loop (using assuan_process_next).  The caller should specify a continuation with CB, which receives CB_DATA as its first argument, and the error value as well as the inquired data as its remaining arguments.

Utility functions
*****************

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.

 -- Function: gpg_error_t assuan_write_status (assuan_context_t CTX, const char *KEYWORD, const char *TEXT)

     This is a convenience function for a server to send a status line.  You need to pass it the KEYWORD and the content of the status line in TEXT.

 -- Function: gpg_error_t assuan_inquire (assuan_context_t CTX, const char *KEYWORD, unsigned char **R_BUFFER, size_t *R_LENGTH, size_t MAXLEN)

     A server may use this function to request specific data from a client. This function sends an 'INQUIRE' command back to the client and returns the client's response in a newly allocated buffer.  You need to pass at least the server's context (CTX) and a description of the required data (KEYWORD).  All other parameters may be NULL or 0, but this is rarely useful.

     On success the result is stored in a newly allocated buffer stored at R_BUFFER. The length of the data is stored at R_LENGTH. If MAXLEN has not been given as 0, it specifies an upper size limit of the expected data.  If the client returns too much data the function fails and an error with the error code GPG_ERR_ASS_TOO_MUCH_DATA will be returned.

 -- Function: FILE* assuan_get_data_fp (assuan_context_t CTX)

     Return a stdio stream for the Assuan context 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 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 funopen or fopencookie. If it is not supported NULL is returned and errno is set to ENOSYS.

 -- Function: gpg_error_t assuan_set_okay_line (assuan_context_t CTX, const char *LINE)

     Set the text used for the next OK response to 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.

 -- Function: gpg_error_t assuan_command_parse_fd (assuan_context_t CTX, char *LINE, assuan_fd_t *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 LINE contains FD=N, it returns N in RFD assuming a local file descriptor.  If LINE contains just FD it returns a file descriptor at RFD; this file descriptor needs to have been sent by the client right before using 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 _open_osfhandle before they can pass this descriptor to standard functions like fdopen or dup.

 -- Function: const char * assuan_get_command_name (assuan_context_t CTX)

     Return the name of the command currently processed by a handler. The returned string is valid until the next call to an Assuan function on the same context.  Returns NULL if no handler is executed or the command is not known.

 -- Function: assuan_fd_t assuan_get_input_fd (assuan_context_t CTX)

     Return the file descriptor sent by the client using the last INPUT command.  Returns ASSUAN_INVALID_FD if no file descriptor is available.

 -- Function: assuan_fd_t assuan_get_output_fd (assuan_context_t CTX)

     Return the file descriptor sent by the client using the last OUTPUT command.  Returns ASSUAN_INVALID_FD if no file descriptor is available.

 -- Function: gpg_error_t assuan_close_input_fd (assuan_context_t CTX)

     Close the file descriptor set by the last INPUT command.  This function has the advantage over a simple close that it can do some sanity checks and make sure that a following assuan_get_input_fd won't return an already closed descriptor.

 -- Function: gpg_error_t assuan_close_output_fd (assuan_context_t CTX)

     Close the file descriptor set by the last OUTPUT command.  This function has the advantage over a simple close that it can do some sanity checks and make sure that a following assuan_get_input_fd won't return an already closed descriptor.

 -- Function: gpg_error_t assuan_set_error (assuan_context_t CTX, gpg_error_t ERR, const char *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 CTX while still being in the command handler.  This function is commonly called this way

            return assuan_set_error (ctx, err, "commands needs 5 arguments");

     The value ERR is passed through and thus the return value of the command handler in the example.  The provided text further explains that error to humans.

 -- Function: pid_t assuan_get_pid (assuan_context_t CTX)

     This function returns the pid of the connected connected peer.  If that pid is not known ASSUAN_INVALID_PID 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  (to our knowledge only the Linux kernel has this feature).

 -- Data type: assuan_peercred_t
     This structure is used to store the peer credentials.  The available members depend on the operating system.

     pid_t pid
          The process ID of the peer.

     uid_t uid
          The user ID of the peer process.

     gid_t gid
          The group ID of the peer process.

 -- Function: gpg_error_t assuan_get_peercred (assuan_context_t CTX, assuan_peercred_t *PEERCRED)
     Return user credentials of the peer. This will work only on certain systems and only when connected over a socket.  On success, a pointer to the peer credentials is stored in PEERCRED.  The information is only valid as long as the state of the connection is unchanged (at least until the next assuan call to the same context).

     As of now only the server is able to retrieve this information.  Note, that for getting the pid of the peer assuan_get_pid is usually better suited.

 -- Function: int assuan_get_active_fds (assuan_context_t CTX, int WHAT, assuan_fd_t *FDARRAY, int FDARRAYSIZE)

     Return all active file descriptors for the context CTX.  This function can be used to select on the file descriptors and to call assuan_process_next if there is an active one.  The first descriptor in the array is the one used for the command connection. Currently WHAT needs to be 0 to return descriptors used for reading, 1 will eventually be used to return descriptors used for writing.  FDARRAY is an array of integers provided by the caller; FDARRAYSIZE gives the size of that array.

     On success the number of active descriptors are returned.  These active descriptors are then stored in FDARRAY.  On error -1 is returned; the most likely reason for this is a too small FDARRAY.

     Note that on W32 systems the returned file descriptor is a system handle and not a libc low level I/O file descriptor.

 -- Function: int assuan_pending_line (assuan_context_t 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.

Socket wrapper functions
************************

It is sometimes useful to support Unix domain sockets on Windows.  To do this in a portable way, Assuan provides a set of wrapper functions which may be used on any system but will enhance Windows to support these socket types.  The actual implementation is based on local TCP sockets and fully transparent for the client.  Server code needs to utilize two extra functions to check the permissions.

 -- Function: gpg_error_t assuan_sock_init (void)
     Initialize the socket wrappers.  Must be called once at startup if any of the socket wrapper functions are used.

 -- Function: gpg_error_t assuan_sock_deinit (void)
     Deinitialize the socket wrappers.

 -- Function: int assuan_sock_close (assuan_fd_t FD)
     Wrapper for close which does a closesocket on Windows if needed.

 -- Function: assuan_fd_t assuan_sock_new (int DOMAIN, int TYPE, int PROTO);
     Wrapper around socket.

 -- Function: int assuan_sock_connect (assuan_fd_t SOCKFD,
     struct sockaddr *ADDR,
     int ADDRLEN)

     Wrapper around connect.  For Unix domain sockets under Windows this function also does a write immediately after the the connect to send the nonce as read from the socket's file.  Under Unix this function check whether the socket file is a redirection file and connects to the redirected socket instead; see assuan_sock_set_sockaddr_un for details on the redirection file format.

 -- Function: int assuan_sock_connect_byname (const char * HOST,
     unsigned short PORT,
     int RESERVED,
     const char *CREDENTIALS,
     unsigned int FLAGS)

     Directly connect to PORT on HOST given as a name.  The current implementation requires that FLAGS has either ASSUAN_SOCK_SOCKS or ASSUAN_SOCK_TOR set.  On success a new TCP STREAM socket is returned; on error ASSUAN_INVALID_FD and ERRNO set.  If CREDENTIALS is not NULL, it is a string used for password based SOCKS authentication.  Username and password are separated by a colon. RESERVED should be 0.  To test whether the proxy is available HOST and PORT may be given as NULL/0:  If the proxy is available the function returns a valid socket which is in the state after credentials sub-negotiation. The caller now knows that the SOCKS proxy is available and has been authenticated; normally the caller closes the socket then.

 -- Function: int assuan_sock_bind (
     assuan_fd_t SOCKFD,
     struct sockaddr *ADDR,
     int ADDRLEN)

     Wrapper around bind.  Under Windows this creates a file and writes the port number and a random nonce to this file.

 -- Function: int assuan_sock_set_sockaddr_un (
     const char *FNAME,
     struct sockaddr *ADDR,
     int *R_REDIRECTED)

     This is a helper function to initialize the Unix socket domain address structure ADDR and store the file name FNAME there.  If R_REDIRECTED is not NULL the function checks whether FNAME already exists, is a regular file, and not a socket.  In that case FNAME is read to see whether this is a redirection to a socket file.  If that is the case 1 is stored at R_REDIRECTED.  If the file does not look like a redirection file 0 will be stored there and FNAME will be used in the regular way.

     The format of a redirection file is

          %Assuan%
          socket=NAME

     With NAME being is the actual socket to use.  No white spaces are allowed, both lines must be terminated by a single linefeed, and extra lines are not allowed.  Environment variables are interpreted in NAME if given in ${VAR} notation.  No escape characters are defined; if the string ${ shall be used in file name, an environment variable with that content may be used.  The length of the redirection file is limited to 511 bytes which is more than sufficient for any known implementation of Unix domain sockets.

 -- Function: int assuan_sock_get_nonce (
     struct sockaddr *ADDR,
     int ADDRLEN,
     assuan_sock_nonce_t *NONCE)

     This is used by the server after a bind to return the random nonce.  To keep the code readable this may also be used on POSIX system.

 -- Function: int assuan_sock_check_nonce (
     assuan_fd_t FD,
     assuan_sock_nonce_t *NONCE)

     If the option ASSUAN_SOCKET_SERVER_ACCEPTED has been used, Libassuan has no way to check the nonce of the server.  Thus an explicit check of the saved nonce using this function is required.  If this function fails the server should immediately drop the connection.  This function may not be used if Libassuan does the accept call itself (i.e. ASSUAN_SOCKET_SERVER_ACCEPTED has not been used) because in this case Libassuan calls this function internally.  See also assuan_set_sock_nonce.

     Actually this mechanism is only required on Windows but for cleanness of code it may be used on POSIX systems as well, where this function is a nop.

To control certain properties of the wrapper two additional functions are provided:

 -- Function: int assuan_sock_set_flag (
     assuan_fd_t FD,
     const char *NAME,
     int VALUE)

     Set the flags NAME for socket FD to VALUE.  See below for a list of valid names.  Returns 0 on success; on failure sets ERRNO and returns -1.

 -- Function: int assuan_sock_get_flag (
     assuan_fd_t FD,
     const char *NAME,
     int *R_VALUE)

     Store the current value of the flag NAME for socket FD at R_VALUE.  See below for a list of valid names.  Returns 0 on success; on failure sets ERRNO and returns -1.

The supported flags are:

cygwin
     This flag has an effect only on Windows.  If the value is 1, the socket is set into Cygwin mode so that Cygwin clients can connect to such a socket.  This flag needs to be set before a bind and should not be changed during the lifetime of the socket.  There is no need to set this flag for connecting to a Cygwin style socket because no state is required at the client.  On non-Windows platforms setting this flag is ignored, reading the flag always returns a value of 0.

tor-mode
socks
     If VALUE is 1 globally enable SOCKS5 mode for new connections using IPv6 or IPv4. FD must be set to ASSUAN_INVALID_FD A future extension may allow to disable SOCKS5 mode for a specified socket but globally disabling SOCKS5 mode is not possible.  Using the flag ``tor-mode'' expects the SOCKS5 proxy to listen on port 9050, the flag ``socks'' expects the proxy to listen on port 1080.

     Connections to the loopback address are not routed though the SOCKS proxy.  UDP requests are not supported at all.  The proxy will be connected at address 127.0.0.1; an IPv6 connection to the proxy is not yet supported.

     [file lgpl.texi not included]
     [file gpl.texi not included]