Age | Commit message (Collapse) | Author |
|
Seems to work ok:
$ echo aaaaaaaaaaaaaaaaaaa > b/foo
$ gocryptfs-xray a/LAh7EiK-kjleJhStVZ1JGg
Header: Version: 2, Id: 8d76d368438112fb00cb807fa8210a74
Block 0: IV: b05bb152f77816678230885d09a4a596, Tag: c1c7d580fe01dd1eb543efd9d8eda8ad, Offset: 18 Len: 52
$ > b/foo
$ echo aaaaaaaaaaaaaaaaaaa > b/foo
$ gocryptfs-xray a/LAh7EiK-kjleJhStVZ1JGg
Header: Version: 2, Id: 8d76d368438112fb00cb807fa8210a74
Block 0: IV: b05bb152f77816678230885d09a4a596, Tag: c1c7d580fe01dd1eb543efd9d8eda8ad, Offset: 18 Len: 52
Deterministic diriv generation is still missing.
Part of https://github.com/rfjakob/gocryptfs/issues/108
|
|
This was implemented in fusefrontend_reverse, but we need it
in fusefrontend as well. Move the algorithm into pathiv.BlockIV().
|
|
We check the md5 sum of the encrypted version of a file to make sure we don't
accidentially change the ciphertext generation.
|
|
...under the new name "FileIVs".
This will also be used by forward mode.
|
|
We will also need it in forward mode.
|
|
...and also exit with the proper exit code when we get an error.
|
|
Fixes https://github.com/rfjakob/gocryptfs/issues/83
|
|
RHEL and CentOS do not have /etc/os-release yet. Read from
/etc/redhat-release instead.
Fixes https://github.com/rfjakob/gocryptfs/issues/113
|
|
These should make it easier to re-implement the key derivation
that was enabled with the "HKDF" feature flag.
|
|
|
|
With hard links, the path to a file is not unique. This means
that the ciphertext data depends on the path that is used to access
the files.
Fix that by storing the derived values when we encounter a hard-linked
file. This means that the first path wins.
|
|
|
|
This should never happen in normal operation and is a sign of
data corruption. Catch it early.
|
|
This should never happen in normal operation and is a sign of
data corruption. Catch it early.
|
|
Log the message ourselves and return EINVAL.
Before:
gocryptfs[26962]: go-fuse: can't convert error type: ParseHeader: invalid version: got 0, want 2
After:
gocryptfs[617]: ParseHeader: invalid version: want 2, got 0. Returning EINVAL.
|
|
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 fixes a few issues I have found reviewing the code:
1) Limit the amount of data ReadLongName() will read. Previously,
you could send gocryptfs into out-of-memory by symlinking
gocryptfs.diriv to /dev/zero.
2) Handle the empty input case in unPad16() by returning an
error. Previously, it would panic with an out-of-bounds array
read. It is unclear to me if this could actually be triggered.
3) Reject empty names after base64-decoding in DecryptName().
An empty name crashes emeCipher.Decrypt().
It is unclear to me if B64.DecodeString() can actually return
a non-error empty result, but let's guard against it anyway.
|
|
Exiting with a fatal error just pushes users to use "-nosyslog",
which is even worse than not having a paniclog.
|
|
When a user calls into a deep directory hierarchy, we often
get a sequence like this from the kernel:
LOOKUP a
LOOKUP a/b
LOOKUP a/b/c
LOOKUP a/b/c/d
The diriv cache was not effective for this pattern, because it
was designed for this:
LOOKUP a/a
LOOKUP a/b
LOOKUP a/c
LOOKUP a/d
By also using the cached entry of the grandparent we can avoid lots
of diriv reads.
This benchmark is against a large encrypted directory hosted on NFS:
Before:
$ time ls -R nfs-backed-mount > /dev/null
real 1m35.976s
user 0m0.248s
sys 0m0.281s
After:
$ time ls -R nfs-backed-mount > /dev/null
real 1m3.670s
user 0m0.217s
sys 0m0.403s
|
|
|
|
|
|
Needs a leading "..".
|
|
All exit codes that are likely to occour are listed.
|
|
New codes:
* OpenConf = 23
* WriteConf = 24
|
|
Empty passwords are not allowed. Let's give the error
it's own exit code.
|
|
Instead, create three new specific exit codes:
* FuseNewServer = 19
* CtlSock = 20
* PanicLogCreate = 21
|
|
We used to return code 8, now we return code 12 as documented in
the man page.
Also adds a test.
|
|
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 .
|
|
Closes https://github.com/rfjakob/gocryptfs/issues/84 .
|
|
nametransform.DecryptName() now always returns syscall.EBADMSG if
the name was invalid.
fusefrontend.OpenDir error messages have been normalized.
|
|
Misspell Finds commonly misspelled English words
gocryptfs/internal/configfile/scrypt.go
Line 41: warning: "paramter" is a misspelling of "parameter" (misspell)
gocryptfs/internal/ctlsock/ctlsock_serve.go
Line 1: warning: "implementes" is a misspelling of "implements" (misspell)
gocryptfs/tests/test_helpers/helpers.go
Line 27: warning: "compatability" is a misspelling of "compatibility" (misspell)
|
|
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.
|
|
...if we were compiled with "-race".
|
|
This usually indicates that the open file limit for gocryptfs is
too low. We should report this to the user.
|
|
We don't want to set the limit to unlimited if "Max" is unlimited.
Hard-cap to 4096.
|
|
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 .
|
|
May be helpful for https://github.com/vgough/encfs/issues/214 .
|
|
...and IDLock to HeaderLock. This matches what the locks actually
protect.
|
|
Now that we embed nodefs.NewDefaultFile(), we can drop our own
no-ops.
|
|
This can happen during normal operation, and is harmless since
14038a1644f17f50b113a05d09a2a0a3b3e973b2
"fusefrontend: readFileID: reject files that consist only of a header"
causes dormant header-only files to be rewritten on the next write.
|
|
This test reproduces the problem xfstests generic/124 uncovered.
The warning itself is harmless, but we should either (1) add locking
so that this cannot happen anymore or (2) drop the warning.
Currently fails:
$ go test -v
=== RUN Test1980Tar
--- PASS: Test1980Tar (0.00s)
=== RUN TestCtlSock
--- PASS: TestCtlSock (0.10s)
=== RUN TestOpenTruncateRead
--- PASS: TestOpenTruncateRead (0.00s)
=== RUN TestWORead
--- PASS: TestWORead (0.00s)
=== RUN TestXfs124
cipherSize 18 == header size: interrupted write?
-wpanic turns this warning into a panic: cipherSize 18 == header size: interrupted write?
|
|
We do not have to track the writeOnly status because the kernel
will not forward read requests on a write-only FD to us anyway.
I have verified this behavoir manually on a 4.10.8 kernel and also
added a testcase.
|
|
The open file table code needs some room to grow for the upcoming
FD multiplexing implementation.
|
|
Go 1.8.1. has been released recently. Use it for the Go 1.8 branch.
|
|
We want to exit with 1 only if we we have complaints left after
the greps.
|
|
The data structure was originally called write lock table, but
is now simply called the open file table. Rename the file to
reflect that.
|
|
|
|
This is a very old leftover.
|
|
This is the value EncFS uses, so let's follow suit.
Suggested at https://github.com/rfjakob/gocryptfs/issues/77 .
|
|
Includes test cases.
|