Age | Commit message (Collapse) | Author |
|
|
|
|
|
xattr names have fewer restrictions than file names,
relax the validation.
Fixes https://github.com/rfjakob/gocryptfs/issues/627
|
|
Failure is:
# github.com/rfjakob/gocryptfs/v2/internal/nametransform
internal/nametransform/names.go:47:33: undefined: math.MaxInt
math.MaxInt was only introduced in Go 1.17. Use MaxInt32 instead,
which is good enough, even on amd64. It only has to be larger than
any name we might encounter.
|
|
Determines when to start hashing long names instead
of hardcoded 255. Will be used to alleviate "name too long"
issues some users see on cloud storage.
https://github.com/rfjakob/gocryptfs/issues/499
|
|
Commit
69d88505fd7f4cb0d9e4f1918de296342fe05858 go mod: declare module version v2
translated all instances of "github.com/rfjakob/gocryptfs/" to
"github.com/rfjakob/gocryptfs/v2/".
Unfortunately, this included hyperlinks.
Unbreak the hyperlinks like this:
find . -name \*.go | xargs sed -i s%https://github.com/rfjakob/gocryptfs/v2/%https://github.com/rfjakob/gocryptfs/v2/%
|
|
Our git version is v2+ for some time now, but go.mod
still declared v1. Hopefully making both match makes
https://pkg.go.dev/github.com/rfjakob/gocryptfs/v2 work.
All the import paths have been fixed like this:
find . -name \*.go | xargs sed -i s%github.com/rfjakob/gocryptfs/%github.com/rfjakob/gocryptfs/v2/%
|
|
-deterministc-names uses all-zero dirivs but does not write
them to disk anymore.
|
|
|
|
|
|
|
|
Useless layer of indirection.
|
|
This means we can unexport the field.
|
|
This proposal is the counterpart of the modifications from the `-badname`
parameter. It modifies the plain -> cipher mapping for filenames when using
`-badname` parameter. The new function `EncryptAndHashBadName` tries to find a
cipher filename for the given plain name with the following steps:
1. If `badname` is disabled or direct mapping is successful: Map directly
(default and current behaviour)
2. If a file with badname flag has a valid cipher file, this is returned
(=File just ends with the badname flag)
3. If a file with a badname flag exists where only the badname flag was added,
this is returned (=File cipher name could not be decrypted by function
`DecryptName` and just the badname flag was added)
4. Search for all files which cipher file name extists when cropping more and
more characters from the end. If only 1 file is found, return this
5. Return an error otherwise
This allows file access in the file browsers but most important it allows that
you rename files with undecryptable cipher names in the plain directories.
Renaming those files will then generate a proper cipher filename One
backdraft: When mounting the cipher dir with -badname parameter, you can never
create (or rename to) files whose file name ends with the badname file flag
(at the moment this is " GOCRYPTFS_BAD_NAME"). This will cause an error.
I modified the CLI test function to cover additional test cases. Test [Case
7](https://github.com/DerDonut/gocryptfs/blob/badnamecontent/tests/cli/cli_test.go#L712)
cannot be performed since the cli tests are executed in panic mode. The
testing is stopped on error. Since the function`DecryptName` produces internal
errors when hitting non-decryptable file names, this test was omitted.
This implementation is a proposal where I tried to change the minimum amount
of existing code. Another possibility would be instead of creating the new
function `EncryptAndHashBadName` to modify the signature of the existing
function `EncryptAndHashName(name string, iv []byte)` to
`EncryptAndHashName(name string, iv []byte, dirfd int)` and integrate the
functionality into this function directly. You may allow calling with dirfd=-1
or other invalid values an then performing the current functionality.
|
|
xfstests generic/523 discovered that we allowed to set
xattrs with "/" in the name, but did not allow to read
them later.
With this change we do not allow to set them in the first
place.
|
|
world-readable
Make `gocryptfs.diriv` and `gocryptfs.xxx.name` files world-readable to make encrypted backups easier
when mounting via fstab.
Having the files follow chmod/chown of their parent does not seem
to be worth the hassle. The content of the diriv files is not
secret, and both diriv and name files are protected by the
perms of the parent dir.
Fixes https://github.com/rfjakob/gocryptfs/issues/539
|
|
Prep for https://github.com/rfjakob/gocryptfs/issues/539
|
|
Retry operations that have been shown to throw EINTR
errors on CIFS.
Todo: Solution for this pain in the back:
warning: unix.Getdents returned errno 2 in the middle of data
rm: cannot remove 'linux-3.0.old3/Documentation/ABI/removed': Input/output error
Progress towards fixing https://github.com/rfjakob/gocryptfs/issues/483 .
|
|
|
|
At least 16 bytes due to AES --> at least 22 characters in base64
|
|
Changed invalid file decoding and decryption. Function
DecryptName now shortens the filename until the filename is
decodable and decryptable. Will work with valid **and**
invalid Base64URL delimiter (valid delimiter [0-9a-zA-z_\\-].
If the filename is not decryptable at all, it returns the
original cipher name with flag suffix Changed cli tests to
generate decryptable and undecryptable file names with correct
encrypted content. Replacing #474, extends #393
|
|
https://github.com/client9/misspell
|
|
The comment still mentioned CBC, which has been removed
a long time ago.
The test definition can be rewritten using slice literals,
saving sume stuttering.
|
|
Resolves https://github.com/rfjakob/gocryptfs/issues/393
|
|
Makes it easier to share an encrypted folder via a network drive.
https://github.com/rfjakob/gocryptfs/issues/387
|
|
This adds support for gitignore-like wildcards and exclude patters in
reverse mode. It (somewhat) fixes #273: no regexp support, but the
syntax should be powerful enough to satisfy most needs.
Also, since adding a lot of --exclude options can be tedious, it adds
the --exclude-from option to read patterns from a file (or files).
|
|
Looks like we allowed creating longer names by accident.
Fix that, and add a test that verifies it.
|
|
Similar to gocryptfs.iv files they are never modified.
|
|
Otherwise this can happen, as triggered by xfstests generic/011:
go-fuse: can't convert error type: openat failed: too many open files
The app then gets a misleading "Function not implemented" error.
|
|
Found with the 'codespell' utility.
|
|
|
|
|
|
Un-spaghettify the function and let the callers open
the directory.
|
|
Finally allows us to delete EncryptPathDirIV.
|
|
Pread() needs retry logic, so instead of implementing it ourselves,
use os.File.
Reported by @slackner at
https://github.com/rfjakob/gocryptfs/commit/c09bf1f2284706232642431c75fa1f3d8500a9d0#r31813394
|
|
And also rename DeleteLongName() -> DeleteLongNameAt(). The
naming follow the names open the openat() etc syscalls.
|
|
Interestingly, little or no performance impact:
$ ./benchmark.bash
Testing gocryptfs at /tmp/benchmark.bash.39W: gocryptfs v1.6-42-g30c2349-dirty; go-fuse v20170619-66-g6df8ddc; 2018-11-04 go1.11
Downloading linux-3.0.tar.gz
/tmp/linux-3.0.tar.gz 100%[=========================================================================>] 92.20M 2.93MB/s in 31s
2018-11-04 21:44:44 URL:https://cdn.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.gz [96675825/96675825] -> "/tmp/linux-3.0.tar.gz" [1]
WRITE: 262144000 bytes (262 MB, 250 MiB) copied, 1.1808 s, 222 MB/s
READ: 262144000 bytes (262 MB, 250 MiB) copied, 0.866438 s, 303 MB/s
UNTAR: 24.745
MD5: 12.050
LS: 3.525
RM: 9.544
Note: kernel has been updated:
$ uname -a
Linux brikett 4.18.16-200.fc28.x86_64 #1 SMP Sat Oct 20 23:53:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
|
|
|
|
openBackingDir() used encryptPath(), which is not symlink-safe
itself. Drop encryptPath() and implement our own directory walk.
Adds three seconds to untar and two seconds to rm:
$ ./benchmark.bash
Testing gocryptfs at /tmp/benchmark.bash.MzG: gocryptfs v1.6-36-g8fb3c2f-dirty; go-fuse v20170619-66-g6df8ddc; 2018-10-14 go1.11
WRITE: 262144000 bytes (262 MB, 250 MiB) copied, 1.25078 s, 210 MB/s
READ: 262144000 bytes (262 MB, 250 MiB) copied, 1.0318 s, 254 MB/s
UNTAR: 20.941
MD5: 11.568
LS: 1.638
RM: 5.337
|
|
DecryptPath is now symlink-safe through the use of *at()
functions.
|
|
So the reader does not have to read through the whole ticket.
The commit message has a nice summary of the problem.
|
|
|
|
Mostly detected with the 'codespell' utility, but also includes some
manual grammar fixes.
|
|
Directly use int file descriptors for the dirfd
and get rid of one level of indirection.
|
|
xfstests generic/083 fills the filesystem almost completely while
running fsstress in parallel. In fsck, these would show up:
readFileID 2580: incomplete file, got 18 instead of 19 bytes
This could happen when writing the file header works, but writing
the actual data fails.
Now we kill the header again by truncating the file to zero.
|
|
If the underlying filesystem is full, writing to gocryptfs.diriv may
fail, and later fsck show this:
OpenDir "xyz": could not read gocryptfs.diriv: wanted 16 bytes, got 0
Uncovered by xfstests generic/083.
Also fixes a fd leak in the error path.
|
|
Make sure we get only 1 warning output per
problem.
Also, add new corruption types to broken_fs_v1.4.
|
|
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
|
|
As requested in https://github.com/rfjakob/gocryptfs/pull/179
|
|
...and fix the instances where the AT_SYMLINK_NOFOLLOW /
O_NOFOLLOW / O_EXCL flag was missing.
|