Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Cryptkeeper sets the same password "p" for everything independently of user input #23
Hi, there is a serious security hole in cryptkeeper.
Details are in this Debian bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852751
Here is a quote from Kirill Tkhai firstname.lastname@example.org, who found this bug:
"I've looked into cryptkeeper code and found, it calls encfs
execlp ("encfs", "encfs", "-S", crypt_dir, mount_dir, NULL);
While the password is passed to encfs using pipe in this way:
But it seems it's wrong. When I'm executing encfs program
$ encfs -S crypt_dir mount_dir
and I'm passing "p\n", encfs exits and doesn't wait for a password
This may be caused by a change in the underlying encfs interface.
According to the simple echo usage at http://jc.coynel.net/2013/09/reading-a-encfs-volume-password-from-a-file/, the
Hmm, CLI change?
I do not think this is a bug in cryptkeeper and cryptkeeper is doing here what everybody else i know does.
The problem is in encfs somehow not behaving as expected in debian.
Below is output that shows how the latest version of encfs works and what cryptkeeper expects
Notice that encfs asks for two inputs,the first input is either an "x" or a "p" and the second one is the password. Not getting these two requests could only be caused by an internal error in encfs in whatever version of debian this problem is in or maybe a new build time configuration option or a debian specific patch or something else completely that changes the behavior of encfs.
Hi, this clearly is a bug in cryptkeeper.
Debian, as of release 1.9.1-3, has applied the following bugfix commit from upstream encfs: vgough/encfs@c3a7da5
Cryptkeeper assumed that encfs -S is a stable way to manipulate encfs, which it is not.
You are not seeing this behavior on your system because your distribution has not pulled this upstream bug fix. As soon as a new encfs release comes out, we will see cryptkeeper fail on all major distributions (e.g., Fedora has decided to wait for a new upstream release: https://bugzilla.redhat.com/show_bug.cgi?id=1390107)
This does not make me happy.
I have a project called SiriKali,its in debian and it interfaces with encfs the exact same way cryptkeeper does it and hence its broken the same exact way.
It is not cool to break interfaces that has been working FOR YEARS and then blame others who depend on those interface.
What documentation made you think this way?
The documentation for "-S" here creates no such impression.
The only thing i can do here is disabling encfs volume creation in SiriKali since i can no longer trust it. Atleast i have words from other projects that they care about backward compatibility and they will not change their API as carelessly as what encfs is doing here.
EncFS co-maintainer here. Looks like vgough/encfs@c3a7da5 should be reverted as it is an unintentional ABI change. No question about that.
However, please note that "-S" has never been meant to be used when creating a filesystem. From man 1 encfs:
Since when is piping something in stdin an API or ABI? This is a UI and was never meant to be used by other programs in this way.
But I must say that the different behavior depending on the existence of the filesystem is not that great (although there's a warning in the manual).
FYI - @rfjakob , a Debian bug report on Encfs:
@rfjakob Here the Debian maintainer.
What's your proposal on vgough/encfs@c3a7da5 ? Simply reverting will probably reintroduce the issue that it was trying to fix. I cannot see any other suggestion or pending pull-request anywhere.
BTW, not sure I need to feel bad or sorry here because otherwise that issue would probably slip under the radar right into the next official release.
added a commit
Feb 6, 2017
This was referenced
Feb 9, 2017
// , Is there anything we can do about this issue?
Has anyone forked cryptkeeper?
The immediate problem with encfs has been addressed.