When copying a directory recursively we should manually
perform the recursion since EncFSFileProvider.copy()
interface doesn't allow recursive copies.
Also, we should update dstPath with the newly created
directory to copy/move stuff from srcPath into it.
Create many different types of volumes and run the file operations
test on each volume. The following volume configurations are now
being tested:
* Default volume
* No Unique IV
* No Chained name IV
* No Unique IV or Chained IV
* No zero block passthrough
* 256-bit volume key
* 128-bit volume key
* 4096 byte block size
* Stream name algorithm
* 8 byte block MAC header
* 8 byte block MAC header + 8 random bytes
Also, I've split off the core testing logic into EncFSVolumeTestCommon,
and created two separate tests, one using CommonVFSFileProvider and one
using EncFSLocalFileProvider.
Misc cleanups:
* Split off createTempDir() to be under EncFSVolumeTestCommon
* Sort file lists in testFileOperations to deal with arbitrary ordering
from EncFSFileProvider's
Implemented recursive directory deletion support controlled by a
boolean option in EncFSVolume.deletePath(). Extended the EncFSShell
'rm' command to make use of this functionality and added a test
case to EncFSVolumeTest to exercise recursive deletion of a
non-empty directory path.
There was a bug in EncFSVolume.movePath() that caused recursive moves
in the case of ChainedNameIV configurations to fail. Also improved
rollback handling in the case of an error during the recursive move
by trying to delete the newly created directories.
Added a FileNotFoundException to EncFSLocalFileProvider.move()
implementation as well.
This commit cleans up EncFSShell path handling to allow absolute paths
as well as relative paths with multiple path elements. For example:
/ > ls
testdir1/
/ > ls testdir1/testdir2
testdir-with-really-really-long-name/
testfile2.txt
/ > cd testdir1/testdir3/testdir4
/testdir1/testdir3/testdir4 > cat /testdir1/testfile.txt
file contents!
file contents!
...
All existing commands were improved to use the new path handling
capabilities. Cleaned up error messages in the process as well.
Made EncFSLocalFileProvider.mkdir() throw a FileNotFoundException
if one or more path elements aren't found. Also modified
EncFSVolume.makeDir to filter this exception to print the
unencrypted path in the exception message.
Noticed we're doing full InputStream->OutputStream copies quite a bit
around the code, so this commit adds a utility function for that and
calls it from everywhere.
This is a massive commit serving a few purposes:
* Unify code formatting and style to conform to Eclipse formatting. We
will use this formatting from now on for all new code to have a
uniform codebase.
* Clean up API naming and remove redundancies. I've renamed a lot of
API functions to promote coherence across the codebase. I've also
removed some redundant API's to promote best practices.
* Improve JavaDoc coverage. This commit documents all public methods
within the library itself.
* Fix JavaDoc warnings.
The extra copy in EncFSInputStream wasn't necessary. Unfortunately the
copy in EncFSOutputStream can't be averted, but this commit moves it to
be in streamEncode() itself.
This commit implements the blockMACBytes and blockMACRandBytes options
that cause a header to be inserted in front of every file block
containing a MAC of the block (and optionally some random data).
Added support to EncFSConfig, EncFSConfigParser and EncFSConfigWriter
to recognize these options. Implemented the MAC computation,
verification and insertion in EncFSInputStream and EncFSOutputStream.
Added a new test volume configured with 8 bytes of MAC and 8 bytes of
random bytes as 'testvol-blockmac', and extended EncFSVolumeTest to
include a long file test that verifies the MAC computations.
Added two 6000 byte files to the default and no unique IV test volumes
and added tests that verify decrypted content. These tests are useful
for testing block encryption.
Separated the step of instantiating an EncFSVolume from the
createVolume() function. This allows batch volume creation support
without having to do the associated crypto that comes with creating
an EncFSVolume object to actually use the created volume.
This commit adds initial support for volume creation. A new class was
added for writing an EncFSConfig to a file (EncFSConfigWriter). Provided
utility methods for getting a default EncFSConfig and creating a new
volume with a given password and EncFSConfig.
Added a basic volume creation test which creates a temporary directory
and creates a volume within, making sure that encfs-java is able to
instantiate an EncFSVolume on it afterwards. I also made sure that the
upstream encfs implementation can read the volume created by this test
also.
We shouldn't use the EncFSFile constructor that takes in a File any
more since we have EncFSLocalFileProvider now. This change removes
that constructor and all the EncFSVolume special casing for it.
Removed all File based constructors for EncFSVolume. Only kept the
following constructors:
EncFSVolume(String rootPath, String password)
EncFSVolume(String rootPath, byte[] passwordKey)
EncFSVolume(EncFSFileProvider fileProvider, String password)
EncFSVolume(EncFSFileProvider fileProvider, byte[] passwordKey)
EncFSVolume(EncFSFileProvider fileProvider, EncFSConfig config,
String password)
EncFSVolume(EncFSFileProvider fileProvider, EncFSConfig config,
byte[] passwordKey)
The first two constructors are easy to use ones for volumes on the local
filesystem. The next two allow non-local storage to be plugged in using
a custom EncFSFileProvider implementation. The last two allow the config
file to be parsed externally, to support the use case where the config
file is located separately than the volume.
EncFSVolume.listFiles() would fail when given this.rootDir as a
parameter because it concatanated the rootDir's last path element
with the root path and ended up causing null pointer exception in
EncFSLocalFileSystemNativeFileSource.listFiles().
In case the file parameter was the root directory, this function
attempted to substring into the parent directory using the root
directories length, resulting in out of bounds index access in
substring().
1) Bug fix for EncFSInputStream missing off the last byte of the stream
2) Initial support for EncFSFileOutputStream
3) Additional tests
4) EncFSComparer enhanced to check file read/ re-write
tests to new files
Conflicts:
src/main/java/org/mrpdaemon/sec/encfs/EncFSCrypto.java
src/main/java/org/mrpdaemon/sec/encfs/EncFSFile.java
src/test/java/org/mrpdaemon/sec/encfs/EncFSComparer.java
src/test/java/org/mrpdaemon/sec/encfs/EncFSVolumeTest.java
This change adds support for nameio/stream mode of filename encryption.
Also as a bonus change it fixes the MAC computation for volumes that
do not use chained name IV.
Remove hardcoded 32-byte volume key size in EncFSCrypto.decryptVolumeKey
to support volumes with key sizes different than 256 bits. Tested to
work fine with the standard options under encfs 1.7.4 which creates
a volume with a 192-bit key.
Added constructors for EncFSVolume to allow the password-based key
and IV data to be cached, and re-used to create an EncFSVolume for
the same volume at a later time.
On some runtimes the readBlock() implementation ended up recursively
calling into read(byte[]) since the call into super.read(byte[]) gets
reflected back into EncFSFileInputStream resulting into infinite
recursion. As a lame solution, removing read(byte[], int, int) from
EncFSFileInputStream and calling FileInputStream.read(byte[], int, int)
from readBlock().
Bundle Robert Harder's Base64 implementation [1] instead of using
javax.xml.bind.DatatypeConverter to do base64 decoding since
Android doesn't package JAXB.
[1] http://iharder.sourceforge.net/current/index.html