The command line default timeout of 60 seconds always took precedence,
we removed it. Also added a debug statement that lets the user know how
long they will have to wait.
This is kind of hacky, but it avoids the segfault at runtime. So,
preferrable. If we ever have more options, we need to properly generate
the argv[] array.
Name the flag exactly as it's used by LUKS everywhere: allow_discards
(we had in some places "discard", "allow_discard"). Implement actually
honoring that flag if it's set. Untested code.
While we're at it with migration, might as well add a host_flags field
so that if we have host-specific configuration flags we want to add
later on, we only have to do a migration once.
Pretty raw and untested code which migrates data from v2 to v3,
introducing a new field in the process. This field is neither editable
as of now nor is it honored if it were set.
We want to introduce a new feature (volumes with discard support) which
will cause file incompatibility. This means we need to prepare data
migration code. This prepares that change.
We currently derive the dkey from the source key at every open or close
(decrypt or encrypt) operation. However, we want to keep the time that
the internal data is exposed (decrypted) as short as possible. While the
vault is open, there's no problem keeping a copy of the dkey around
(because the data is decrypted anyways, therefore it isn't important).
So we change things around and, at the expense of doubling the time that
decryption takes, we make encryption extremely fast. We do this by
computing the next (rekeyed) key at the start of the decryption routine
(but before the data has been decrypted) and keep the dkey stored in the
vault structure for direct access on the next encryption run.
We want to keep the dkey in the vault structure as long as it's open
(because only the open operation should take long, the close operation
should be really fast).
Now all keys are encrypted when they're not in use to thwart cold-boot
attacks. Furthermore, all unlocking messages are sent in bulk to avoid
fragmentation and improve performance.
Previously, we wrote the passphrase contents to a temporary file on
/dev/shm and then wiped it afterwards. This is odd, why don't we use a
pipe for this purpose, like it's intended to be used? Replace all of
that previous code by piped IPC.
We'll now parse the response messages on the client side, abort after a
previously defined timeout and trigger the LUKS unlocking process, if
requested (although the latter isn't fully implemented yet).
Clients now broadcast their host UUID and magic number via UDP, but the
server does not respond nor would the client trigger anything if the
server did.
