You can configure xiden using environment variables, the command line interface, and/or a runtime configuration file. Every setting has only one name, and a contract for accepted Racket values.
The Changing a Runtime Configuration Value section covers how to change the value of a setting.
Each workspace can have its own runtime configuration file, or rcfile. When Xiden selects a workspace directory, it will load etc/xiden.rkt and use it as a source of setting values. Here’s an example of what that file might look like:
A consequence of the rules in Changing a Runtime Configuration Value is that you cannot combine short flags into strings like -vUi. Every flag requires an argument, so the flags may appear as -v '#t' -U '#f' -i '#t'.
Verbose commands are more painful to type, so why do it this way? Because there are a few benefits to this approach:
Passing values to flags keeps the entire command explicit and self-describing. Let’s say XIDEN_VERBOSE is #t due to an environment variable or rcfile. Assuming that you do not change the environment variable, you would not be able to change that back to #f in a command line without expressing #f.
What you type is what gets used at runtime, so long as it meets a contract. This makes commands easier to predict for Racket programmers, because they can visualize exact values at play.
Every setting has a canonical name, meaning that no matter where you define a value, you can use the same name. Short flags are merely bound to the same setting as the flags with canonical names.
$ XIDEN_VERBOSE="#t" xiden ...
$ xiden --XIDEN_VERBOSE "#t" ...
$ xiden -v "#t" ...
XIDEN_WORKSPACE defines the directory to use as the workspace.
XIDEN_WORKSPACE can only be set using the environment variable of the same name. This is because all other settings check a workspace-specific configuration file, and that file cannot be known until XIDEN_WORKSPACE is set.
XIDEN_WORKSPACE must be a complete-path?. If the path points to an existing entry on the filesystem, then that entry must be a directory. If the path points to no existing entry, then xiden will create a directory at that path.
You can use Xiden’s integrity checking system to specify public keys and executables that you trust. You specify the integrity information the same way that you would for an input in a package definition.
(define XIDEN_TRUSTED_PUBLIC_KEYS (list (integrity 'sha384 (hex "d925eca70c5adfa1d7722cf6c1fb667ed3e7967715a4eaecf52e342663f88231de39f96293e719a27ade3d87666ae54"))))
Notice that this is not a fingerprint, it is integrity information for an entire (trusted) public key file. This avoids collision attacks due to short fingerprint lengths, but not collision attacks based on the digest algorithm. If a digest algorithm is subject to a collision attack, you can upgrade the algorithm and expected digest.
This example value for XIDEN_TRUSTED_EXECUTABLES similarly verifies binaries that Xiden may use for a subprocess. This example shows integrity information for a Python 2.7 binary.
(define XIDEN_TRUSTED_EXECUTABLES (list (integrity 'sha1 (hex "3b1c5bcf6d6c0f584a07aed26ad18299b5a8311d"))))
Note that the integrity information applies only to the named executable. This system will not detect something like a compromised dynamically-linked library.