Age | Commit message (Collapse) | Author |
|
To show that https://github.com/rfjakob/gocryptfs/issues/163 has been fixed.
|
|
|
|
|
|
Allows to use /dev/random for generating the master key instead of the
default Go implementation. When the kernel random generator has been
properly initialized both are considered equally secure, however:
* Versions of Go prior to 1.9 just fall back to /dev/urandom if the
getrandom() syscall would be blocking (Go Bug #19274)
* Kernel versions prior to 3.17 do not support getrandom(), and there
is no check if the random generator has been properly initialized
before reading from /dev/urandom
This is especially useful for embedded hardware with low-entroy. Please
note that generation of the master key might block indefinitely if the
kernel cannot harvest enough entropy.
|
|
Getting just the help text in response to
gocryptfs -info -config external.config
is confusing: https://github.com/rfjakob/gocryptfs/issues/157
|
|
At the moment, it does two things:
1. Disable stat() caching so changes to the backing storage show up
immediately.
2. Disable hard link tracking, as the inode numbers on the backing
storage are not stable when files are deleted and re-created behind
our back. This would otherwise produce strange "file does not exist"
and other errors.
Mitigates https://github.com/rfjakob/gocryptfs/issues/156
|
|
...this fails in a thousand ways:
[...]
vendor/golang.org/x/crypto/sha3/keccakf_amd64.s:324: [amd64] keccakF1600: unknown variable state; offset 0 is a+0(FP)
vendor/golang.org/x/crypto/ssh/certs.go:172: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/certs.go:166
vendor/golang.org/x/crypto/ssh/certs.go:187: declaration of "rest" shadows declaration at vendor/golang.org/x/crypto/ssh/certs.go:161
vendor/golang.org/x/crypto/ssh/certs.go:187: declaration of "ok" shadows declaration at vendor/golang.org/x/crypto/ssh/certs.go:161
vendor/golang.org/x/crypto/ssh/client_auth.go:226: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/client_auth.go:193
vendor/golang.org/x/crypto/ssh/client_auth.go:394: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/client_auth.go:380
vendor/golang.org/x/crypto/ssh/client_auth.go:405: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/client_auth.go:380
vendor/golang.org/x/crypto/ssh/handshake.go:566: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/handshake.go:547
vendor/golang.org/x/crypto/ssh/handshake.go:592: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/handshake.go:547
vendor/golang.org/x/crypto/ssh/handshake.go:630: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/handshake.go:620
[...]
|
|
Plus signs are apparently not supported on github,
and replaced by a dot.
|
|
...and delete if after packaging is done.
|
|
|
|
|
|
...to latest point releases acc. to https://golang.org/dl/
|
|
|
|
Prepares for the release of all-in-one source tarballs
that include all non-stdlib dependencies.
|
|
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
|
|
This could lead to test failures like this:
--- FAIL: TestGetdents (0.02s)
getdents_test.go:57: len(getdentsEntries)=362, len(readdirEntries)=360
FAIL
|
|
"go vet" on Go 1.8 and older does not support flags:
$ go version
go version go1.8.3 linux/amd64
$ ./test.bash
gocryptfs v1.4.1-27-g8c1b363 without_openssl; go-fuse v20170619-21-gcf21bc2; 2017-10-22 go1.8.3
gocryptfs v1.4.1-27-g8c1b363; go-fuse v20170619-21-gcf21bc2; 2017-10-22 go1.8.3
flag provided but not defined: -all
usage: vet [-n] [-x] [build flags] [packages]
Vet runs the Go vet command on the packages named by the import paths.
For more about vet, see 'go doc cmd/vet'.
For more about specifying packages, see 'go help packages'.
To run the vet tool with specific options, run 'go tool vet'.
The -n flag prints commands that would be executed.
The -x flag prints commands as they are executed.
For more about build flags, see 'go help build'.
See also: go fmt, go fix.
This reverts commit a1170be979cb75da11e84f45f67d3f5468d97669.
|
|
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().
|
|
"go vet" automatically skips the vendor directory.
"go tool vet" does not, and it will complain about a lot
of things in there.
|
|
We use fixed-size byte slice pools (sync.Pool) and cannot
handle larger requests. So ask the kernel to not send
bigger ones.
Fixes https://github.com/rfjakob/gocryptfs/issues/145
|
|
We cannot return less data than requested to the kernel!
From https://libfuse.github.io/doxygen/structfuse__operations.html:
Read should return exactly the number of bytes
requested except on EOF or error, otherwise the
rest of the data will be substituted with
zeroes.
Reverts commit 3009ec9852316c3c696f77f476390ab5a6d8d6d7 minus
the formatting improvements we want to keep.
Fixes https://github.com/rfjakob/gocryptfs/issues/147
Reopens https://github.com/rfjakob/gocryptfs/issues/145
|
|
...if the filesystem was created with that option (or reverse
mode).
Mitigates https://github.com/rfjakob/gocryptfs/issues/148
|
|
...to account for unaligned reads.
I have not seen this happen in the wild because the kernel
always seems to issue 4k-aligned requests. But the cost
of the additional block in the pool is low and prevents
a buffer overrun panic when an unaligned read does happen.
|
|
If $PATH contains the mountpoint, searching through it
will lock us up. Use an absolute path to avoid looking
at $PATH.
Fixes https://github.com/rfjakob/gocryptfs/issues/146
|
|
Our byte cache pools are sized acc. to MAX_KERNEL_WRITE, but the
running kernel may have a higher limit set. Clamp to what we can
handle.
Fixes a panic on a Synology NAS reported at
https://github.com/rfjakob/gocryptfs/issues/145
|
|
The extended TestLongnameStat() exposes a pathological case
when run on ext4, as ext4 reuses inode numbers immediately.
This change modifies the test to not delete the files immediately,
so the inode numbers cannot be reused immediately.
Fix for the underlying issue is a TODO.
|
|
A file with a name of exactly 176 bytes length caused this error:
ls: cannot access ./tmp/dsg/sXSGJLTuZuW1FarwIkJs0w/b6mGjdxIRpaeanTo0rbh0A/QjMRrQZC_4WLhmHI1UOBcA/gocryptfs.longname.QV-UipdDXeUVdl05WruoEzBNPrQCfpu6OzJL0_QnDKY: No such file or directory
ls: cannot access ./tmp/dsg/sXSGJLTuZuW1FarwIkJs0w/b6mGjdxIRpaeanTo0rbh0A/QjMRrQZC_4WLhmHI1UOBcA/gocryptfs.longname.QV-UipdDXeUVdl05WruoEzBNPrQCfpu6OzJL0_QnDKY.name: No such file or directory
-????????? ? ? ? ? ? gocryptfs.longname.QV-UipdDXeUVdl05WruoEzBNPrQCfpu6OzJL0_QnDKY
-????????? ? ? ? ? ? gocryptfs.longname.QV-UipdDXeUVdl05WruoEzBNPrQCfpu6OzJL0_QnDKY.name
Root cause was a wrong shortNameMax constant that failed to
account for the obligatory padding byte.
Fix the constant and also expand the TestLongnameStat test case
to test ALL file name lengths from 1-255 bytes.
Fixes https://github.com/rfjakob/gocryptfs/issues/143 .
|
|
|
|
The encrypt and decrypt path both had a copy that were equivalent
but ordered differently, which was confusing.
Consolidate it in a new dedicated function.
|
|
Using firstBlockNo as the counter is confusing, create a
copy named "blockNo" and use that.
|
|
|
|
* Reduce the build time precision from seconds to days
* Allow to specify an arbitrary build date through an
env variable
|
|
Allows users to get a reproduceable build. Still needs to
be integrated into build.bash.
Suggested at https://github.com/rfjakob/gocryptfs/issues/142
|
|
MacOS sprinkles .DS_Store files everywhere. This is hard to avoid for
users, so handle it transparently in Rmdir().
Mitigates https://github.com/rfjakob/gocryptfs/issues/140
|
|
Handle the errors first so that the normal code path is not indented.
This should not cause any behavoir changes.
|
|
MacOS creates lots of these files, and if the directory is otherwise
empty, we would throw an IO error to the unsuspecting user.
With this patch, we log a warning, but otherwise pretend we did not
see it.
Mitigates https://github.com/rfjakob/gocryptfs/issues/140
|
|
...and if Getdents is not available at all.
Due to this warning I now know that SSHFS always returns DT_UNKNOWN:
gocryptfs[8129]: Getdents: convertDType: received DT_UNKNOWN, falling back to Lstat
This behavoir is confirmed at http://ahefner.livejournal.com/16875.html:
"With sshfs, I finally found that obscure case. The dtype is always set to DT_UNKNOWN [...]"
|
|
$ uname -a
Linux brikett 4.12.5-300.fc26.x86_64 #1 SMP Mon Aug 7 15:27:25 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
|
|
Previously, OpenDir() did not use the cache at all, missing
an opportunity to speed up repeated directory reads.
|
|
The comments were unclear on whether relative or absolute paths
have to be passed.
|
|
Save an execution trace of writing 100MB of data
to a new gocryptfs mount on /tmp
|
|
|
|
https://goreportcard.com/report/github.com/rfjakob/gocryptfs#misspell
|
|
The exit codes have been documented in CLI_ABI.md for a while,
but they should also be listed in the man page.
Also fix the rendering of "[-o COMMA-SEPARATED-OPTIONS]", where
the square brackets where interpreted as something. Escape all
square brackets to be safe.
|
|
|
|
The local user id of the packager is not interesting for users who
download the tarball.
Also it will cause the gocryptfs binary to have an unintended owner
when the tarball is extraced as root.
Fix the issue by using "tar --owner=root --group=root" which
overwrites user and group id with zero.
|
|
The benchmark that supported the decision for 512-byte
prefetching previously lived outside the repo.
Let's add it where it belongs so it cannot get lost.
|
|
For some reason, writing became a lot faster in Linux 4.11
(scheduler improvements?).
|
|
|
|
|