\input texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename assuan.info
@macro copyrightnotice
Copyright @copyright{} 2001--2013 Free Software Foundation, Inc. @*
Copyright @copyright{} 2001--2015 g10 Code GmbH
@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
\gdef\mysetfont#1#2#3#4{\font#1=\fontprefix#2#3 scaled #4}
\global\mysetfont\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.
* Socket wrappers:: Socket wrapper 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
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 @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 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.
@node Assuan
@chapter 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:
@itemize @bullet
@item Common framework for module communication
@item Easy debugging
@item Easy module testing
@item Extensible
@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 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.
@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 [<arbitrary debugging information>]
Request was successful.
@item ERR @var{errorcode} [<human readable error description>]
Request could not be fulfilled. The possible error codes are defined
by @code{libgpg-error}.
@item S @var{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. @var{keyword} shall start with a
letter or an underscore.
@item # <string>
Comment line issued only for debugging purposes. Totally ignored.
@item 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.
@item INQUIRE @var{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''.
@end table
Consider the following examples (lines prefixed with S indicate text
that the server sends; lines prefixed with C indicate text that the
client sends):
@example
S: INQUIRE foo
C: D foo bar
C: D bar baz
C: END
[Server continues normal work]
@end example
This implements a callback to the client:
@example
S: INQUIRE foo
C: END
[Server continues]
@end example
and:
@example
S: INQUIRE foo
C: CAN
[Server terminates the operaion and in most cases returns an ERR to the client.]
@end example
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.)
@node Client requests
@section Client requests
The server waits for client requests after sending an Okay or Error.
The client should not issue a request in other cases.
@example
@var{command} <parameters>
@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 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.
@example
D <raw data>
@end example
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 @code{OK} or @code{ERR}
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 supported by the Assuan library:
@table @code
@item BYE
Close the connection. The server will respond with @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
@code{END} to indicate a partial end of data.
@item HELP
Lists all commands that the server understands as comment lines on the
status channel.
@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 Werner's mail to gpa-dev on
2001-10-25 about the rationale for measurements against local attacks.
@item NOP
No operation. Returns OK without any action.
@end table
@node Error codes
@section 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
@code{GPG_ERR_SOURCE_UNKNOWN} by calling @ref{function
assuan_set_gpg_err_source} early.
@c
@c P R E P A R A T I O N
@c
@node Preparation
@chapter Preparation
To use @sc{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.
@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 @code{libassuan} can be used in a MT environment.
@end menu
@node Header
@section Header
All interfaces (data types and functions) of @code{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 <assuan.h>
@end example
The namespace of @code{libassuan} 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.
Because @code{libassuan} makes use of the GPG Error library, using
@code{libassuan} will also use the @code{GPG_ERR_*} namespace
directly, and the @code{gpg_err*} and @code{gpg_str*} namespaces
indirectly.
@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, @code{libassuan} 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 @code{libassuan} libraries (in
particular, the @option{-lassuan} option). The example shows how to
link @file{foo.o} with the @code{libassuan} library to a program
@command{foo}.
@example
gcc -o foo foo.o $(libassuan-config --libs)
@end example
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
@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. @code{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 @code{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 @code{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
@node Multi Threading
@section Multi Threading
The @code{libassuan} library is designed so that it can be used in a
threaded application, if some rules are followed.
@itemize @bullet
@item Run the initialization functions before you actually start
to use threads. Specifically, the functions
@code{assuan_set_gpg_err_source}, @code{assuan_set_malloc_hooks} and
@code{assuan_set_log_cb} should not be called concurrently with
@code{assuan_new}. Use @code{assuan_new_ext} instead or ensure proper
serialization.
@item Only one thread at a time may access an @code{libassuan} context.
@item If you use the default log handler, use
@code{assuan_set_assuan_log_stream} to setup a default log stream.
@item If you have callback functions shared by multiple functions,
the callback function must be reentrant for that purpose.
@code{libassuan} does not serialize invocation of callback functions
across contexts.
@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 @code{libassuan}.
* Initializing the library:: How to initialize the library.
* Default Log Handler:: How to configure the default log handler.
* Contexts:: How to work with contexts.
* Reading and Writing:: How to communicate with the peer.
@end menu
@node Data Types
@section Data Types used by the library
@sc{Assuan} uses a so-called context to store a connection's state.
The following data type is used for that:
@deftp {Data type} assuan_context_t
The @code{assuan_context_t} type is a pointer to an object maintained
internally by the library. Contexts are allocated with
@code{assuan_new} or @code{assuan_new_ext} and released with
@code{assuan_release}. Other functions take this data type to access
the state created by these functions.
@end deftp
@deftp {Data type} assuan_fd_t
The @code{assuan_fd_t} is a file descriptor (in Unix) or a system
handle (in Windows). The special value @code{ASSUAN_INVALID_FD} is
used to specify invalid Assuan file descriptors.
@end deftp
@deftypefun assuan_fd_t assuan_fdopen (@w{int @var{fd}})
Create an assuan file descriptor from a POSIX (libc) file descriptor
@var{fd}. On Unix, this is equivalent to @code{dup}, while on Windows
this will retrieve the underlying system handle with
@code{_get_osfhandle} and duplicate that.
@end deftypefun
@node Initializing the library
@section Initializing the library
Libassuan makes use of Libgpg-error and assumes that Libgpg-error has
been initialized. In general @code{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 @code{assuan_new}. As there can only be one default,
all values can also be set directly with @code{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 @code{libassuan} about it so it can make use of the
same functions or wrappers:
@deftp {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:
@table @code
@item void *(*malloc) (size_t cnt)
This is the function called by @sc{Assuan} to allocate memory for a context.
@item void *(*realloc) (void *ptr, size_t cnt)
This is the function called by @sc{Assuan} to reallocate memory for a context.
@item void (*free) (void *ptr)
This is the function called by @sc{Assuan} to release memory for a context.
@end table
@end deftp
@deftp {Data type} {assuan_malloc_hooks_t}
This is a pointer to a @code{struct assuan_malloc_hooks}.
@end deftp
@deftypefun void assuan_set_malloc_hooks (@w{assuan_malloc_hooks_t @var{malloc_hooks}})
This function sets the default allocation hooks for new contexts
allocated with @code{assuan_new}. 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
@deftypefun assuan_malloc_hooks_t assuan_get_malloc_hooks ()
This function gets the default allocation hooks for new contexts
allocated with @code{assuan_new}. The result structure is statically
allocated and should not be modified.
@end deftypefun
The @sc{Assuan} library uses @code{libgpg-error} error values, which
consist and error code and an error source. The default source used
by contexts allocated with @code{assuan_new} can be set with the
following function.
@anchor{function assuan_set_gpg_err_source}
@deftypefun void assuan_set_gpg_err_source (@w{gpg_err_source_t @var{err_source}})
This function sets the default error source for errors generated by
contexts allocated with @code{assuan_new}.
One way to call this function is
@smallexample
assuan_set_gpg_err_source (GPG_ERR_SOURCE_DEFAULT);
@end smallexample
@end deftypefun
@deftypefun gpg_err_source_t assuan_get_gpg_err_source (void)
This function gets the default error source for errors generated by
contexts allocated with @code{assuan_new}.
@end deftypefun
@noindent
To integrate assuan logging and diagnostics into your own logging
system, you may use the following two functions:
@deftp {Data type} {int (*assuan_log_cb_t) (@w{assuan_context_t @var{ctx}}, @w{void *@var{hook_value}}, @w{unsigned int @var{cat}}, @w{const char *@var{msg}})}
The user-provided callback function takes a context @var{ctx}, for
which the message @var{msg} was generated, and a hook value
@var{hook_value} that was supplied when the log handler was registered
for the context with @code{assuan_set_log_cb}, and a category
@var{cat}. The category is one of:
@table @code
@item ASSUAN_LOG_INIT
@item ASSUAN_LOG_CTX
@item ASSUAN_LOG_ENGINE
@item ASSUAN_LOG_DATA
RFU
@item ASSUAN_LOG_SYSIO
Log lowlevel I/O data.
@item ASSUAN_LOG_CONTROL
Log the control channel.
@end table
The user may then, depending on the category, write the message to a
log file or treat it in some other way.
If @var{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 @var{cat}. If it is not interested, 0 should be
returned. This allows @code{libassuan} to suppress the generation of
expensive debug output.
@end deftp
@deftypefun void assuan_set_log_cb (@w{assuan_log_cb_t @var{log_cb}}, @w{void *@var{log_cb_data}})
This function sets the default logging handler for log messages
generated by contexts allocated with @code{assuan_new}.
@end deftypefun
@deftypefun void assuan_get_log_cb (@w{assuan_log_cb_t *@var{log_cb}}, @w{void **@var{log_cb_data}})
This function gets the default logging handler for log messages
generated by contexts allocated with @code{assuan_new}.
@end deftypefun
You do not need to set a log handler, as @sc{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.
@node Default Log Handler
@section Default Log Handler
The default log handler can be configured by the following functions:
@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
@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
@deftypefun void assuan_set_assuan_log_stream (FILE *@var{fp})
This sets the default log stream to which @code{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 @w{FILE *} assuan_get_assuan_log_stream (void)
Return the stream which is currently being using for global logging.
@end deftypefun
The log stream used by the default log handler can also be set on a
per context basis.
@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
@node Contexts
@section 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
@code{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.
@anchor{function assuan_new}
@deftypefun gpg_error_t assuan_new (@w{assuan_context_t *@var{ctx_p}})
The function @code{assuan_new} creates a new context, using the global
default memory allocation, log handler and @code{libgpg-error} source.
It is equivalent to
@smallexample
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);
@end smallexample
As you can see, this is not thread-safe. Take care not to modify the
memory allocation hooks or log callback handler concurrently with
@code{assuan_new}.
The function returns an error if a memory allocation error occurs, and
0 with the new context in @var{ctx_p} otherwise.
@end deftypefun
@deftypefun gpg_error_t assuan_new_ext (@w{assuan_context_t *@var{ctx_p}}, @w{gpg_err_source_t @var{err_source}}, @w{assuan_malloc_hooks_t @var{malloc_hooks}}, @w{assuan_log_cb_t @var{log_cb}}, @w{void *@var{log_cb_data}})
The function @code{assuan_new_ext} creates a new context using the
supplied @code{libgpg-error} error source @var{err_source}, the memory
allocation hooks @var{malloc_hooks} and the log handler @var{log_cb}
with the user data @var{log_cb_data}.
@end deftypefun
After the context has been used, it can be destroyed again.
@deftypefun void assuan_release (assuan_context_t ctx)
The function @code{assuan_release} destroys the context CTX and
releases all associated resources.
@end deftypefun
Other properties of the context beside the memory allocation handler,
the log handler, and the @code{libgpg-error} source can be set after
context creation. Here are some of them:
@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 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.
Available flags are:
@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_release}. 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
Use to return the state of the confidential logging mode.
@item ASSUAN_NO_FIXSIGNALS
Do not modify signal handler for @code{SIGPIPE}.
@item ASSUAN_CONVEY_COMMENTS
If enabled comment lines are passed to the status callback of the
@code{assuan_transact}.
@item 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. @var{value} is ignored
and thus it is not possible to clear this flag.
@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 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.
This is identical to:
@smallexample
assuan_set_flag (ctx, ASSUAN_CONFIDENTIAL, 1);
@end smallexample
@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).
This is identical to:
@smallexample
assuan_set_flag (ctx, ASSUAN_CONFIDENTIAL, 0);
@end smallexample
@end deftypefun
@deftp {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.
@table @code
@item int version
The user should set this to @code{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.
@item void (*usleep) (assuan_context_t ctx, unsigned int usec)
This is the function called by @sc{Assuan} to sleep for @code{USEC}
microseconds.
@item int (*pipe) (assuan_context_t ctx, assuan_fd_t fd[2], int inherit_idx)
This is the function called by @sc{Assuan} to create a pipe. The
returned file descriptor @code{fd[inherit_idx]} must be inheritable by
the child process (under Windows, this requires some extra work).
@item int (*close) (assuan_context_t ctx, assuan_fd_t fd)
This is the function called by @sc{Assuan} to close a file descriptor
created through the system functions.
@item ssize_t (*read) (assuan_context_t ctx, assuan_fd_t fd, void *buffer, size_t size)
This is the function called by @sc{Assuan} to read data from a file
descriptor. It is functionally equivalent to the system @code{read}
function.
@item ssize_t (*write) (assuan_context_t ctx, assuan_fd_t fd, const void *buffer, size_t size)
This is the function called by @sc{Assuan} to write data to a file
descriptor. It is functionally equivalent to the system @code{write}
function.
@item int (*recvmsg) (assuan_context_t ctx, assuan_fd_t fd, assuan_msghdr_t msg, int flags)
This is the function called by @sc{Assuan} to receive a message from a
file descriptor. It is functionally equivalent to the system
@code{recvmsg} function.
@item int (*sendmsg) (assuan_context_t ctx, assuan_fd_t fd, const assuan_msghdr_t msg, int flags);
This is the function called by @sc{Assuan} to send a message to a
file descriptor. It is functionally equivalent to the system
@code{sendmsg} function.
@item 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 @sc{Assuan} to spawn a child process.
The @code{stdin} and @code{stdout} file descriptors are provided in
@code{fd_in} and @code{fd_out} respectively, but can be set to
@code{ASSUAN_INVALID_FD}, in which case they are set to
@code{/dev/null}. On systems which use @code{fork} and @code{exec},
the @code{atfork} function should be called with @code{atforkvalue}
and @code{0} for flags in the child process right after @code{fork}
returns. @code{fd_child_list} is a @code{ASSUAN_INVALID_FD}
terminated array (or @code{NULL}) and specifies file descriptors to be
inherited by the child process.
A special situation occurs if @code{name} is a null pointer, in which
case the process should just fork but not call @code{exec}. In this
case, @code{*argv} should be set to @code{"client"} in the parent
process and @code{"server"} in the child process.
Flags is the bit-wise OR of some (or none) of the following flags:
@table @code
@item 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.
@end table
@item pid_t (*waitpid) (assuan_context_t ctx, pid_t pid, int action, int *status, int options)
This is the function called by @sc{Assuan} to wait for the spawned
child process @var{pid} to exit, or, if @var{action} is 1, to just
release all resources associated with @var{pid} (required on Windows
platforms). If @var{action} is 0, this is equivalent to @code{waitpid}.
@item int (*socketpair) (assuan_context_t ctx, int namespace, int style, int protocol, assuan_fd_t filedes[2])
This is the function called by @sc{Assuan} to create a socketpair. It
is equivalent to @code{socketpair}.
@end table
@end deftp
@deftypefun void assuan_set_system_hooks (@w{assuan_system_hooks_t @var{system_hooks}})
Set the default system hooks to use. There is currently no way to
reset to the default system hooks.
@end deftypefun
@deftypefun void assuan_sock_set_system_hooks (@w{assuan_system_hooks_t @var{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.
@end deftypefun
@deftypefun void assuan_ctx_set_system_hooks (@w{assuan_context_t @var{ctx}}, @w{assuan_system_hooks_t @var{system_hooks}})
Set the system hooks for context @var{ctx}. There is currently no way
to reset to the default system hooks, create a new context for that.
@end deftypefun
The following system hook collections are defined by the library for
your convenience:
@table @code
@item ASSUAN_SYSTEM_NPTH
System hooks suitable for use with the nPth library.
@item 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 @code{ASSUAN_SYSTEM_NPTH}.
@item ASSUAN_SYSTEM_PTH
System hooks suitable for use with the GNU Pth library.
@item 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 @code{ASSUAN_SYSTEM_PTH}.
@end table
@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 gpg_error_t assuan_read_line (@w{assuan_context_t @var{ctx}}, @w{char **@var{line}}, @w{size_t *@var{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 @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 value.
@end deftypefun
@deftypefun gpg_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 on the control channel.
This string needs to be a proper formatted Assuan protocol line and
should not include a linefeed. Sending linefeed or @code{Nul}
characters is not possible and not allowed by the assuan protocol. This
function shall not be used for sending data (@code{D}) lines. This
function returns @code{0} on success or an error value.
@end deftypefun
@noindent
To actually send bulk data lines a specialized function is available:
@deftypefun gpg_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 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, @var{buffer}
may be passed as @code{NULL} and @var{length} be @code{0}.
@noindent
When used by a client, this flush operation does also send the
@code{END} command to terminate the response on an @command{INQUIRE}
request. 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 value.
@end deftypefun
The input and output of data can be controlled at a higher level using
an I/O monitor.
@deftp {Data type} {unsigned int (*assuan_io_monitor_t) (@w{assuan_context_t @var{ctx}}, @w{void *@var{hook_value}}, @w{int @var{inout}}, @w{const char *@var{line}}, @w{size_t @var{linelen}})}
The monitor function is called right after a line has been received,
if @var{inout} is @code{ASSUAN_IO_FROM_PEER}, or just before it is
send, if @var{inout} is @code{ASSUAN_IO_TO_PEER}. The
@var{hook_value} is provided by the user when registering the I/O
monitor function with a context using @code{assuan_set_io_monitor}.
The callback function should return the bitwise OR of some (or none) of the
following flags:
@table @code
@item ASSUAN_IO_MONITOR_NOLOG
Active logging of this line is suppressed. This can reduce debug
output in the case of a frequent message.
@item ASSUAN_IO_MONITOR_IGNORE
The whole output line is discarded.
@end table
@end deftp
@deftypefun void assuan_set_io_monitor (@w{assuan_context_t @var{ctx}}, @w{assuan_io_monitor_t @var{io_monitor}}, @w{void *@var{hook_data}})
This function registers an I/O monitor @var{io_monitor} for the
context @var{ctx} with the hook value @var{hook_data}.
@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.
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:
@deftypefun gpg_error_t assuan_pipe_connect (@w{assuan_context_t @var{ctx}},@w{const char *@var{name}}, @w{const char *@var{argv}[]}, @w{assuan_fd_t *@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{ASSUAN_INVALID_FD} terminated array @var{fd_child_list}.
If @var{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
@code{"client"} returned in @var{argv} and the child returns with
@code{"server"} in @var{argv}. This feature is only available on POSIX
platforms.
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.
@noindent
@var{flags} is a bit vector and controls how the function acts:
@table @code
@item 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 @code{socketpair} function. It also enables
features only available with such servers.
@item 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.
@end table
@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 gpg_error_t assuan_socket_connect (@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} using the
already-initialized 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 process ID (PID), pass @code{ASSUAN_INVALID_PID}.
With @var{flags} set to @code{ASSUAN_SOCKET_CONNECT_FDPASSING},
@code{sendmsg} and @code{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 @var{name} specifying a TCP server.
@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 gpg_error_t assuan_transact (@w{assuan_context_t @var{ctx}}, @w{const char *@var{command}}, @w{gpg_error_t (*@var{data_cb})(void *, const void *, size_t)}, @w{void *@var{data_cb_arg}}, @w{gpg_error_t (*@var{inquire_cb})(void*, const char *)}, @w{void *@var{inquire_cb_arg}}, @w{gpg_error_t (*@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 Assuan command string. 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_send_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 value. The error value
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 gpg_error_t assuan_sendfd (@w{assuan_context_t @var{ctx}}, @w{assuan_fd_t @var{fd}})
Send the descriptor @var{fd} to the peer using the context @var{ctx}.
The descriptor must be sent before the command is issued that makes
use of the descriptor.
Note that calling this function with a @var{ctx} of @code{NULL} and
@var{fd} of @code{ASSUAN_INVALID_FD} can be used as a runtime test to
check whether descriptor passing is available on the platform:
@code{0} is returned if descriptor passing is available, otherwise an
error with the error code @code{GPG_ERR_NOT_IMPLEMENTED} is returned.
@end deftypefun
@anchor{function assuan_receivefd}
@deftypefun gpg_error_t assuan_receivefd (@w{assuan_context_t @var{ctx}}, @w{assuan_fd_t *@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 (@code{cmd_foo}, @code{cmd_bar}) or even put inside
@code{command_handler} (see below). Note that the commands
@code{INPUT} and @code{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)
@{
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;
@}
@end example
@noindent
This is the first part of the command handler. We start off by
allocating a new Assuan context with @code{assuan_new}.
@xref{function assuan_new}.
In case this is called as a pipe based server, @var{fd} will be based
as @var{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 gpg_error_t assuan_init_pipe_server (@w{assuan_context_t @var{ctx}}, @w{assuan_fd_t @var{filedes}[2]})
This 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
returning an error value. 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
generally don't need to know this, because @code{assuan_pipe_connect},
which is called by the client to connect to such a server,
automagically sets this variable.
@end deftypefun
@deftypefun gpg_error_t assuan_init_socket_server (@w{assuan_context_t @var{ctx}}, @w{assuan_fd_t @var{fd}}, @w{unsigned int @var{flags}})
This function takes the file descriptor @var{fd}, which is expected to
be associated with a socket, and an Assuan context @var{ctx}. The
following bits are currently defined for @var{flags}:
@table @code
@item ASSUAN_SOCKET_SERVER_FDPASSING
If set, @code{sendmsg} and @code{recvmesg} are used for input and
output, which enables the use of descriptor passing.
@item ASSUAN_SOCKET_SERVER_ACCEPTED
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 returning an error value.
@end deftypefun
@noindent
On the Windows platform the following function needs to be called after
@code{assuan_init_socket_server}:
@deftypefun void assuan_set_sock_nonce ( @
@w{assuan_context_t @var{ctx}}, @
@w{assuan_sock_nonce_t *@var{nonce}})
Save a copy of @var{nonce} in context @var{ctx}. This should be used
to register the server's nonce with a context established by
@code{assuan_init_socket_server}. It is technically only needed for
Windows, but it does no harm to use it on other systems.
@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, NULL);
if (rc)
@{
fprintf (stderr, "register failed: %s\n", gpg_strerror (rc));
assuan_release (ctx);
return;
@}
@}
@end example
@deftp {Data type} {gpg_error_t (*assuan_handler_t) (@w{assuan_context_t @var{ctx}}, @w{char *@var{line}})}
This is the function invoked by @sc{Assuan} for various command
related callback functions. Some of these callback functions have a
different type, but most use @code{assuan_handler_t}.
@end deftp
@deftypefun gpg_error_t assuan_register_command (@w{assuan_context_t @var{ctx}}, @w{const char *@var{cmd_string}}, @w{assuan_handler_t @var{handler}}, @w{const char *@var{help_string}})
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: @code{NOP},
@code{CANCEL}, @code{OPTION}, @code{BYE}, @code{AUTH}, @code{RESET}
and @code{END}. It is possible, but not recommended, to override
these commands.
@var{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.
@end deftypefun
@deftypefun gpg_error_t assuan_register_post_cmd_notify (@w{assuan_context_t @var{ctx}}, @w{void (*@var{fnc})(assuan_context_t)}, @w{gpg_error_t @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 gpg_error_t assuan_register_bye_notify (@w{assuan_context_t @var{ctx}}, @w{assuan_handler_t @var{handler}})
Register function @var{fnc} with context @var{ctx} to be called right
before the standard handler for the @code{BYE} command is being called.
@end deftypefun
@deftypefun gpg_error_t assuan_register_reset_notify (@w{assuan_context_t @var{ctx}}, @w{assuan_handler_t @var{handler}})
Register function @var{fnc} with context @var{ctx} to be called right
before the standard handler for the @code{RESET} command is being called.
@end deftypefun
@deftypefun gpg_error_t assuan_register_cancel_notify (@w{assuan_context_t @var{ctx}}, @w{assuan_handler_t @var{handler}})
Register function @var{fnc} with context @var{ctx} to be called right
before the standard handler for the @code{RESET} command is being called.
@end deftypefun
@deftypefun gpg_error_t assuan_register_option_handler (@w{assuan_context_t @var{ctx}}, @w{gpg_error_t (*@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 gpg_error_t assuan_register_input_notify (@w{assuan_context_t @var{ctx}}, @w{assuan_handler_t @var{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 @code{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 @code{INPUT} command may already be used. That file
descriptor is available by calling @code{assuan_get_input_fd}. If the
notification function returns an error, the input fd does not change.
@end deftypefun
@deftypefun gpg_error_t assuan_register_output_notify (@w{assuan_context_t @var{ctx}}, @w{assuan_handler_t @var{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 @code{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 @code{OUTPUT} command may already be used. That file
descriptor is available by calling @code{assuan_get_output_fd}. If the
notification function returns an error, the output fd does not change.
@end deftypefun
@deftypefun gpg_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
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_release (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 gpg_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 value will be returned if the connection could for
some reason not be established. An error code of @code{GPG_ERR_EOF} indicates
the end of the connection.
@end deftypefun
@deftypefun gpg_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 value if something went seriously wrong. Error values from the
individual command handlers, i.e. operational error, are not seen here.
@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 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:
@itemize @bullet
@item
Either partner should always write full lines. If partial lines are
written, the remainder of the line should be 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_release}.
@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} with the final argument being
@code{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: @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 true in @code{done} 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 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 @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 value 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 gpg_error_t assuan_process_next (@w{assuan_context_t @var{ctx}}, @w{int *@var{done}})
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 @var{done} is false.
@end deftypefun
@deftypefun gpg_error_t assuan_process_done (@w{assuan_context_t @var{ctx}}, @w{gpg_error_t @var{rc}})
Finish a pending command and return the error code @var{rc} to the
client.
@end deftypefun
@deftypefun gpg_error_t assuan_inquire_ext (@w{assuan_context_t @var{ctx}}, @w{const char *@var{keyword}}, @w{size_t @var{maxlen}}, @w{gpg_error_t (*@var{cb}) (void *cb_data, gpg_error_t rc, unsigned char *buffer, size_t buffer_len)}, @w{void *@var{cb_data}})
This is similar to @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, and the error value as well as the inquired data as
its remaining arguments.
@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 gpg_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 gpg_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 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 (@var{ctx}) and a description of
the required data (@var{keyword}). All other parameters may be
@code{NULL} or @code{0}, but 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 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
@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 gpg_error_t assuan_set_okay_line (@w{assuan_context_t @var{ctx}}, @w{const char *@var{line}})
Set the text used for the next @code{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 gpg_error_t assuan_command_parse_fd (@w{assuan_context_t @var{ctx}}, @w{char *@var{line}}, @w{assuan_fd_t *@var{rfd}})
This is the core of the default @code{INPUT} and @code{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 @w{const char *} assuan_get_command_name (@w{assuan_context_t @var{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 @code{NULL} if no handler is
executed or the command is not known.
@end deftypefun
@deftypefun assuan_fd_t assuan_get_input_fd (@w{assuan_context_t @var{ctx}})
Return the file descriptor sent by the client using the last @code{INPUT}
command. Returns @code{ASSUAN_INVALID_FD} if no file descriptor is available.
@end deftypefun
@deftypefun assuan_fd_t assuan_get_output_fd (@w{assuan_context_t @var{ctx}})
Return the file descriptor sent by the client using the last
@code{OUTPUT} command. Returns @code{ASSUAN_INVALID_FD} if no file descriptor is
available.
@end deftypefun
@deftypefun gpg_error_t assuan_close_input_fd (@w{assuan_context_t @var{ctx}})
Close the file descriptor set by the last @code{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 gpg_error_t assuan_close_output_fd (@w{assuan_context_t @var{ctx}})
Close the file descriptor set by the last @code{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 gpg_error_t assuan_set_error (@w{assuan_context_t @var{ctx}}, @w{gpg_error_t @var{err}}, @w{const char *@var{text}})
This is a helper to provide a more descriptive error text with @code{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 to humans.
@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{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
@code{SO_PEERCRED} socket option @footnote{to our knowledge only the
Linux kernel has this feature}.
@end deftypefun
@deftp {Data type} {assuan_peercred_t}
This structure is used to store the peer credentials. The available
members depend on the operating system.
@table @code
@item pid_t pid
The process ID of the peer.
@item uid_t uid
The user ID of the peer process.
@item gid_t gid
The group ID of the peer process.
@end table
@end deftp
@deftypefun gpg_error_t assuan_get_peercred (@w{assuan_context_t @var{ctx}}, @w{assuan_peercred_t *@var{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 @var{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 @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{assuan_fd_t *@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
@c
@c S O C K E T W R A P P E R S
@c
@node Socket wrappers
@chapter Socket wrapper functions
@noindent
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.
@deftypefun 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.
@end deftypefun
@deftypefun gpg_error_t assuan_sock_deinit (void)
Deinitialize the socket wrappers.
@end deftypefun
@deftypefun int assuan_sock_close (@w{assuan_fd_t @var{fd}})
Wrapper for close which does a closesocket on Windows if needed.
@end deftypefun
@deftypefun assuan_fd_t assuan_sock_new (@w{int @var{domain}}, @w{int @var{type}}, @w{int @var{proto}});
Wrapper around socket.
@end deftypefun
@deftypefun int assuan_sock_connect (@w{assuan_fd_t @var{sockfd}}, @
@w{struct sockaddr *@var{addr}}, @
@w{int @var{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 @code{assuan_sock_set_sockaddr_un} for
details on the redirection file format.
@end deftypefun
@deftypefun int assuan_sock_connect_byname (@w{const char * @var{host}}, @
@w{unsigned short @var{port}}, @
@w{int @var{reserved}}, @
@w{const char *@var{credentials}}, @
@w{unsigned int @var{flags}})
Directly connect to @var{port} on @var{host} given as a name. The
current implementation requires that @var{flags} has either
@code{ASSUAN_SOCK_SOCKS} or @code{ASSUAN_SOCK_TOR} set. On success a
new TCP STREAM socket is returned; on error @code{ASSUAN_INVALID_FD}
and ERRNO set. If @var{credentials} is not @code{NULL}, it is a
string used for password based SOCKS authentication. Username and
password are separated by a colon. @var{reserved} should be 0. To
test whether the proxy is available @var{host} and @var{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.
@end deftypefun
@deftypefun int assuan_sock_bind ( @
@w{assuan_fd_t @var{sockfd}}, @
@w{struct sockaddr *@var{addr}}, @
@w{int @var{addrlen}})
Wrapper around bind. Under Windows this creates a file and writes the
port number and a random nonce to this file.
@end deftypefun
@deftypefun int assuan_sock_set_sockaddr_un ( @
@w{const char *@var{fname}}, @
@w{struct sockaddr *@var{addr}}, @
@w{int *@var{r_redirected}})
This is a helper function to initialize the Unix socket domain address
structure @var{addr} and store the file name @var{fname} there. If
@var{r_redirected} is not NULL the function checks whether @var{fname}
already exists, is a regular file, and not a socket. In that case
@var{fname} is read to see whether this is a redirection to a socket
file. If that is the case 1 is stored at @var{r_redirected}. If the
file does not look like a redirection file 0 will be stored there and
@var{fname} will be used in the regular way.
The format of a redirection file is
@example
%Assuan%
socket=@var{name}
@end example
With @var{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
@var{name} if given in @code{$@{VAR@}} notation. No escape characters
are defined; if the string @code{$@{} 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.
@end deftypefun
@deftypefun int assuan_sock_get_nonce ( @
@w{struct sockaddr *@var{addr}}, @
@w{int @var{addrlen}}, @
@w{assuan_sock_nonce_t *@var{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.
@end deftypefun
@deftypefun int assuan_sock_check_nonce ( @
@w{assuan_fd_t @var{fd}}, @
@w{assuan_sock_nonce_t *@var{nonce}})
If the option @code{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. @code{ASSUAN_SOCKET_SERVER_ACCEPTED} has not been used) because
in this case Libassuan calls this function internally. See also
@code{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.
@end deftypefun
To control certain properties of the wrapper two additional functions
are provided:
@deftypefun int assuan_sock_set_flag ( @
@w{assuan_fd_t @var{fd}}, @
@w{const char *@var{name}}, @
@w{int @var{value}})
Set the flags @var{name} for socket @var{fd} to @var{value}. See
below for a list of valid names. Returns 0 on success; on failure
sets ERRNO and returns -1.
@end deftypefun
@deftypefun int assuan_sock_get_flag ( @
@w{assuan_fd_t @var{fd}}, @
@w{const char *@var{name}}, @
@w{int *@var{r_value}})
Store the current value of the flag @var{name} for socket @var{fd} at
@var{r_value}. See below for a list of valid names. Returns 0 on
success; on failure sets ERRNO and returns -1.
@end deftypefun
The supported flags are:
@table @code
@item 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.
@item tor-mode
@itemx socks
If @var{value} is 1 globally enable SOCKS5 mode for new connections
using IPv6 or IPv4. @var{fd} must be set to @code{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.
@end table
@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