Passfile and Extpass is used as both old and new password when changing password

[slackner]

I already mentioned this at https://github.com/rfjakob/gocryptfs/commit/295d432175292dbaef572093d784aab55f5c0b8f#r31705033 - now turning into a proper bug report since I verified that this is indeed an issue.

Steps to reproduce:

$ gocryptfs -passwd -passfile test.txt directory
passfile: reading from file "test.txt"
Decrypting master key
Please enter your new password.
passfile: reading from file "test.txt"
Password changed.

or, equivalently:

$ gocryptfs -passwd -extpass "cat -- test.txt" directory
Reading password from extpass program
Decrypting master key
Please enter your new password.
Reading password from extpass program
Password changed.

In both cases, the password is changed back to what it was initially without giving the user a chance to interact with the program. I assume we can agree that this does not make any sense. ;)

There are several options what we could do to fix that, either:

• Ignore -passfile and -extpass options for this command entirely.
• Use it only for the old password, but never for the new password.
• Support multiline files / program output, where both the old and new password are provided.
• Add separate command line options for the new passfile / extpass.
• ...

For me the second option sounds like the best choice (at least for now), but I'll leave that up to you.

[rfjakob]

Hehe. True, looks pretty useless, however, what if the file is actually a pipe?

[slackner]

Since trailing garbage will be ignored, it will still be pretty difficult to interact with the program, even when using a pipe. A programmer would have to add some artificial delay, to make sure that the second line isn't already read when unlocking the database (see https://github.com/rfjakob/gocryptfs/commit/295d432175292dbaef572093d784aab55f5c0b8f#diff-370dbd213c0ec955541f4b58b8acb1d5R38).

[rfjakob]

I believe the pipe will be closed between the first and 2nd read, this should work ok without delays

[rfjakob]

The extpass case makes sense in any case i believe, as it may open something like a GUI popup for asking the user. And it will be called twice, once for the old, once for the new password.

[slackner]

Using -extpass to show a fancy GUI popup would work, but a lot of other things are quite difficult to achieve with the current design.

• When using a pass file to unlock the gocryptfs volume, the -passfile option can not be used to change the password. The user manually has to insert the old password, choose a new password, and then copy the new password into the pass file.

• Using -passfile also can not be easily used in a script: Only with a unix socket it is possible to detect the closed pipe (and thus to send the old and new password separately without having an artificial delay). This increases the complexity and makes it impossible to use this method in a simple shell script.

• When using -extpass, there is also no way for the user to know if the dialog asks for the old or new password. This means you would have to pass a script and internally count how often it was called.

What do you think about the following suggestions:

• Since you also support stdin (which is much easier to use from a script), I would suggest to limit -passfile to regular files. The new password is typed using stdin, then the passfile is automatically updated.

• To make -extpass easier to use, gocryptfs could set environment variables that can be used by the calling program to show an appropriate dialog.

What do you think about these ideas?

[yajo]

I think the easiest fix is to add -extpassnew and -passfilenew CLI options, which get invoked to ask the new password, leaving the other 2 options to obtain the previous password.

For now, it seems the easiest way to automate the process is:

echo old > p1
echo new > p2
cat p1 p2 | gocryptfs -passwd encrypted_dir