The LOCK and UNLOCK by PIN requests were acting on the supplied PIN
and also the empty PIN, due to a bug in ob_get_str_ptr(), which returned
an empty string instead of NULL after reaching the end of the string
list.
- make "debug.h" a private header so that the DEBUG() macro does not
interfere with Xcode Debug builds, which set DEBUG=1
- move all #include "debug.h" from headers into .c files
- move 'struct idebug' into a new public header "idebug.h" so that
"log.h" can be public
- move HTTPD port number defs from "httpd.h" to "constants.h", so that
"httpd.h" can be private and "conf.h" can be public
- add missing nested includes so each header compiles stand-alone
without error
- #include "sodium.h" instead of <sodium.h>
- #include "sqlite3.h" instead of <sqlite3.h>
- add header guard to "fifo.h"
- fix header guard in "sync_keys.h"
The new ios/configure script performs a separate ../configure for each of
the following iOS targets:
iPhoneOS on armv7
iPhoneOS on arm64
iPhoneSimulator on i386
iPhoneSimulator on x86_64
The script then creates ios/Makefile that builds a static iOS Framework
Bundle suitable for inclusion in an Xcode iOS project.
Add the --xcode-sdk=SDK option to configure.ac, to support cross
compiling using Apple Xcode. It prefixes all compile/link toolchain
commands with the "xcrun --sdk SDK" command, ie, CC, AS, LD, AR, RANLIB,
etc.
Re-structure headerfiles.mk to separate "public" from "private" headers,
because the Framework module only exposes the public ones. Moves the
SQLITE3_AMALGAMATION definition from Makefile.in into headerfiles.mk.
Update INSTALL.md and add a technical document for Apple iOS.
This enables development of Serval DNA within the context of an Xcode
iOS project using the standard edit-make-test cycle: after modifying a
Serval DNA source file, "cd ios; make" will recompile the changed file
for all the target architectures and update the Framework Bundle.
Rebuilding the Xcode project will then incorporate the changes, which
can be tested immediately.
The daemon API is built as a Swift module called ServalDNA.
The new CliContext class allows easy implementation of CLI output using
Swift code. The new CliContextFile subclass is the obvious first
implementation, equivalent to cli_stdio.c. The 'servaldswift'
executable now uses CliContextFile to print its CLI output to standard
output.
The new delegated log output support constructs each log line in a
buffer and prints it by calling the delegate's 'print' function at
end-of-line. The 'servaldswift' executable now provides a log output
delegate in Swift that simply prints to standard error, replacing
log_output_console.o, which is omitted from its link.
Add a swift-client-api subdirectory containing a Swift source package
and a Makefile.in that compiles it into the "ServalClient" Swift module
using the Swift package manager. The Swift API contains the following
classes:
- ServalKeyring provides the operations: add, remove, set, list
- AbstractId and its specialisation SubscriberId, already in near-final
form, are data types for SID and the like
- ServalRestfulClient (internal) uses an HTTP client to access the
Serval DNA RESTful interface
Improve the REST /keyring/set operation to only alter the DID or Name if
the corresponding query parameter is supplied. Modify the internal
keyring_set_did() function to only assign the DID or Name if the
corresponding parameter is not a null pointer.
The configure script ensures that the Swift build target version is
10.10 or later when compiling for Mac OS-X, so that the package manager
will succeed.
Add autoconf macros for the Swift package manager.
If the Swift 3 or Swift 4 compiler is present or passed to the configure
script in the SWIFTC variable, then the Makefile will compile a Swift
'servaldswift' executable to ensure that the module map links correctly
into a stand-alone Swift program.
Use the gold linker if supported, to avoid relocation errors on symbols
produced by Swift when linking dynamic libraries.
Update the Java API to be consistent with recent changes to the Rhizome
REST API was that regularised the MIME types used in Content-Type
headers.
Add some missing CONTENT_TYPE_ constants to "httpd.h", and ensure they
are consistent with the Java getMimeType() methods in subclasses of
AbstractId.
Add the --stderr option to all executeJavaOk statements in the
'rhizomejava' test script, to reveal the exception message in the case
of failure.
Add a test script for all Java tests, called "alljava".
Include testconfig.sh in testdefs.sh, not testdefs_java.sh, so that the
tests/all script can successfully test the $JAVAC variable.
Rename the logging primitive functions and utility functions, prefixing
all with 'serval_log', eg: logMessage() -> serval_logf() etc.
Add an XPRINTF xhexdump() function and use it to implement the
serval_log_hexdump() utility, renamed from dump(). Add macros
WHY_dump(), WARN_dump(), HINT_dump() and DEBUG_dump(), and use them
everywhere.
Remove the 'log.console.dump_config' and 'log.file.dump_config'
configuration options; configuration is now dumped in every log prolog.
The logging system now constructs the log prolog by invoking the new
'log_prolog' trigger, so that it no longer depends on the version string
and configuration system. Any system that wants to present a message in
the log prolog can define its own trigger, which calls standard log
primitives to print the message.
Split the logging system into a front-end (log.c) that provides the
logging primitives and is independent of the configuration system, and a
set of back-end "outputters" (log_output_console.c, log_output_file.c,
log_output_android.c) that may depend on the configuration system and
are decoupled from the front-end using the 'logoutput' link section.
These log outputters are explicitly linked into executables by the
Makefile rules, but could also be linked in using USE_FEATURE(). The
USE_FEATURE() calls have _not_ been added to servald_features.c, so that
different daemon executables can be built with the same feature set but
different log outputs.
The strbuf_local_buf() function attempted to detect if its argument was
not an array but a pointer, and fail at compile time. This worked fine
when compiling with standard optimisation (-O2).
However, specifying the gcc -g option disables compiler optimisation, so
the compiler does not optimise away the call to the function with
__attribute__(error("...")), and so the compile fails.
The solution is to perform the check at run time using assert(), like
strbuf_local() already does.
Correct the maximum DID length defined in "serval_types.h" from 32 to
31. Add a definition of the maximum identity Name length and use it
instead of the bare constant 64, eg, in the MDP_DNALOOKUP request
handling code.
Introduce a dataformats.h function for validating an identity name, and
use it to validate the 'name' parameter in the CLI 'keyring set'
command.
Add 'did' and 'name' parameter validation to the GET /restful/keyring/add
and GET /restful/keyring/SID/set requests (#131).
Rename keyring_set_did() to keyring_set_did_name() and assert that DID
and Name lengths have been validated before storing in the keyring.
Update the Keyring REST API tech document.
Use the conventional autoconf @srcdir@ substitution instead of requiring
the SOURCE_PREFIX variable to be passed to the Makefile.
Also support running test scripts in an out-of-tree build directory.
The REST Rhizome import request now requires the 'id' and 'version'
query parameters to either both be supplied or neither, and fails if
they do not match the manifest that is supplied in the request body.
Added a test case for this.
Added a test case to ensure that if the 'id' and 'version' query
parameters cause a hit (already in store) then the response is sent
immediately without reading the request body.
Improve the documentation for the REST Rhizome import request.
Users and contributors have had difficulty working out how to use the
more complex requests in the REST interface, particularly POST
/restful/rhizome/insert.
Improve the Markdown documentation to provide concrete examples of POST
requests and provide much more extensive description of how to use the
"multipart/form-data" Content-Type.
The static file server now sets the Content-Type of the response
depending on the file name extension:
.txt = text/plain; charset=utf-8
.htm .html = text/html; charset=utf-8
.json = application/json
.rfm = rhizome/manifest; format=text+binarysig
Undo a change from late 2015 that allowed the format=text+binarysig
parameter of the rhizome/manifest MIME content-type to be optional -- it
is easy to provide that parameter via libcurl, and the lbard code has
just been updated to provide it.
Make Content-Type handling consistent throughout the Serval DNA code by
using 'struct mime_content_type' to represent both parsed (request) and
sent (response) Content-Type fields, replacing ad-hoc in-line string
literals.
Fix some TODOs by adding the "serval/sid", "rhizome/bid" and
"rhizome/bundlesecret" MIME types, which remain optional for the time
being to preserve REST API compatibility with clients that do not set
the Content-Type of their 'bundle-author', 'bundle-id' and
'bundle-secret' parameters.
These trace files make it easier to see the innards of REST
API requests and responses, which improves the value of tests
as API specification/documentation.
