gocryptfs/tests/defaults, branch det Mirror of gocryptfs source code on Github http://nuetzlich.net/cgit/gocryptfs/atom?h=det 2017-05-07T19:01:39+00:00 fusefrontend: implement path decryption via ctlsock 2017-05-07T19:01:39+00:00 Jakob Unterwurzacher 2017-05-07T19:01:39+00:00 urn:sha1:ad7942f434fea567f24458e67a0919291b5ec8dd Closes https://github.com/rfjakob/gocryptfs/issues/84 . tests: add TestXfs124 2017-05-01T16:44:03+00:00 Jakob Unterwurzacher 2017-05-01T16:36:25+00:00 urn:sha1:9768376bd1961a5aa0fbf7f08de0601322664fc3 This test reproduces the problem xfstests generic/124 uncovered. The warning itself is harmless, but we should either (1) add locking so that this cannot happen anymore or (2) drop the warning. Currently fails: $ go test -v === RUN Test1980Tar --- PASS: Test1980Tar (0.00s) === RUN TestCtlSock --- PASS: TestCtlSock (0.10s) === RUN TestOpenTruncateRead --- PASS: TestOpenTruncateRead (0.00s) === RUN TestWORead --- PASS: TestWORead (0.00s) === RUN TestXfs124 cipherSize 18 == header size: interrupted write? -wpanic turns this warning into a panic: cipherSize 18 == header size: interrupted write? fusefrontend: drop writeOnly flag 2017-05-01T15:49:37+00:00 Jakob Unterwurzacher 2017-05-01T15:49:37+00:00 urn:sha1:9ab11aa4d775f7c1242e8b044cc2f8957cc2c784 We do not have to track the writeOnly status because the kernel will not forward read requests on a write-only FD to us anyway. I have verified this behavoir manually on a 4.10.8 kernel and also added a testcase. tests: ctlsock: check warning for non-canonical paths 2017-02-12T11:22:25+00:00 Jakob Unterwurzacher 2017-02-12T11:22:25+00:00 urn:sha1:357307cbcfaafb2b22f01e780d717df1a3f8eb1b ctlsock: sanitize paths before passing them to the backend 2016-12-10T11:59:54+00:00 Jakob Unterwurzacher 2016-12-10T11:59:54+00:00 urn:sha1:2758c75cae2896b7f1327fe00f60a1c017c0e0d1 You used to be able to crash gocryptfs by passing "/foo" of "foo/" to the ctlsock. Fixes https://github.com/rfjakob/gocryptfs/issues/66 tests: add OpenTruncateRead test 2016-11-17T21:48:50+00:00 Jakob Unterwurzacher 2016-11-07T19:58:12+00:00 urn:sha1:1bae06a16a94950cfbb134f64a765bb34db1f167 This is a regression test for the issue that was fixed by the last commit. ctlsock: implement EncryptPath for reverse mode, add tests 2016-11-10T22:32:51+00:00 Jakob Unterwurzacher 2016-11-10T22:32:51+00:00 urn:sha1:c03fc46a5150715bf6aee20ce4b89d9704141220 ctlsock: add initial limited implementation 2016-11-09T23:27:08+00:00 Jakob Unterwurzacher 2016-11-09T23:27:08+00:00 urn:sha1:75ebb28a625bc16d145f5acd9e0cc1d305716afe At the moment, in forward mode you can only encrypt paths and in reverse mode you can only decrypt paths. tests: add example tar 2016-10-19T20:32:21+00:00 Jakob Unterwurzacher 2016-10-19T20:32:21+00:00 urn:sha1:1e66499af87b77314a30fed0ed429d3d73202e6d tests: add 1980.tar.gz extract test 2016-10-19T20:25:54+00:00 Jakob Unterwurzacher 2016-10-19T20:25:54+00:00 urn:sha1:589748548f24429bb30a8aafb3cae0d295b07da0 Test that we get the right timestamp when extracting a tarball. Also simplify the workaround in doTestUtimesNano() and fix the fact that it was running no test at all.