| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This PR addresses the Issue #95, about "Confusing file owner for
longname files in reverse mode".
It affects only the reverse mode, and introduces two
modifications:
1) The "gocryptfs.longname.XXXX.name" files are assigned the owner and
group of the underlying plaintext file. Therefore it is consistent
with the file "gocryptfs.longname.XXXX" that has the encrypted
contents of the plaintext file.
2) The two virtual files mentioned above are given -r--r--r--
permissions. This is consistent with the behavior described in
function Access in internal/fusefrontend_reverse/rfs.go where all
virtual files are always readable. Behavior also observed in point
c) in #95 .
Issue #95 URL: https://github.com/rfjakob/gocryptfs/issues/95
Pull request URL: https://github.com/rfjakob/gocryptfs/pull/97
|
|
https://github.com/rfjakob/gocryptfs/issues/98
|
|
This makes it render properly on the github webinterface.
|
|
|
|
This makes sure we cannot get weak parameters passed through a
rougue gocryptfs.conf.
|
|
* Further explain the use of 'scryptn' parameter
* Further explain the use of 'scryptn' parameter in MANPAGE
* Use 28 as reasonable upper limit
|
|
This keeps the README working even if nuetzlich.net is unavailable.
We use a PNG because github disallows embedding local SVGs.
|
|
|
|
|
|
1000 was too low as at least one user had a password
that was longer.
Fixes https://github.com/rfjakob/gocryptfs/issues/93
|
|
|
|
|
|
Github seems to have changed its markdown parser.
It now requires three spaces for sublists.
|
|
...and v1.3-beta1
|
|
These are deliberately corrupt.
|
|
|
|
|
|
Due to kernel readahead, we usually get multiple read requests
at the same time. These get submitted to the backing storage in
random order, which is a problem if seeking is very expensive.
Details: https://github.com/rfjakob/gocryptfs/issues/92
|
|
A header-only file will be considered empty (this is not supposed to happen).
This makes File ID poisoning more difficult.
|
|
...if doWrite() can do it for us. This avoids the situation
that the file only consists of a file header when calling
doWrite.
A later patch will check for this condition and warn about it,
as with this change it should no longer occour in normal operation.
|
|
|
|
If you truncate a ciphertext file to 19 bytes, you could get the
impression that the plaintext is 18446744073709551585 bytes long,
as reported by "ls -l".
Fix it by clamping the value to zero.
|
|
This brings the CLI options back in sync with the default
feature flags.
|
|
The filesystem was created with a gocryptfs version that ignored
the HKDF flag (hence everything was actually encrypted WITHOUT hkdf).
Fix it by recreating it.
|
|
This commit also enables actually passing the HKDF setting to
fusefrontend, this was missing till now.
|
|
Also adds a test to verify that they are set in new config
files.
|
|
TestMain() runs all tests twice, once with plaintextnames=true and once
with false. Several tests mount their own filesystem and ignore the
plaintextnames variable. It makes no sense to run them twice, so
skip execution when plaintextnames is set.
|
|
Prior to this commit, gocryptfs's reverse mode did not report correct
directory entry sizes for symbolic links, where the dentry size needs to
be the same as the length of a string containing the target path.
This commit corrects this issue and adds a test case to verify the
correctness of the implementation.
This issue was discovered during the use of a strict file copying program
on a reverse-mounted gocryptfs file system.
|
|
internal/configfile/config_test.go:67: c declared and not used
|
|
This test fails because Raw64 has been disabled for now.
|
|
This filesystem has both HKDF and Raw64 enabled.
|
|
Raw64 is supported (but was disabled by default) since gocryptfs
v1.2. However, the implementation was buggy because it forgot
about long names and symlinks.
Disable it for now by default and enable it later, together
with HKDF.
|
|
The symlink functions incorrectly hardcoded the padded
base64 variant.
|
|
HashLongName() incorrectly hardcoded the call to base64.URLEncoding.
|
|
...but keep it disabled by default for new filesystems.
We are still missing an example filesystem and CLI arguments
to explicitely enable and disable it.
|
|
This will be re-enabled once it is implemented.
|
|
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.
|
|
There is no security reason for doing this, but it will allow
to consolidate the code once we drop compatibility with gocryptfs v1.2
(and earlier) filesystems.
|
|
|
|
Yields a nice reduction in code size.
|
|
Also drop Go 1.4 from Travis CI and update other Go
versions to latest point release.
|
|
There are two independent backends, one for name encryption,
the other one, AEAD, for file content.
"BackendTypeEnum" only applies to AEAD (file content), so make that
clear in the name.
|
|
Version 1.1 of the EME package (github.com/rfjakob/eme) added
a more convenient interface. Use it.
Note that you have to upgrade your EME package (go get -u)!
|
|
Calling t.Fatal immeadiately aborts the test, which means the
filesystem will not get unmounted, which means test.bash will
hang.
|
|
Sourcing the script breaks the "cd $(dirname $0)" logic in
build-without-openssl.bash.
|
|
|
|
When filename encryption is active, every directory contains
a "gocryptfs.diriv" file. This file should also change the owner.
Fixes https://github.com/rfjakob/gocryptfs/issues/86
|
|
We have it saved in Stderr and Stdout anyway, let's free this fd
number.
|
|
The old ones were rendered by github almost as big as the parent headings.
|
