Age | Commit message (Collapse) | Author |
|
Now that https://github.com/hanwen/go-fuse/issues/399 has
landed we can report an inode number for the root node.
Fixes https://github.com/rfjakob/gocryptfs/issues/580
|
|
|
|
Detect and delete an orphaned socket file that collides with
the ctlsock we want to create.
Fixes https://github.com/rfjakob/gocryptfs/issues/776
|
|
Prep for solving https://github.com/rfjakob/gocryptfs/issues/776
|
|
Fixes https://github.com/rfjakob/gocryptfs/issues/809
|
|
Should make debugging situations like
https://github.com/rfjakob/gocryptfs/issues/852
Empty stdin in mkinitcpio hook
easier.
Examples:
$ echo -n "" | ./gocryptfs -init a
Choose a password for protecting your files.
Reading Password from stdin (connected to "pipe:[749878]")
Got empty Password from stdin
$ ./gocryptfs -init a < /dev/null
Choose a password for protecting your files.
Reading Password from stdin (connected to "/dev/null")
Got empty Password from stdin
$ ./gocryptfs -init a < /dev/zero
Choose a password for protecting your files.
Reading Password from stdin (connected to "/dev/zero")
fatal: maximum password length of 2048 bytes exceeded
$ ./gocryptfs -init a < /dev/full
Choose a password for protecting your files.
Reading Password from stdin (connected to "/dev/full")
fatal: maximum password length of 2048 bytes exceeded
$ jakob@brikett:~/go/src/github.com/rfjakob/gocryptfs$ ./gocryptfs -init a < /dev/urandom
Choose a password for protecting your files.
Reading Password from stdin (connected to "/dev/urandom")
Your master key is:
4e45a317-595d8a2d-46493a30-97de86ef-
540c7364-f0acc297-dd6f2592-7d9a5c97
If the gocryptfs.conf file becomes corrupted or you ever forget your password,
there is only one hope for recovery: The master key. Print it to a piece of
paper and store it in a drawer. This message is only printed once.
The gocryptfs filesystem has been created successfully.
You can now mount it using: gocryptfs a MOUNTPOINT
|
|
Instead of just looking for AES, also look for PCLMULQDQ,
like crypto/tls does.
Fixes: https://github.com/rfjakob/gocryptfs/issues/822
|
|
Let's not leak fds to logger.
Before:
$ lsof -p $(pgrep logger)
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
logger 146410 jakob cwd DIR 253,0 4096 2 /
logger 146410 jakob rtd DIR 253,0 4096 2 /
logger 146410 jakob txt REG 253,0 41560 6293858 /usr/bin/logger
logger 146410 jakob mem REG 253,0 229754784 6292695 /usr/lib/locale/locale-archive
logger 146410 jakob mem REG 253,0 186480 6292031 /usr/lib64/libgcc_s-14-20240508.so.1
logger 146410 jakob mem REG 253,0 787128 6294119 /usr/lib64/libzstd.so.1.5.6
logger 146410 jakob mem REG 253,0 211424 6294587 /usr/lib64/liblzma.so.5.4.6
logger 146410 jakob mem REG 253,0 131128 6302636 /usr/lib64/liblz4.so.1.9.4
logger 146410 jakob mem REG 253,0 49184 6302330 /usr/lib64/libcap.so.2.69
logger 146410 jakob mem REG 253,0 2476880 6295299 /usr/lib64/libc.so.6
logger 146410 jakob mem REG 253,0 987256 6292058 /usr/lib64/libsystemd.so.0.38.0
logger 146410 jakob mem REG 253,0 906256 6295295 /usr/lib64/ld-linux-x86-64.so.2
logger 146410 jakob 0r FIFO 0,14 0t0 607727 pipe
logger 146410 jakob 1w CHR 1,3 0t0 4 /dev/null
logger 146410 jakob 2w CHR 1,3 0t0 4 /dev/null
logger 146410 jakob 3u unix 0x0000000046d9c96b 0t0 607729 type=DGRAM (CONNECTED)
logger 146410 jakob 10u DIR 0,33 80 7758 /tmp/tmp.lbUiEw9P6W/a
After:
$ lsof -p $(pgrep logger)
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
logger 147982 jakob cwd DIR 253,0 4096 2 /
logger 147982 jakob rtd DIR 253,0 4096 2 /
logger 147982 jakob txt REG 253,0 41560 6293858 /usr/bin/logger
logger 147982 jakob mem REG 253,0 229754784 6292695 /usr/lib/locale/locale-archive
logger 147982 jakob mem REG 253,0 186480 6292031 /usr/lib64/libgcc_s-14-20240508.so.1
logger 147982 jakob mem REG 253,0 787128 6294119 /usr/lib64/libzstd.so.1.5.6
logger 147982 jakob mem REG 253,0 211424 6294587 /usr/lib64/liblzma.so.5.4.6
logger 147982 jakob mem REG 253,0 131128 6302636 /usr/lib64/liblz4.so.1.9.4
logger 147982 jakob mem REG 253,0 49184 6302330 /usr/lib64/libcap.so.2.69
logger 147982 jakob mem REG 253,0 2476880 6295299 /usr/lib64/libc.so.6
logger 147982 jakob mem REG 253,0 987256 6292058 /usr/lib64/libsystemd.so.0.38.0
logger 147982 jakob mem REG 253,0 906256 6295295 /usr/lib64/ld-linux-x86-64.so.2
logger 147982 jakob 0r FIFO 0,14 0t0 609636 pipe
logger 147982 jakob 1w CHR 1,3 0t0 4 /dev/null
logger 147982 jakob 2w CHR 1,3 0t0 4 /dev/null
logger 147982 jakob 3u unix 0x00000000bc46d033 0t0 610344 type=DGRAM (CONNECTED)
Fixes https://github.com/rfjakob/gocryptfs/issues/846
|
|
This package is a failed experiment and should not
have been committed.
Fixes: 9958b63931aee613d5f97a8e7137efa3fb118343
|
|
ed0a12b7337c2d88c027329f64e73070da17d5b3 already fixed the kernel side,
now we also want the .name files to NOT appear hardlinked when just
looking at the inode number.
Relates-to: https://github.com/rfjakob/gocryptfs/issues/802
|
|
This will be used in reverse mode. Switch to atomic increment to avoid
a "nextSpillInoUnlocked" helper.
|
|
This avoids the manual "| spillBit" logic.
|
|
We used to present gocryptfs.longname.*.name files for hardlinked
files as hardlinked to the kernel (same Node ID) which is wrong.
Fix this by using a unique generation number for all nodes, which
also fixes possible issues with inode reuse.
Basically what 1bc1db620b061aabf59469a5eb4fb60e3e1701a3 did
for forward mode with -sharedstorage.
Fixes https://github.com/rfjakob/gocryptfs/issues/802
|
|
Add an option to specify user verification options for `fido2-assert -t`
Options will be saved to config file
Provide same functionality to #705 with simpler implementation
Resolve #702
|
|
|
|
|
|
|
|
Looks like I should have been calling testing.Init()
all along. From https://pkg.go.dev/testing#Init :
> Init is only needed when calling functions such as
> Benchmark without using "go test".
Panic only affected without_openssl builds and looks
like this:
$ ./gocryptfs -speed
gocryptfs v2.4.0-2-g8b1c4b0-dirty without_openssl; go-fuse v2.3.0; 2023-09-15 go1.21.1 linux/amd64
cpu: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz; with AES acceleration
AES-GCM-256-OpenSSL panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x5a5d20]
goroutine 7 [running]:
testing.(*common).decorate(0x40d625?, {0xc00001c150, 0x2a}, 0x830601?)
testing/testing.go:772 +0xa0
[...]
Fixes: https://github.com/rfjakob/gocryptfs/issues/789
Relates-to: https://github.com/golang/go/issues/62666
|
|
The test added in the earlier commit passes with this
change.
|
|
Not having Access() means go-fuse emulates it by looking at Getattr().
This works fine most of the time, but breaks down on sshfs, where
sshfs-benchmark.bash shows this:
gocryptfs/tests$ ./sshfs-benchmark.bash nuetzlich.net
working directory: /tmp/sshfs-benchmark.bash.JQC
sshfs mounted: nuetzlich.net:/tmp -> sshfs.mnt
gocryptfs mounted: sshfs.mnt/sshfs-benchmark.bash.Wrz/gocryptfs.crypt -> gocryptfs.mnt
sshfs-benchmark.bash: sshfs gocryptfs-on-sshfs
git init 3.98 6.80
rsync 7.71 10.84
rm -R 4.30rm: descend into write-protected directory 'gocryptfs.mnt/git1'?
The go-fuse emulation gets it wrong here because sshfs reports
permissions but does not enforce them.
Implement it ourselves properly.
|
|
And add a test for it.
Fixes https://github.com/rfjakob/gocryptfs/issues/724
|
|
BenchmarkGoGCMBlockSize/16-4 5499200 219.7 ns/op 72.83 MB/s
BenchmarkGoGCMBlockSize/32-4 4497284 266.2 ns/op 120.22 MB/s
BenchmarkGoGCMBlockSize/64-4 3296336 363.4 ns/op 176.10 MB/s
BenchmarkGoGCMBlockSize/128-4 4204794 285.5 ns/op 448.36 MB/s
BenchmarkGoGCMBlockSize/256-4 2928472 409.7 ns/op 624.83 MB/s
BenchmarkGoGCMBlockSize/512-4 1825164 658.0 ns/op 778.09 MB/s
BenchmarkGoGCMBlockSize/1024-4 1000000 1151 ns/op 889.98 MB/s
BenchmarkGoGCMBlockSize/2048-4 560275 2135 ns/op 959.47 MB/s
BenchmarkGoGCMBlockSize/4096-4 291906 4099 ns/op 999.28 MB/s
BenchmarkGoGCMBlockSize/8192-4 148916 8033 ns/op 1019.83 MB/s
BenchmarkGoGCMBlockSize/16384-4 75337 15911 ns/op 1029.75 MB/s
BenchmarkGoGCMBlockSize/32768-4 37912 31651 ns/op 1035.30 MB/s
BenchmarkGoGCMBlockSize/65536-4 19000 64287 ns/op 1019.43 MB/s
BenchmarkGoGCMBlockSize/131072-4 9225 127636 ns/op 1026.92 MB/s
BenchmarkGoGCMBlockSize/262144-4 4752 252300 ns/op 1039.02 MB/s
BenchmarkGoGCMBlockSize/524288-4 2377 504612 ns/op 1038.99 MB/s
BenchmarkGoGCMBlockSize/1048576-4 1183 1011637 ns/op 1036.51 MB/s
|
|
Only visible when you run "go test -bench" like this:
$ cd gocryptfs/internal/speed
$ go test -bench .
goos: linux
goarch: amd64
pkg: github.com/rfjakob/gocryptfs/v2/internal/speed
cpu: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz
BenchmarkStupidGCM-4 202352 5937 ns/op 689.96 MB/s
BenchmarkStupidGCMDecrypt-4 206023 5782 ns/op 708.38 MB/s
BenchmarkGoGCM-4 291878 4098 ns/op 999.45 MB/s
BenchmarkGoGCMBlockSize/1024-4 1000000 1151 ns/op 889.88 MB/s
BenchmarkGoGCMBlockSize/2048-4 561182 2134 ns/op 959.60 MB/s
BenchmarkGoGCMBlockSize/4096-4 292057 4101 ns/op 998.87 MB/s
BenchmarkGoGCMBlockSize/8192-4 149216 8031 ns/op 1020.09 MB/s
BenchmarkGoGCMBlockSize/16384-4 75361 15917 ns/op 1029.34 MB/s
BenchmarkGoGCMBlockSize/32768-4 37916 31649 ns/op 1035.35 MB/s
BenchmarkGoGCMBlockSize/65536-4 19005 63117 ns/op 1038.33 MB/s
BenchmarkGoGCMBlockSize/131072-4 9498 126166 ns/op 1038.89 MB/s
BenchmarkGoGCMBlockSize/262144-4 4755 252149 ns/op 1039.64 MB/s
BenchmarkGoGCMBlockSize/524288-4 2377 504108 ns/op 1040.03 MB/s
BenchmarkGoGCMBlockSize/1048576-4 1188 1008675 ns/op 1039.56 MB/s
BenchmarkGoGCMDecrypt-4 294664 4059 ns/op 1009.02 MB/s
BenchmarkAESSIV-4 46498 25432 ns/op 161.05 MB/s
BenchmarkAESSIVDecrypt-4 46908 25509 ns/op 160.57 MB/s
BenchmarkXchacha-4 244473 4894 ns/op 836.97 MB/s
BenchmarkXchachaDecrypt-4 249710 4798 ns/op 853.75 MB/s
BenchmarkStupidXchacha-4 166988 7101 ns/op 576.79 MB/s
BenchmarkStupidXchachaDecrypt-4 163093 7240 ns/op 565.72 MB/s
BenchmarkStupidChacha-4 184172 6527 ns/op 627.58 MB/s
BenchmarkStupidChachaDecrypt-4 179796 6659 ns/op 615.11 MB/s
PASS
ok github.com/rfjakob/gocryptfs/v2/internal/speed 30.068s
|
|
Commit 6196a5b5 got the logic inverted, hence we never
set the last position markers.
Fixes https://github.com/rfjakob/gocryptfs/issues/712
|
|
It used to be reported as "function not implemented", accompanied
with this log output:
go-fuse: can't convert error type: ParseHeader: header is all-zero. Header hexdump: 000000000000000000000000000000000000
Now we report EIO and log this:
doWrite 1372183: corrupt header: ParseHeader: header is all-zero. Header hexdump: 000000000000000000000000000000000000
|
|
Get rid of this eyesore.
|
|
Calculated acc. to https://words.filippo.io/the-scrypt-parameters/ ,
and add benchmarks to double-check the numbers. They match.
|
|
Run "make format" using
go version go1.19.4 linux/amd64
|
|
Replace dependency jacobsa/crypto with a fork with support for riscv64.
Issue: https://github.com/rfjakob/gocryptfs/issues/666
Upstream PR: https://github.com/jacobsa/crypto/issues/13
Unaddressed on jacobsa/crypto:
https://github.com/jacobsa/crypto/pull/14#issuecomment-1182744229
Signed-off-by: Christian Stewart <christian@paral.in>
|
|
Fixes https://github.com/rfjakob/gocryptfs/issues/681
Fixes 2a25c3a8fda1f0918fd76687561b1a9c615298b9
|
|
|
|
|
|
|
|
Signed-off-by: Abirdcfly <fp544037857@gmail.com>
|
|
|
|
Unlike the FUSE implementation on Linux, macFUSE doesn't cache the file
attributes from the `LOOKUP` call, so it calls `GETATTR` prior to
accessing a file.
In the case of the `VirtualConfNode` (reverse config file passthrough),
this resulted in the default `GETATTR` implementation returning an empty
result, ultimately resulting in a "permission denied" error.
14:44:14.095207 rx 3: GETATTR n2
14:44:14.095229 tx 3: OK, {tA=1s {M0100000 SZ=0 L=0 0:0 0 0:8954996 A 0.000000 M 0.000000 C 0.000000}}
14:44:14.099943 rx 4: ACCESS n2 {u=501 g=20 r}
14:44:14.099990 tx 4: 13=permission denied
By impementing `Getattr` (from `fs.NodeGetattrer`) on `VirtualConfNode`
this solves the issue.
|
|
|
|
$ ./crossbuild.bash
[...]
+ GOOS=darwin
+ GOARCH=amd64
+ build
+ go build -tags without_openssl -o /dev/null
internal/fusefrontend/node.go:397:2: duplicate case syscallcompat.RENAME_NOREPLACE (value 0) in switch
previous case at internal/fusefrontend/node.go:397:7
internal/fusefrontend/node.go:397:2: duplicate case syscallcompat.RENAME_EXCHANGE (value 0) in switch
previous case at internal/fusefrontend/node.go:397:7
internal/fusefrontend/node.go:397:2: duplicate case syscallcompat.RENAME_WHITEOUT (value 0) in switch
previous case at internal/fusefrontend/node.go:397:7
internal/fusefrontend/node.go:399:38: duplicate case syscallcompat.RENAME_NOREPLACE | syscallcompat.RENAME_WHITEOUT (value 0) in switch
previous case at internal/fusefrontend/node.go:397:7
|
|
Both new internal test and xfstests generic/013 are happy.
https://github.com/rfjakob/gocryptfs/issues/641
|
|
Fixes https://github.com/rfjakob/gocryptfs/issues/629
|
|
This allows cleanups to happen in the caller, like removing
the control socket.
Fixes https://github.com/rfjakob/gocryptfs/issues/634
|
|
|
|
xattr names have fewer restrictions than file names,
relax the validation.
Fixes https://github.com/rfjakob/gocryptfs/issues/627
|
|
This
gocryptfs -init /does/not/exist 2> err.log
used to write escape codes into err.log. Stop doing that.
|
|
Fixes https://github.com/rfjakob/gocryptfs/issues/617
|
|
Running the tests we have lots of these:
Openat: O_NOFOLLOW missing: flags = 0x4
-wpanic turns this warning into a panic: Openat: O_NOFOLLOW missing: flags = 0x4
panic: -wpanic turns this warning into a panic: Openat: O_NOFOLLOW missing: flags = 0x4
goroutine 114 [running]:
log.(*Logger).Panic(0x14000118280, {0x14000313ca8, 0x1, 0x1})
log/log.go:224 +0x90
github.com/rfjakob/gocryptfs/v2/internal/tlog.(*toggledLogger).Printf(0x14000076780, {0x1009dc2e8, 0x27}, {0x14000313d18, 0x1, 0x1})
github.com/rfjakob/gocryptfs/v2/internal/tlog/log.go:78 +0x168
github.com/rfjakob/gocryptfs/v2/internal/syscallcompat.Openat(0x9, {0x1009d0747, 0x1}, 0x4, 0x0)
github.com/rfjakob/gocryptfs/v2/internal/syscallcompat/sys_common.go:59 +0xf0
github.com/rfjakob/gocryptfs/v2/internal/fusefrontend.(*Node).getXAttr(0x14000142000, {0x1400001c140, 0x3a})
github.com/rfjakob/gocryptfs/v2/internal/fusefrontend/node_xattr_darwin.go:30 +0x8c
github.com/rfjakob/gocryptfs/v2/internal/fusefrontend.(*Node).Getxattr(0x14000142000, {0x100a7eba0, 0x1400000c2e8}, {0x14000016348, 0x14}, {0x14000326000, 0x20, 0x4000})
github.com/rfjakob/gocryptfs/v2/internal/fusefrontend/node_xattr.go:65 +0x1ac
github.com/hanwen/go-fuse/v2/fs.(*rawBridge).GetXAttr(0x1400008e140, 0x140001901e0, 0x140001133c0, {0x14000016348, 0x14}, {0x14000326000, 0x20, 0x4000})
github.com/hanwen/go-fuse/v2@v2.1.1-0.20210825171523-3ab5d95a30ae/fs/bridge.go:685 +0x114
github.com/hanwen/go-fuse/v2/fuse.doGetXAttr(0x14000144000, 0x14000113200)
github.com/hanwen/go-fuse/v2@v2.1.1-0.20210825171523-3ab5d95a30ae/fuse/opcode.go:270 +0x224
github.com/hanwen/go-fuse/v2/fuse.(*Server).handleRequest(0x14000144000, 0x14000113200)
github.com/hanwen/go-fuse/v2@v2.1.1-0.20210825171523-3ab5d95a30ae/fuse/server.go:499 +0x214
created by github.com/hanwen/go-fuse/v2/fuse.(*Server).loop
github.com/hanwen/go-fuse/v2@v2.1.1-0.20210825171523-3ab5d95a30ae/fuse/server.go:470 +0xac
https://github.com/rfjakob/gocryptfs/issues/625
|
|
Quoting fusefrontend_reverse/node_helpers.go :
// File names are padded to 16-byte multiples, encrypted and
// base64-encoded. We can encode at most 176 bytes to stay below the 255
// bytes limit:
// * base64(176 bytes) = 235 bytes
// * base64(192 bytes) = 256 bytes (over 255!)
// But the PKCS#7 padding is at least one byte. This means we can only use
// 175 bytes for the file name.
Noticed by @bailey27 at https://github.com/rfjakob/gocryptfs/issues/499#issuecomment-955790427
|
|
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.
|
|
Fixes https://github.com/rfjakob/gocryptfs/issues/499
|
|
Feature flag + numeric paramater
https://github.com/rfjakob/gocryptfs/issues/499
|