| Age | Commit message (Collapse) | Author |
|---|
|
...and fix a few golint issues and print a scary warning message on mount.
Also, force the fs to ro,noexec.
|
|
Force decode of encrypted files even if the integrity check fails, instead of
failing with an IO error. Warning messages are still printed to syslog if corrupted
files are encountered.
It can be useful to recover files from disks with bad sectors or other corrupted
media.
Closes https://github.com/rfjakob/gocryptfs/pull/102 .
|
|
go-fuse has added a new method to the nodefs.File interface that
caused this build error:
internal/fusefrontend/file.go:75: cannot use file literal (type *file) as type nodefs.File in return argument:
*file does not implement nodefs.File (missing Flock method)
Fixes https://github.com/rfjakob/gocryptfs/issues/104 and
prevents the problem from happening again.
|
|
|
|
The volatile inode numbers that we used before cause "find" to complain and error out.
Virtual inode numbers are derived from their parent file inode number by adding 10^19,
which is hopefully large enough no never cause problems in practice.
If the backing directory contains inode numbers higher than that, stat() on these files
will return EOVERFLOW.
Example directory lising after this change:
$ ls -i
926473 gocryptfs.conf
1000000000000926466 gocryptfs.diriv
944878 gocryptfs.longname.hmZojMqC6ns47eyVxLlH2ailKjN9bxfosi3C-FR8mjA
1000000000000944878 gocryptfs.longname.hmZojMqC6ns47eyVxLlH2ailKjN9bxfosi3C-FR8mjA.name
934408 Tdfbf02CKsTaGVYnAsSypA
|
|
This has long been replaced by virtualFile.GetAttr().
|
|
The fmt.Printfs output would end up in the paniclog.
|
|
Note: find currently complains like this:
find: failed to read file names from file system at or below
‘/tmp/linux-3.0.reverse.mnt.vNI’: No such file or directory
I have analyzed this and it is caused by the non-stable inode numbers
that gocryptfs -reverse uses. Will be fixed in a later commit.
|
|
...and improve and comment variable naming in findLongnameParent.
No semantic changes.
|
|
|
|
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.
|
