The trezor libraries are not yet stable enough to build
gocryptfs with trezor support by default.
It does not even compile at the moment:
$ ./build.bash -tags enable_trezor
# github.com/conejoninja/tesoro/vendor/github.com/trezor/usbhid
../../conejoninja/tesoro/vendor/github.com/trezor/usbhid/hid.go:32:11: fatal error: os/threads_posix.c: No such file or directory
#include "os/threads_posix.c"
^~~~~~~~~~~~~~~~~~~~
compilation terminated.
https://github.com/conejoninja/tesoro/issues/9
If we encounter a 128KB block of zeros, try to skip to the next
data section by calling File.SeekData().
This fixes xfstests generic/285, which creates a 17TB sparse file,
and runs fsck afterwards. Without this optimization, fsck would
take ages.
"gocryptfs -fsck" will need access to helper functions,
and to get that, it will need to cast a gofuse.File to a
fusefrontend.File. Make fusefrontend.File exported to make
this work.
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.
We are clean again.
Warnings were:
internal/fusefrontend/fs.go:443:14: should omit type string from declaration
of var cTarget; it will be inferred from the right-hand side
internal/fusefrontend/xattr.go:26:1: comment on exported method FS.GetXAttr
should be of the form "GetXAttr ..."
internal/syscallcompat/sys_common.go:9:7: exported const PATH_MAX should have
comment or be unexported
Gopkg.toml was emptied out by commit c3e12b5e68 which
seemed to work fine at the time. It turns out that, in
absence of a
branch = "master"
constraint, dep will use the last tag. We want latest
master, as this is what "go get" fetches, and hence
what Travis uses for testing.
Reading system.posix_acl_access and system.posix_acl_default
should return EOPNOTSUPP to inform user-space that we do not
support ACLs.
xftestest essientially does
chacl -l | grep "Operation not supported"
to determine if the filesystem supports ACLs, and used to
wrongly believe that gocryptfs does.
Don't dump the help text on the unsuspecting user, but
give a short error message:
$ gocryptfs -foobar
flag provided but not defined: -foobar
Invalid command line: gocryptfs -foobar. Try 'gocryptfs -help'.
For comparison: This is what cp does:
$ cp --foo
cp: unrecognized option '--foo'
Try 'cp --help' for more information.
And this what we used to do:
$ gocryptfs -foobar
flag provided but not defined: -foobar
gocryptfs v1.4.4-45-gfb772da; go-fuse v20170619-35-gb16719c; 2018-06-08 go1.10.2
Usage: gocryptfs -init|-passwd|-info [OPTIONS] CIPHERDIR
or gocryptfs [OPTIONS] CIPHERDIR MOUNTPOINT
Common Options (use -hh to show all):
-aessiv Use AES-SIV encryption (with -init)
-allow_other Allow other users to access the mount
-config Custom path to config file
-ctlsock Create control socket at location
-extpass Call external program to prompt for the password
-fg Stay in the foreground
-fusedebug Debug FUSE calls
-h, -help This short help text
-hh Long help text with all options
-init Initialize encrypted directory
-info Display information about encrypted directory
-masterkey Mount with explicit master key instead of password
-nonempty Allow mounting over non-empty directory
-nosyslog Do not redirect log messages to syslog
-passfile Read password from file
-passwd Change password
-plaintextnames Do not encrypt file names (with -init)
-q, -quiet Silence informational messages
-reverse Enable reverse mode
-ro Mount read-only
-speed Run crypto speed test
-version Print version information
-- Stop option parsing
You passed: "-foobar"
flag provided but not defined: -foobar
On Linux, where /proc exists, this makes sure that we are
executing ourselves again, and not some other copy of the
gocryptfs executable.
This usually does not matter, but mount(1) unsets $PATH
and sets argv[0] to just "gocryptfs".
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.
When mounted via /etc/fstab like this,
/a /b fuse.gocryptfs default 0 0
we always get extra options passed. As reported by @mahkoh
at https://github.com/rfjakob/gocryptfs/pull/233 :
mount passes `-o noexec` if `-o user` is set and `-o exec` is not set.
If both `-o user` and `-o exec` are set, it passes `-o exec`.
Make these options work, and in addtion, also make -suid and -rw
work the same way.
Reported-by: @mahkoh
mv is unhappy when we return EPERM when it tries to set
system.posix_acl_access:
mv: preserving permissions for ‘b/x’: Operation not permitted
Now we return EOPNOTSUPP like tmpfs does and mv seems happy.
Values a binary-safe, there is no need to base64-encode them.
Old, base64-encoded values are supported transparently
on reading. Writing xattr values now always writes them binary.
The tests write to the example_filesystems folder, which
1) May leave your source tree in a modified state
2) Triggers test failures when the fsck tests run concurrently,
which happens on Travis CI every now and then.
Fix both problem by copying the example_filesystems folder
to a private location in /tmp.
We previously returned EPERM to prevent the kernel from
blacklisting our xattr support once we get an unsupported
flag, but this causes lots of trouble on MacOS:
Cannot save files from GUI apps, see
https://github.com/rfjakob/gocryptfs/issues/229
Returning ENOSYS triggers the dotfiles fallback on MacOS
and fixes the issue.
And fix two in test_helpers.Mount().
Leftover fds can cause an unmount failure like this later:
fusermount: failed to unmount /tmp/gocryptfs-test-parent/873632270/default-plain: Device or resource busy
so try to catch them early.
