Age | Commit message (Collapse) | Author |
|
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
|
|
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
|
|
Because switch only matches once, we could have missed invalid
cases.
Replace the switch statements with a straight if rake.
|
|
|
|
Reported by codacity:
internal/cryptocore/cryptocore.go
Minor icon MINOR
Code Style
should omit type AEADTypeEnum from declaration of var BackendAESSIV; it will be inferred from the right-hand side
var BackendAESSIV AEADTypeEnum = AEADTypeEnum{"AES-SIV-512", "Go", siv_aead.NonceSize}
Minor icon MINOR
Code Style
should omit type AEADTypeEnum from declaration of var BackendXChaCha20Poly1305; it will be inferred from the right-hand side
var BackendXChaCha20Poly1305 AEADTypeEnum = AEADTypeEnum{"XChaCha20-Poly1305", "Go", chacha20poly1305.NonceSizeX}
Minor icon MINOR
Code Style
should omit type AEADTypeEnum from declaration of var BackendXChaCha20Poly1305OpenSSL; it will be inferred from the right-hand side
var BackendXChaCha20Poly1305OpenSSL AEADTypeEnum = AEADTypeEnum{"XChaCha20-Poly1305", "OpenSSL", chacha20poly1305.NonceSizeX}
Found 2 possible new issues
internal/cryptocore/cryptocore.go
Minor icon MINOR
Code Style
should omit type AEADTypeEnum from declaration of var BackendOpenSSL; it will be inferred from the right-hand side
var BackendOpenSSL AEADTypeEnum = AEADTypeEnum{"AES-GCM-256", "OpenSSL", 16}
Minor icon MINOR
Code Style
should omit type AEADTypeEnum from declaration of var BackendGoGCM; it will be inferred from the right-hand side
var BackendGoGCM AEADTypeEnum = AEADTypeEnum{"AES-GCM-256", "Go", 16}
|
|
Used in gocryptfs-xray, and will also be used in -info.
|
|
When somebody posts "gocryptfs -speed" results, they are
most helpful together with the CPU model. Add the cpu model
to the output.
Example:
$ ./gocryptfs -speed
gocryptfs v2.2.0-beta1-5-g52b0444-dirty; go-fuse v2.1.1-0.20210825171523-3ab5d95a30ae; 2021-09-14 go1.17.1 linux/amd64
cpu: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz; with AES acceleration
AES-GCM-256-OpenSSL 862.79 MB/s
AES-GCM-256-Go 997.71 MB/s (selected in auto mode)
AES-SIV-512-Go 159.58 MB/s
XChaCha20-Poly1305-OpenSSL 729.65 MB/s
XChaCha20-Poly1305-Go 843.97 MB/s (selected in auto mode)
|
|
Makes the code clearer, and will be used in the next commit.
|
|
|