Long passwords (and passwords ending with newlines) still have problems.

[mpb]

Hi,

I reported via email that there were problems with passwords longer than 64 characters. Also, if the password is read from a file, the trailing character was removed, even if it was not a newline.

You partially fixed the problem in 1.4.0 by changing:

   const int MaxPassBuf = 1024;

However, this change also needs to be made in the getNewUserKey function.

You also removed the code that trimmed off the newline. Unfortunately, now if the last character of the file *is* a newline, it is *no longer* removed. This change breaks old passwords, rendering old filesystems unreadable. Given that you are reading the password in with fgets, I think encfs should trim the newline, if it is present. (fgets is not a safe way to read in binary passwords.)

Below is a patch against 1.4.0 that fixes both of these issues.

--- encfs-1.4.0/encfs/FileUtils.cpp.ap-orig 2008-01-11 22:20:55.000000000 -0800
+++ encfs-1.4.0/encfs/FileUtils.cpp 2008-01-11 22:26:13.000000000 -0800
@@ -1153,6 +1153,10 @@
     if( useStdin )
     {
        res = fgets( passBuf, sizeof(passBuf), stdin );
+ // Kill the trailing newline.
+ if (passBuf[ strlen(passBuf)-1 ] == '\n') {
+ passBuf[ strlen(passBuf)-1 ] = '\0';
+ }
     } else
     {
        // xgroup(common)
@@ -1279,7 +1283,7 @@

 CipherKey getNewUserKey( const shared_ptr<Cipher> &cipher )
 {
- const int MaxPassBuf = 64;
+ const int MaxPassBuf = 1024;
     CipherKey userKey;
     char passBuf[MaxPassBuf];
     char passBuf2[MaxPassBuf];

[mpb (mpb-mail)]

Here is the above patch as an attachment.

[Valient Gough (vgough)]

Thank you.

I've check in a change. It is unfortunate about password incompatibility. But rather then keep separate logic for 1.4.0 vs all other versions, I think it is best that I release a 1.4.1 quickly with the couple changes so far and give notice that encfs 1.4.x differs in how it handles passwords in --stdin or --extpass options. Even the change to the password length is incompatible behavior, but I think it is for the best.

regards,
Valient