gocryptfs/internal/fusefrontend, branch v1.4.1Mirror of gocryptfs source code on Githubhttp://nuetzlich.net/cgit/gocryptfs/atom?h=v1.4.12017-08-15T17:04:02+00:00fusefrontend: use Getdents if available2017-08-15T17:04:02+00:00Jakob Unterwurzacher2017-08-15T16:35:30+00:00urn:sha1:989b88098951e5ad68b66049e59fd2ca475c4711
Getdents avoids calling Lstat on each file.
main: purge masterkey from memory as soon as possible2017-08-11T17:02:26+00:00Jakob Unterwurzacher2017-08-11T16:42:30+00:00urn:sha1:0c520845f3623eff28f0277a52e3ccffd928f5c2
Remove the "Masterkey" field from fusefrontend.Args because it
should not be stored longer than neccessary. Instead pass the
masterkey as a separate argument to the filesystem initializers.
Then overwrite it with zeros immediately so we don't have
to wait for garbage collection.
Note that the crypto implementation still stores at least a
masterkey-derived value, so this change makes it harder, but not
impossible, to extract the encryption keys from memory.
Suggested at https://github.com/rfjakob/gocryptfs/issues/137
fusefronted: enable writing to write-only files2017-07-11T21:19:58+00:00Jakob Unterwurzacher2017-07-11T21:19:58+00:00urn:sha1:3062de6187990f9b4f669ecd9dffdd48ee0d778f
Due to RMW, we always need read permissions on the backing file. This is a
problem if the file permissions do not allow reading (i.e. 0200 permissions).
This patch works around that problem by chmod'ing the file, obtaining a fd,
and chmod'ing it back.
Test included.
Issue reported at: https://github.com/rfjakob/gocryptfs/issues/125
fusefrontend: doRead: skip decryption for an empty read2017-07-02T14:02:13+00:00Jakob Unterwurzacher2017-07-02T13:59:38+00:00urn:sha1:52ab0462a42c22ccf07d0cc110590fc7db957182
Previously we ran through the decryption steps even for an empty
ciphertext slice. The functions handle it correctly, but returning
early skips all the extra calls.
Speeds up the tar extract benchmark by about 4%.
contentenc: add PReqPool and use it in DecryptBlocks2017-06-30T21:30:57+00:00Jakob Unterwurzacher2017-06-30T21:30:57+00:00urn:sha1:12c0101a232928e8969f23235ca45506e743d547
This gets us a massive speed boost in streaming reads.
fusefrontend: doRead: use CReqPool for ciphertext buffer2017-06-30T21:15:31+00:00Jakob Unterwurzacher2017-06-30T21:15:31+00:00urn:sha1:b2a23e94d10a7e3f7e25db50211b167f6fb280da
Easily saves lots of allocations.
fusefrontend: Read: use provided buffer2017-06-30T21:11:38+00:00Jakob Unterwurzacher2017-06-30T21:11:38+00:00urn:sha1:06398e82d91c81c618bfa6a481c0e9070847c909
This will allow us to return internal buffers to a pool.
contentenc: add safer "bPool" pool variant; add pBlockPool2017-06-29T21:44:32+00:00Jakob Unterwurzacher2017-06-29T20:05:23+00:00urn:sha1:80676c685fe2b52ce0c48a7d9d922895d0c583b8
bPool verifies the lengths of slices going in and out.
Also, add a plaintext block pool - pBlockPool - and use
it for decryption.
contentenc: use sync.Pool memory pools for encryption2017-06-20T19:22:00+00:00Jakob Unterwurzacher2017-06-20T19:22:00+00:00urn:sha1:3c6fe98eb1e5dada2613664182ead18be9e68819
We use two levels of buffers:
1) 4kiB+overhead for each ciphertext block
2) 128kiB+overhead for each FUSE write (32 ciphertext blocks)
This commit adds a sync.Pool for both levels.
The memory-efficiency for small writes could be improved,
as we now always use a 128kiB buffer.
Fix missing Owner coercion for already-open files (#117)2017-06-09T20:04:56+00:00Charles Duffy2017-06-09T19:37:30+00:00urn:sha1:da1bd742461e397abefc814bb0c0a21a6d8ec3d6