Output now looks like this
$ gocryptfs -speed
gocryptfs v1.7.1-38-gbe3b9df-dirty; go-fuse v2.0.2-57-gd1cfa17; 2020-04-13 go1.13.6 linux/amd64
AES-GCM-256-OpenSSL 607.90 MB/s
AES-GCM-256-Go 920.75 MB/s (selected in auto mode)
AES-SIV-512-Go 169.85 MB/s
XChaCha20-Poly1305-Go 794.30 MB/s
and has go version and arch information, which is important
when comparing results.
CheckTrailingGarbage was called even when "-passfile" was
used, which is stupid, and causes false positives:
https://github.com/rfjakob/gocryptfs/issues/391
(false error "Received trailing garbage after the password"
when using -passfile in .bash_profile)
Instead of trying to improve the logic to handle that case
and make everything even more complicated, delete the function.
It is unclear if actually helps in some cases, and it definitely
harms as shown by the above bug report.
The files are apparently processed in alphabetic order, so cli_args.go is
processed before main.go. In order to run before the go-fuse imports, put
the 'ensure fds' code in a separate package. Debug messages are omitted
to avoid additional imports (that might contain other code messing up our
file descriptors).
Show enable_trezor in the version string if we were compiled
with `-tags enable_trezor`. And hide the `-trezor` flag from
the help output if we were not.
TrezorPayload stores 32 random bytes used for unlocking
the master key using a Trezor security module. The randomness makes sure
that a unique unlock value is used for each gocryptfs filesystem.
mount(1) unsets PATH before calling mount.fuse. Therefore it's not set
in gocrpytfs either and daemonization fails if gocryptfs was not
executed via an absolute path.
mount.fuse handles this by leaving the execution of the helper to
/bin/sh. /bin/sh handles an empty PATH by searching a few default
locations.
This patch sets the PATH to a sane default if it's empty or unset.
Most corruption cases except xattr should be covered.
With test filesystem.
The output is still pretty ugly. xattr support will
be added in the next commits.
Overwrite the masterkey with zeros once we
have encrypted it, and let it run out of scope.
Also get rid of the password duplicate in
readpassword.Twice.
...and move all profiling functionality to its own file, as
the main function is already long enough.
Periodically saving the memory profile allows capturing the used
memory during normal operation, as opposed to on exit, where the
kernel has already issued FORGETs for all inodes.
This functionality has been used to create the memory profile shown
in https://github.com/rfjakob/gocryptfs/issues/132 .
Before Go 1.5, GOMAXPROCS defaulted to 1, hence it made
sense to unconditionally increase it to 4.
But since Go 1.5, GOMAXPROCS defaults to the number of cores,
so don't keep it from increasing above 4.
Also, update the performance numbers.
We have accumulated so many options over time that they
no longer fit on the screen.
Display only a useful subset of options to the user unless
they pass "-hh".
This commit defines all exit codes in one place in the exitcodes
package.
Also, it adds a test to verify the exit code on incorrect
password, which is what SiriKali cares about the most.
Fixes https://github.com/rfjakob/gocryptfs/issues/77 .
Now looks like this:
$ ./gocryptfs -version
gocryptfs [GitVersion not set - please compile using ./build.bash]; go-fuse [GitVersionFuse not set - please compile using ./build.bash]; 0000-00-00 go1.8
Hopefully easier to grep for.
A crypto benchmark mode like "openssl speed".
Example run:
$ ./gocryptfs -speed
AES-GCM-256-OpenSSL 180.89 MB/s (selected in auto mode)
AES-GCM-256-Go 48.19 MB/s
AES-SIV-512-Go 37.40 MB/s
From the comment:
// CheckTrailingGarbage tries to read one byte from stdin and exits with a
// fatal error if the read returns any data.
// This is meant to be called after reading the password, when there is no more
// data expected. This helps to catch problems with third-party tools that
// interface with gocryptfs.
