| Age | Commit message (Collapse) | Author |
|---|
|
We relied on the finalizer to close a few fds.
For some reason, this did not cause problems on Linux,
but on MacOS, it causes unmount failures:
umount(/private/tmp/gocryptfs-test-parent/194654785/default-plain): Resource busy -- try 'diskutil unmount'
|
|
Accept extra args, like test.bash does.
|
|
Gets rid of the touch error message upon running the tests.
|
|
Limit is much lower than on linux
|
|
|
|
MacOS does not have it installed by default.
|
|
These cannot work on MacOS.
|
|
The limit is much lower than on Linux.
https://github.com/rfjakob/gocryptfs/issues/213
|
|
On MacOS, symlinks don't have their own permissions,
so don't check for them.
|
|
To Go test logic waits for stderr and stdout to close, so
when we share it with a subprocess, it will wait for it to
exit as well.
We don't want the tests to hang when the unmount fails.
Seen on MacOS as reported at
https://github.com/rfjakob/gocryptfs/issues/213
|
|
A few places have called tlog.Warn.Print, which directly
calls into log.Logger due to embedding, losing all features
of tlog.
Stop embedding log.Logger to make sure the internal functions
cannot be called accidentially and fix (several!) instances
that did.
|
|
"1.10" does not work as expected because it
is parsed as a floating point number:
https://github.com/travis-ci/travis-ci/issues/9247
Added benefit is that we always get the latest point
release.
|
|
|
|
This Warn() is causing panics in the test suite
on MacOS: https://github.com/rfjakob/gocryptfs/issues/213
|
|
Go 1.10 has introduced test result caching and
enabled it by default.
This does not work properly for our integration
tests because they test the compiled binary and
do not have a source level dependency on the
gocryptfs code.
Disable caching.
|
|
|
|
We now print the number in a debug message, so define
the numeric values explicitely instead of using iota.
This way you don't have to understand how iota works
to find out what the number means. Lack of understanding
of how iota works is also the reason why the numbers
start at 3 (to keep the current behavoir).
|
|
Zero the HKDF-derived keys when we don't need them
anymore, and let the variable run of of scope.
https://github.com/rfjakob/gocryptfs/issues/211
|
|
Having a private copy relieves the caller from worrying about
whether he can zero his copy. The copy can be cleared by
calling Wipe().
|
|
Overwrite the masterkey with zeros once we
have encrypted it, and let it run out of scope.
Also get rid of the password duplicate in
readpassword.Twice.
|
|
Overwrite the password we have got from the user
with zeros once we don't need it anymore, and make
sure the variable runs out of scope.
|
|
This will allows us to overwrite the password
with zeros once we are done with it.
https://github.com/rfjakob/gocryptfs/issues/211
|
|
Also drop the unused int return.
|
|
As soon as we don't need them anymore, overwrite
keys with zeros. Make sure they run out of scope
so we don't create a risk of inadvertedly using
all-zero keys for encryption.
https://github.com/rfjakob/gocryptfs/issues/211
|
|
While reading the code, I had to think about what it
does, so add a comment that explains it.
|
|
As soon as we don't need them anymore, overwrite
keys with zeros and make sure they run out of scope
so we don't create a risk of inadvertedly using all-zero
keys for encryption.
https://github.com/rfjakob/gocryptfs/issues/211
|
|
Relieves the caller from worrying about whether they
can overwrite the key.
|
|
Raise the bar for recovering keys from memory.
https://github.com/rfjakob/gocryptfs/issues/211
|
|
Both fusefrontend and fusefrontend_reverse were doing
essentially the same thing, move it into main's
initFuseFrontend.
A side-effect is that we have a reference to cryptocore
in main, which will help with wiping the keys on exit
(https://github.com/rfjakob/gocryptfs/issues/211).
|
|
Not bulletproof due to possible GC copies, but
still raises to bar for extracting the key.
https://github.com/rfjakob/gocryptfs/issues/211
|
|
What the key slice does not get copied around
will make it possible to check if the key has been wiped.
|
|
|
|
|
|
The test is known to fail on gccgo
(https://github.com/rfjakob/gocryptfs/issues/201), but
getdents emulation is not used on linux, so let's skip
the test and ignore the failure.
|
|
|
|
$ go.gcc build
# github.com/rfjakob/gocryptfs/internal/syscallcompat
internal/syscallcompat/unix2syscall_linux.go:32:13: error: incompatible types in assignment (cannot use type int64 as type syscall.Timespec_sec_t)
s.Atim.Sec = u.Atim.Sec
^
|
|
The man page is rendered on github at
https://github.com/rfjakob/gocryptfs/blob/master/Documentation/MANPAGE.md .
Improve formatting a little.
|
|
For some reason the syscall.NAME_MAX constant does not exist
on gccgo, and it does not hurt us to use unix.NAME_MAX instead.
https://github.com/rfjakob/gocryptfs/issues/201
|
|
On mips64le, syscall.Getdents() and struct syscall.Dirent do
not fit together, causing our Getdents implementation to
return garbage ( https://github.com/rfjakob/gocryptfs/issues/200
and https://github.com/golang/go/issues/23624 ).
Switch to unix.Getdents which does not have this problem -
the next Go release with the syscall package fixes is too
far away, and will take time to trickle into distros.
|
|
|
|
|
|
Due to padding between entries, it is 280 even on 32-bit architectures.
See https://github.com/rfjakob/gocryptfs/issues/197 for details.
|
|
We used to print somewhat strange messages:
Getdents: corrupt entry #1: Reclen=276 > 280. Returning EBADR
Reported at https://github.com/rfjakob/gocryptfs/issues/197
|
|
README: add missing word
|
|
We don't actually print that warning anymore.
|
|
syscall.ParseDirent only returns the NAMES, we want
everything.
|
|
Also update the v1.4.3 release date to today.
The release was delayed one day.
|
|
|
|
|
|
|
