Add "dumpconfig" command to onak to aide configuration file migration
onak is capable of parsing both old and new style configuration files,
but future improvements will only be added to the new style. To aide
users in the migration to the new format add a "dumpconfig" option to
the onak binary which will dump the current configuration in new format.
onak's config file format grew from the pksd config style. pksd is long
obsolete and there are a number of features it would be nice to support
in onak which this config format makes hard to support cleanly. Move to
a .ini style config file, with [section] and name=value definitions. The
old format is still supported and at present an old style config is
searched for first to ensure smooth upgrades, but any new config options
will only be supported by the new style.
Additionally add tests against both old + new config styles for all
backends.
onak + wotsap were failing to free the memory allocated for the config
file name if it was passed on the command line, and the config structure
cleanups failed to free any configured sock_dir or the actual DB
backend config structure. All of this gets cleaned up by normal program
exit (which is when we do our clean-up anyway), but fix it anyway.
Rather than having each test script hard code the config file that
should be use, have the top level runtests script pass the filename
to use as the config in as a command line parameter.
The indentation in the config file reading function is horrible, so
pull the actual parsing of the line out to its own function simplifying
the loop to primarily be about reading each line and trimming white
space.
Parse pks_bin_dir / mail_dir in the C config handling
pks_bin_dir and mail_dir are only used by the Perl that handles
incoming keyserver email, but parse them in the C code rather than
just ignoring them. This helps pave the way for some config file format
changes and tightening up the parsing to complain about unused options.
Fix compilation breakage introduced in last commit
An unrelated change sneaked in as part of the proper splitting out of
backend database configuration - configuration initialisation for not
yet present config options. Remove them.
While database backends have had private context for some time they've
all been using the same configuration details from the global config
structure. Create a new DB specific config structure and initialise
a single instance from the config file. Also modify the DB backend
initialise functions to take this config structure as a parameter.
This will allow in the future for multiple different backends (whether
the same type or different) to be included at the same time.
Switch to C99 struct initialisation for default configuration
Inbound changes to the configuration file handling will change the
config structure around. Switch to using C99 style initialisation, which
is much clearer to read and reduces the risk of assigning values to the
wrong configuration variable.
Switch to using mail_dir for incoming mail lock file
Rather than using the db_dir for the lock file to prevent multiple
onak-mail instances processing incoming requests at the same time, use
the mail_dir file where the incoming messages are spooled anyway. This
is cleaner and will cope with the potential for multiple DB backends to
be in play in the future.
Rather than putting our socket in $localstatedir/run use $runstatedir
which is support by the Debian package autoconf 2.69-9 and will be in
autoconf 2.70. Fall back to $localstatedir/run when an older version
of autoconf is used.
Add config option to specify keyd socket directory
keyd was stashing its Unix domain socket in the DB directory, which
is contrary to convention. Add a sock_dir config option and default it
to ${prefix}/var/run in the sample config file.
GnuPG will incorrectly add a pre-existing subkey that it doesn't
understand (e.g. ECC) to a key. This results in keys with a large
number of identical subkeys. Avoid this by detecting such keys and
de-duplicating the identical subkeys.
(gnupg bug report at https://bugs.gnupg.org/gnupg/issue1962)
Re-order linking for backend plugins to cope with ld --as-needed
The shared libraries for DB4/curl/PostgreSQL should all come after the
object file that uses them so that ld --as-needed can correctly pick up
the required linkage.
Don't build-depend on Debian systemd dev packages for non-Linux architectures
Later versions of systemd aren't build on FreeBSD etc so the Debian build
was failing due to an unmet build-dep on libsystemd-dev; limit this
requirement to Linux archs.
Fixes Debian bug #763924. Thanks to Pino Toscano <pino@debian.org>
Check for sd_listen_fds in libsystemd as well as libsystemd-daemon
Upstream systemd has moved the sd_listen_fds function from
libsystemd-daemon into a combined libsystemd. For Debian this change
happens in the 214-1 package. Make the autoconf script look in both
and change the Debian build-deps to look for either suitably
recent libsystemd-dev or fall back to libsystemd-daemon-dev (to aid
backports).
The use of strtoul to parse the key ID breaks parsing 64 bit key IDs
on 32 bit platforms. Use strtouq instead, which is defined as returning
a 64 bit rather than being dependant on the length of "unsigned long".
Enable use of systemd + socket activation support for Debian package
Now that onak supports systemd socket activation add the appropriate
systemd service files to enable this on Debian installs. In the longer
term I'd like this to be generic for any distro; patches from people
experienced with them most welcome.
If we have libsystemd-daemon available then enable support for
systemd socket activation of keyd. Even if this support is compiled
in we will fall back to the old behaviour of setting up our own
listening Unix domain socket if systemd is not in use.
Use common function for command sending in keyd client code
Rather than duplicating the checks for writing ok and getting a non
error response use a common function for sending commands to keyd from
the DB backend client code.
Cleanup key array logic to make llvm scan-build happier
We can't have the size != 0 without keys != NULL, but the fact we
checked one at the start and the other later was confusing the static
checks from scan-build. Use size in both places; it keeps scan-build
happy and make the code a little easier to read.
Make keyd more robust in the face of socket errors
We were mostly ignoring errors back from reads or writes to the keyd
socket. Check that we've read/written as many bytes as we expect and
pull some of this out to common functions for sending keys/replies.
Check return value when writing PID to DB4 upgrade lock file
When writing our PID to the lock file for upgrading the DB4 version
we didn't check it was actually successful. This doesn't matter in
general (because it's the existence or not of the file we care about)
but catch it and error out appropriate anyway.
Fix issue with looking up keys by fingerprint via HKP interface
The index variable for the current parameter was being reused to parse
the fingerprint, resulting in attempting to free an unallocated piece of
memory and crashing. Use a different loop variable instead.
With the changes to the backends to store keys using the full fingerprints
it can be useful to force a key to be re-indexed and thus transitioned to
a fingerprint rather than 64 bit key id index. Ideally we'd want to be
able to do this across the entire backend, but that's a bit heavyweight for
a full keyserver so add the ability to do it for a single key to start with.
Check that signature data lengths do not exceed the available data
Some signatures have been witnessed on the keyserver network where the
hashed data lengths reported exceed the size of the overall packet. It
is assumed these are the results of some corruption somewhere, so if
they're detected don't try to parse any further (and drop them if we're
doing signature checking).
Don't end an existing transaction if trying to delete a non-existent key
The DB4 key deletion routine would always exit the current transaction
if the key wasn't found, even if it had been called by another function
which had entered the transaction. Only do so if the deletion routine
itself is what caused the transaction to be started.
Up until now the DB4 backend has used the 64 bit key ID as the index
into the key database. The fingerprint has always been a better idea
and it's easy to create a v3 key that causes a collision, so switch to
using the fingerprint in the DB4 backend.
These changes to not require an upgrade to an existing DB4 setup; keys
will get transitioned to the new storage method as they are updated in
the keyserver.
Observed in keys sent to the keyserver and taken from either RFC 4880
or the source of various older PGP implementations. Some of these are
legacy but we can identify and ignore them.
Switch keysubkeys to returning an array of fingerprints instead of IDs
No functional change at present because the users only currently use the
64 bit key ID, so add a helper function fingerprint2keyid as well (which
only works for v4 keys, but v3 keys can't have subkeys).
Introduce and use a structure to hold OpenPGP fingerprints
Fingerprint lengths can be 16 bytes (for v3 keys) or 20 bytes (for v4
keys). Rather than passing around a size and fingerprint buffer separately
use a structure to hold both pieces of information and just pass that
around.
Fix issues found by llvm scan-build static analysis
A mixture of fixes: some variables set but never used (fix by either
removing or correctly checking error codes), some unlikely but possible
memory leaks, some invalid casting.
Rather than defining a static set of database functions use a well
known initialisation function for each database backend that then
returns a database context structure. This structure contains function
pointers for all of the functions previously held in dbstructs as well
as a private instance context pointer.
For the moment this doesn't provide any change to behaviour, but it
provides the initial preparation for allowing multiple database instance
(whether of the same or differing types) to be used at the same time.
A hash variant that uses 8 SHA-1 instances and results in a double width
hash (320 bits instead of SHA-1's 160 bits). This was used in older
versions of PGP and there are quite a few keys on the keyservers with
signatures using it. Added mainly to enable the sig hash checking
routine to do some sanity checking on these signatures.
This was originally for pulling keys from an old pksd keyserver setup.
The code has bit-rotted and no one should have been running pksd for
years now, so just remove the backend entirely. DB4 has been the best
choice for onak backend for some time now.
Extend database backends to support fetching by key fingerprint
Up until now the database backends have supported fetching a specific
key only by 64 bit key id. We should really have been using the
fingerprint where possible. Add a new backend function, fetch_key_fp,
to allow us to fetch using the fingerprint, and a generic implementation
that just truncates the fingerprint to get the 64 bit key id (valid for
v4 only). The HKP, keyd and dynamic backends gain full passthrough
support for retrieval by fingerprint with this commit.
The key size of an elliptic curve key is given by the OID defining the
curve. Add support for understanding the OIDs listed in RFC6637 (256,
384 + 521 bits).
Old versions of GnuPG put Elgamal (type 16) keys inside v3 packets.
The method of getting the keyid for these keys was via a RIPE MD160
hash approach similar to the SHA-1 approach used in v4. While nothing
supports this these days there are keys in the public keyserver
network that contain this sort of data and if we don't parse the keyid
correctly we can't show things like self-sigs.
With the increased use of signature subkeys and the fact long
keyids are being used to do HKP lookups we need to store a mapping
of the subkey long keyids to primary key ids. Previously the fact
we did this for the 32 bit subkey id was enough. Add a new DB for
the DB4 backend that can map the 64 bit subkey ID to the 64 bit
primary key ID.
Check that libcurl supports SSL if using HKPS with HKP backend
Use CURL's runtime feature checking to ensure that we have support
for SSL before trying to use a HKPS (HTTPS) remote keyserver with
the HKP keydb backend.
Try to use a user specific configuration file if available
Try looking for $XDG_CONFIG_HOME/onak.conf (or $HOME/.config/onak.conf
if $XDG_CONFIG_HOME is not set) before looking for the system wide
config file. This allows users to use their own config file without
having to always use the -c option to provide it.
A harmless failure to cleanup the config structure before exiting
keydctl and a more major (small, but key runs for a long period of
time) leak of the search string for fetching a key by text string
in keyd.
wotsap wasn't paying attention to keys that were revoked, leading to them
being included in the output key/signature lists. Force the load of a key
before colouring it so we can ignore it if it's revoked.
The initial commit of the HKP backend just took a hostname as the "db_dir"
parameter. Extend this to cope with an http:// or hkp:// style URL, allowing
the port to be specified as well.
Clean up use of K&R style function definitions in md5.c
md5_process_block / md5_read_ctx had K&R style function definitions.
Clean them up to use ANSI C style like the rest of the code (including
other functions in that file). Spotted by Doxygen.
Switch keyd to allow multiple clients to be served at once
keyd was only accepting a single connection at a time and dealing with
all the requests from it before accepting the next client. This causes
delays in regular HKP processing while running something like wotsap on
a live keyserver.
Most of the pieces were already in place to deal with a per request select
based processing loop, so this commit switches to that model. A better
solution in the future may be to consider the use of libevent or libev,
but at present this enables the use of long runs stats programs while
still being able to service HKP requests in reasonable time.
A potential use case of onak is as a proxy server. Add an HKP backend
that uses libcurl to make requests to a remote keyserver to fetch, search
or store keys. The "db_dir" configuration parameter becomes the base
host name for the remote keyserver e.g.:
db_backend hkp
db_dir the.earth.li
In the future the addition of the ability to stack database backends
should allow this to be used to turn onak into a caching keyserver.
projects / onak.git / log