Horribly broken, but it compiles.
.../tests/fsck$ ./run_fsck.bash
Reading password from extpass program "echo", arguments: ["test"]
Decrypting master key
OpenDir ".": invalid entry "invalid_file_name.3": illegal base64 data at input byte 17
OpenDir ".": invalid entry "invalid_file_name_2": bad message
fsck: corrupt entry in dir "": "invalid_file_name.3"
fsck: corrupt entry in dir "": "invalid_file_name_2"
OpenDir ".": invalid entry "invalid_file_name____1": bad message
fsck: corrupt entry in dir "": "invalid_file_name____1"
fsck: error stating file ".go-fuse.5577006791947779410/deleted": no such file or directory
fsck: error listing xattrs on ".go-fuse.13260572831089785859/deleted": no such file or directory
fsck: error opening dir "i10488239 (dir): ": no such file or directory
fsck: error reading symlink ".go-fuse.10667007354186551956/deleted": no such file or directory
fsck: error listing xattrs on ".go-fuse.11998794077335055257/deleted": no such file or directory
[...]
We need
fd7328faf9
to fix a crash reported in https://github.com/rfjakob/gocryptfs/issues/430 :
2019/10/30 17:14:16 Unknown opcode 2016
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x508d38]
This patch is only in the v2.x.x branch. Upgrade to v2, as the
old API is also supported there.
Running
git grep hanwen/go-fuse | grep -v hanwen/go-fuse/v2
to check for forgotten references comes back clean.
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.
