Mirror of gocryptfs source code on Github http://nuetzlich.net/cgit/gocryptfs/atom?h=v1.7-rc1 2018-12-27T17:47:14+00:00 2018-12-27T17:47:14+00:00 Sebastian Lackner 2018-12-26T20:17:54+00:00 urn:sha1:07c486603c42af00c81d9e76e3b0731aa986e881 Further raises the bar for recovering keys from memory. 2018-12-27T14:19:55+00:00 Sebastian Lackner 2018-12-27T11:03:00+00:00 urn:sha1:874eaf9734cc10940e08f7b043652449e1e220b5 Mostly detected with the 'codespell' utility, but also includes some manual grammar fixes. 2018-07-15T09:39:19+00:00 Jakob Unterwurzacher 2018-07-15T09:39:07+00:00 urn:sha1:bcca323cb778d3ab9bf3b16e041ede5e67b18ff8 File holes and -fsck can cause unaligned read accesses, which means we have to decrypt one extra plaintext block. xfstests generic/083 manage to crash -fsck like this: generic/083 2018/07/14 15:25:21 wrong len=266240, want=131072 panic: wrong len=266240, want=131072 goroutine 1 [running]: log.Panicf(0x67fc00, 0x15, 0xc4204fec90, 0x2, 0x2) /usr/local/go/src/log/log.go:333 +0xda github.com/rfjakob/gocryptfs/internal/contentenc.(*bPool).Put(0xc4200d4800, 0xc4202f2000, 0x21000, 0x41000) /home/jakob/go/src/github.com/rfjakob/gocryptfs/internal/contentenc/bpool.go:27 +0x15d github.com/rfjakob/gocryptfs/internal/fusefrontend.(*File).doRead(0xc4200b4500, 0xc42019e000, 0x0, 0x20000, 0x28400, 0x20000, 0xc42019e000, 0xc4204ff008, 0x435164, 0xc420000180) /home/jakob/go/src/github.com/rfjakob/gocryptfs/internal/fusefrontend/file.go:227 +0xba9 github.com/rfjakob/gocryptfs/internal/fusefrontend.(*File).Read(0xc4200b4500, 0xc42019e000, 0x20000, 0x20000, 0x28400, 0x0, 0x0, 0x0) /home/jakob/go/src/github.com/rfjakob/gocryptfs/internal/fusefrontend/file.go:246 +0x23e main.(*fsckObj).file(0xc420069320, 0xc42001a630, 0x21) /home/jakob/go/src/github.com/rfjakob/gocryptfs/fsck.go:126 +0x21f main.(*fsckObj).dir(0xc420069320, 0xc420014dc0, 0x1d) /home/jakob/go/src/github.com/rfjakob/gocryptfs/fsck.go:76 +0x387 main.(*fsckObj).dir(0xc420069320, 0xc42021dae0, 0x19) /home/jakob/go/src/github.com/rfjakob/gocryptfs/fsck.go:74 +0x347 2018-04-02T16:32:30+00:00 Jakob Unterwurzacher 2018-04-02T16:32:30+00:00 urn:sha1:b6c8960b01f9e5366814b0dada57a0b1e6a031d9 Make sure we get only 1 warning output per problem. Also, add new corruption types to broken_fs_v1.4. 2018-03-25T19:06:10+00:00 Jakob Unterwurzacher 2018-03-18T16:43:38+00:00 urn:sha1:1ed3d51df1750d5472b1349222c352171f1e8d64 At the moment, only for reverse mode. https://github.com/rfjakob/gocryptfs/issues/217 2017-10-19T07:23:10+00:00 Jakob Unterwurzacher 2017-10-19T07:23:10+00:00 urn:sha1:29445c976d200f6e734eae56d9665fd4098f0a43 ...to account for unaligned reads. I have not seen this happen in the wild because the kernel always seems to issue 4k-aligned requests. But the cost of the additional block in the pool is low and prevents a buffer overrun panic when an unaligned read does happen. 2017-10-17T19:48:29+00:00 Jakob Unterwurzacher 2017-10-17T19:47:32+00:00 urn:sha1:3009ec9852316c3c696f77f476390ab5a6d8d6d7 Our byte cache pools are sized acc. to MAX_KERNEL_WRITE, but the running kernel may have a higher limit set. Clamp to what we can handle. Fixes a panic on a Synology NAS reported at https://github.com/rfjakob/gocryptfs/issues/145 2017-09-17T09:21:48+00:00 Jakob Unterwurzacher 2017-09-17T09:21:48+00:00 urn:sha1:885fdcabdacb2d53829e7f96f4c600df0a3e282d The encrypt and decrypt path both had a copy that were equivalent but ordered differently, which was confusing. Consolidate it in a new dedicated function. 2017-09-17T08:59:04+00:00 Jakob Unterwurzacher 2017-09-17T08:59:04+00:00 urn:sha1:4bd2c6736afbe20d6aa7d94758082d8c8752af4b Using firstBlockNo as the counter is confusing, create a copy named "blockNo" and use that. 2017-08-21T19:06:05+00:00 Jakob Unterwurzacher 2017-08-21T19:06:05+00:00 urn:sha1:ed046aa35978c835d79f9cb3ee359349ee9145c5 https://goreportcard.com/report/github.com/rfjakob/gocryptfs#misspell