Changed invalid file decoding and decryption. Function
DecryptName now shortens the filename until the filename is
decodable and decryptable. Will work with valid **and**
invalid Base64URL delimiter (valid delimiter [0-9a-zA-z_\\-].
If the filename is not decryptable at all, it returns the
original cipher name with flag suffix Changed cli tests to
generate decryptable and undecryptable file names with correct
encrypted content. Replacing #474, extends #393
On CIFS mounts, unix.Getdents can return sudden ENOENT
in the middle of data. This will not be reported as an error
by user space tools, so return EIO instead.
Also log it as a warning.
https://github.com/rfjakob/gocryptfs/issues/483
When filename encryption is on, we do know when we
overwrite a directory, and can clear only in this case.
sshfs-benchmark.bash: sshfs gocryptfs-on-sshfs
git init 1.74 7.80
rsync 6.19 11.63
Mkdir can not cause existing entries in the cache to go
stale. So don't clear it. Benchmark results:
sshfs-benchmark.bash: sshfs gocryptfs-on-sshfs
git init 1.65 8.74
rsync 6.09 17.54
Looking at the dircache debug output, we see
that a "git status" workload has a very bad
cache hit rate because the entries expire or
get evicted before they can be reused.
Increase both cache size and lifetime for
a 4x speedup:
Before: 75s
After: 17s
https://github.com/rfjakob/gocryptfs/issues/410
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.
Adding flags allows to use inomap in reverse mode,
replacing the clunky inoBaseDirIV/inoBaseNameFile
logic that causes problems with high underlying
inode numbers ( https://github.com/rfjakob/gocryptfs/issues/457 )
Microbenchmarks (values below) show that the "SingleDev"
case is now much slower due to an extra map lookup,
but this has no visible effects in ./test.bash results,
so there was no time spent optimizing the case further.
$ go test -bench=.
goos: linux
goarch: amd64
pkg: github.com/rfjakob/gocryptfs/internal/inomap
BenchmarkTranslateSingleDev-4 18757510 61.5 ns/op
BenchmarkTranslateManyDevs-4 18061515 64.5 ns/op
PASS
ok github.com/rfjakob/gocryptfs/internal/inomap 2.467s
The comment still mentioned CBC, which has been removed
a long time ago.
The test definition can be rewritten using slice literals,
saving sume stuttering.
We used to prefer openssl in this situation, which
used to make sense, but now Go gained an optimized
assembly implementation for aes-gcm on arm64 with
aes instructions:
root@q1:~/go/src/github.com/rfjakob/gocryptfs# ./gocryptfs -speed
gocryptfs v1.7.1-46-g73436d9; go-fuse v1.0.1-0.20190319092520-161a16484456; 2020-04-13 go1.14.2 linux/arm64
AES-GCM-256-OpenSSL 212.30 MB/s (selected in auto mode)
AES-GCM-256-Go 452.30 MB/s
AES-SIV-512-Go 100.25 MB/s
XChaCha20-Poly1305-Go 137.35 MB/s
https://github.com/rfjakob/gocryptfs/issues/452
We used to restrict setting xattrs to the "user."
namespace. I don't see a real reason for this
anymore, and it causes trouble for users who are using
acls.
Tests will be added in the next commit.
https://github.com/rfjakob/gocryptfs/issues/453
Now that I have discovered golang.org/x/sys/cpu and that Go
versions below 1.6 are uncommon, there was not much useful
code left in prefer_openssl.
Merge the remains into stupidgcm.
Error from Travis CI was:
+GOOS=darwin
+GOARCH=amd64
+go build -tags without_openssl
# github.com/rfjakob/gocryptfs/internal/fusefrontend
internal/fusefrontend/fs.go:88:45: cannot use st.Dev (type int32) as type uint64 in argument to openfiletable.NewInumMap
Add uint64 to fix it.
The comment is outdated, at this point, we should
really not get any errors from ReadDirIVAt.
The change is best seen when running the fsck tests. Before:
fsck: error opening dir "missing_diriv": 2=no such file or directory
After:
OpenDir "K2m0E6qzIfoLkVZJanoUiQ": could not read gocryptfs.diriv: no such file or directory
fsck: error opening dir "missing_diriv": 5=input/output error
See https://github.com/rfjakob/gocryptfs/issues/403 , where
the extra info would have been helpful.
This was meant as a way to inform the user that
something is very wrong, however, users are hitting
the condition on MacOS due to ".DS_Store" files, and
also on NFS due to ".nfsXXX" files.
Drop the whole thing as it seems to cause more pain
than gain.
Fixes https://github.com/rfjakob/gocryptfs/issues/431
