| Age | Commit message (Collapse) | Author |
|---|
|
Directly use int file descriptors for the dirfd
and get rid of one level of indirection.
|
|
TrezorPayload stores 32 random bytes used for unlocking
the master key using a Trezor security module. The randomness makes sure
that a unique unlock value is used for each gocryptfs filesystem.
|
|
configfile.LoadConfFile() -> configfile.Load()
configfile.CreateConfFile() -> configfile.Create()
|
|
readpassword.Trezor() is not implemented yet and returns
a hardcoded dummy key.
|
|
To avoid confusion with fsck, rename to isDir*()
and move the functions into init_dir.go.
|
|
The replaces the "does not return" comments with
an explicit os.Exit, which is unambigous.
|
|
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.
|
|
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
|
|
Fixes the same problem as described in 72b975867a3b9bdf53fc2da62e2ba4a328d7e4ab,
except for directories instead of device nodes.
|
|
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.
|
|
New codes:
* OpenConf = 23
* WriteConf = 24
|
|
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 .
|
|
As we have dropped Go 1.4 compatibility already, and will add
a new feature flag for gocryptfs v1.3 anyway, this is a good
time to enable Raw64 as well.
|
|
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.
|
|
Through base64.RawURLEncoding.
New command-line parameter "-raw64".
|
|
Before:
You can now mount it using: gocryptfs a x MOUNTPOINT
After:
You can now mount it using: gocryptfs "a x" MOUNTPOINT
This is still not bulletproof but should handle the common
case of having a space in the directory name. After all,
it's only a suggestion.
|
|
|
|
$ gocryptfs -init -extpass "echo test" a
Using password provided via -extpass. <<< DUPLICATE
Reading password from extpass program
The gocryptfs filesystem has been created successfully.
You can now mount it using: gocryptfs a MOUNTPOINT
|
|
GCM-SIV is not yet finalized, and the reference implemenation is
painfully slow at about 2 MB/s. Switch to AES-SIV.
|
|
|
|
Also add ReverseDummyNonce nonce generation.
|
|
|
|
|
|
|
