The LIBMTP_Open_Raw_Device_Uncached function may return NULL if
an error occurs when attempting to open the device. We need to
check for that possibility.
Incenp-bug-id: 6
(This patch will prevent the crash observed in that bug, but it
does not fix the fact that LIBMTP sometimes fails to open the
device.)
At the end of the interactive menu, the number of shares to create
is printed; this was needed at one point during the development of
the menu, but is not needed anymore.
Using relative paths for shares is not supported, so when manually
assigning a path to a share (instead of parsing a URI), we make
sure the path starts with a '/'.
A single "GIO volume" is not descriptive enough to allow the user
to identify the corresponding volume, so we add either the label
or the UUID in the string.
In the future, we could even add the volume's size, as in
"External 2GB volume with label 'LABEL'".
This patch is the first step toward the implementation of an
interactive mode for gfsec-split, which will allow the user to
choose which external devices she want to create a share onto.
Add a -k, --keep option to gfsec-use to allow the user to keep
the reconstructed file instead of removing it upon termination of
the command.
As a special case, we do not spawn a shell if no command to run is
specified and the file is to be kept.
Incenp-bug-id: 3
Commit b18609a, in which the syntax of the gfsec-split command was
changed, introduced a regression preventing the removal of the
original secret file once the shares have been generated. This is
because the code taking care of removing the file still assumed
the filename of the secret file was still the last argument of the
command line, which is not true anymore.
Incenp-bug-id: 4
Commit 609ab3c introduced a regression in which local shares
could not be used because a non-NULL zero-length authority
string was compared to "localhost". The comparison should only
be attempted on a non-NULL, non-empty string.
Incenp-bug-id: 5
When using the file:// scheme, we should accept an authority
part which refers to the local machine. It has no use (since we
do not support file:// URIs pointing to other hosts), but it is
consistent with what the user accustomed to file:// URIs might
expect.
The xstrndup function should take care of always adding a NULL
byte at the end of the copied string, to match the behavior of
the original strndup function.
Use die-on-error memory-allocating functions, and use assert()
to check for arguments validity. Passing a NULL pointer to anyone
of these functions is a programming error anyway, not a runtime
error.
I plan to modify the behavior of the entire programs to stop
caring about memory allocation failures. There's nothing much to
do anyway in case of a system running out of memory, and besides,
Linux's behavior of never failing to allocate memory means that I
cannot properly test the code paths in case of ENOMEM. So I came
to think the best way of handling ENOMEM is just to abandon
completely.
This patch adds die-on-error versions of some common
memory-allocating functions.
The error message for the NOT_ENOUGH_SHARES error case is too
long, and should not say "to reconstitute the secret" since that
error may also occur when splitting a secret.
The rc variable in the get_file function in the libmtp-based
module was not initialized, leading to a random return code when
no MTP device is present. This could lead to a crash if the
returned value happened to be zero, which is interpreted as a
success by the calling code (which then assumes that the share
has been successfully retrieved).
The GIO-based module will no longer attempt to create parent
directories when writing a share. Parent directories are assumed
to exist, and the module will throw an error if they do not.
It is simpler and more consistent with the behavior of the other
modules.
The put_file of the libmtp-based scheme module now supports
sending a file to any (pre-existing) directory on the device,
instead of only the root directory.
Add the gfsec-split program to split a secret into shares,
dispatch the shares to specific locations, and write a
configuration file allowing to reconstitute the secret using
the gfsec-use program.
Add a new function to the scheme module interface, to write a
file's contents at a specified location.
Only the file module implemements this function for now.