From https://github.com/rfjakob/gocryptfs/issues/150:
mkdir a
mkdir a/b
gocryptsfs -init -reverse a/
gocryptfs -reverse a/ a/b
Now directory a/b/ contains encrypted view of 'a' but it
is possible to descend into encrypted version of b (e.g.
a/b/43873uhj538765387/) which contains double encrypted
'a' and so on.
Reported-by: https://github.com/tigmac
Disable hard link tracking to avoid strange breakage on duplicate
inode numbers ( https://github.com/rfjakob/gocryptfs/issues/149 ).
Reverse mode is read-only, so we don't need a working link().
Remove the "Masterkey" field from fusefrontend.Args because it
should not be stored longer than neccessary. Instead pass the
masterkey as a separate argument to the filesystem initializers.
Then overwrite it with zeros immediately so we don't have
to wait for garbage collection.
Note that the crypto implementation still stores at least a
masterkey-derived value, so this change makes it harder, but not
impossible, to extract the encryption keys from memory.
Suggested at https://github.com/rfjakob/gocryptfs/issues/137
scrypt (used during masterkey decryption) allocates a lot of memory.
Go only returns memory to the OS after 5 minutes, which looks like
a waste. Call FreeOSMemory() to return it immediately.
Looking a fresh mount:
before: VmRSS: 73556 kB
after: VmRSS: 8568 kB
Currently neither gocryptfs nor go-fuse automatically call load_osxfuse
if the /dev/osxfuse* device(s) do not exist. At least tell the user
what to do.
See https://github.com/rfjakob/gocryptfs/issues/124 for user pain.
go-fuse caps MaxWrite at MAX_KERNEL_WRITE anyway, and we
actually depend on this behavoir now as the byte pools
are sized according to MAX_KERNEL_WRITE.
So let's use MAX_KERNEL_WRITE explicitely.
Previously, it was at the go-fuse default of 64KiB. Getting
bigger writes should increase throughput somewhat.
Testing on tmpfs shows an improvement from 112MiB/s to 120MiB/s.
Instead of redirecting stdout and stderr to /tmp/gocryptfs_paniclog,
where it is hard to find, redirect them to a newly spawned logger(1)
instance that forwards the messages to syslog.
See https://github.com/rfjakob/gocryptfs/issues/109 for an example
where the paniclog was lost due to a reboot.
Also, instead of closing stdin, redirect it to /dev/null, like most
daemons seem to do.
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 .
Linux by default has a soft limit of 1024 and a hard limit of
4096 on open files. We can increase it so 4096 without root
permissions.
This should help reduce the risk of gocryptfs running out of
file descriptors, as reported at
https://github.com/rfjakob/gocryptfs/issues/82 .
Force decode of encrypted files even if the integrity check fails, instead of
failing with an IO error. Warning messages are still printed to syslog if corrupted
files are encountered.
It can be useful to recover files from disks with bad sectors or other corrupted
media.
Closes https://github.com/rfjakob/gocryptfs/pull/102 .
Due to kernel readahead, we usually get multiple read requests
at the same time. These get submitted to the backing storage in
random order, which is a problem if seeking is very expensive.
Details: https://github.com/rfjakob/gocryptfs/issues/92
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.
Preallocation is very slow on hdds that run btrfs. Give the
user the option to disable it. This greatly speeds up small file
operations but reduces the robustness against out-of-space errors.
Also add the option to the man page.
More info: https://github.com/rfjakob/gocryptfs/issues/63
Redirect stdout and stderr to /tmp/gocryptfs_paniclog.NNNNNN
instead of closing them so users have a chance to get the
backtrace on a panic.
This only applies if "-nosyslog" is NOT set. Panics will
go to terminal as usual if it is.
This makes sure all callers of parseMasterKey warn the user.
At the moment there is only one, but another one will be added
soon for forcing a password change when only the master key is
known.
For example, we cannot mount "/home/user/.cipher" at "/home/user"
because the mount will hide ".cipher" also for us.
Doing it anyway used to cause a nasty hang.
