Debian Bug report logs - #852751

[cryptkeeper] Sets the same password "p" for everything independently of user input

Reported by: Kirill Tkhai <ktkhai@virtuozzo.com> Date: Thu, 26 Jan 2017 23:30:02 UTC Severity: critical Tags: confirmed, security, sid, stretch Found in version cryptkeeper/0.9.5-5.1 Fixed in version 0.9.5-5.1+rm Done: Debian FTP Masters <ftpmaster@ftp-master.debian.org> Bug is archived. No further changes may be made. Forwarded to https://github.com/tomm/cryptkeeper/issues/23

Toggle useless messages

Report forwarded to debian-bugs-dist@lists.debian.org, secure-testing-team@lists.alioth.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Thu, 26 Jan 2017 23:30:04 GMT) (full text, mbox, link).

Acknowledgement sent to Kirill Tkhai <ktkhai@virtuozzo.com> :

New Bug report received and forwarded. Copy sent to secure-testing-team@lists.alioth.debian.org, Francesco Namuri <francesco@namuri.it> . (Thu, 26 Jan 2017 23:30:04 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Kirill Tkhai <ktkhai@virtuozzo.com> To: <submit@bugs.debian.org> Subject: [cryptkeeper] Sets the same password "p" for everything independently of user input Date: Fri, 27 Jan 2017 02:27:31 +0300

Package: cryptkeeper Version: 0.9.5-5.1 Severity: critical Tags: security X-Debbugs-CC: secure-testing-team@lists.alioth.debian.org Hello, guys, today I tried to use cryptkeeper in the first time. I created a new encrypted folder by wizzard, and copied my data into the folder in Nautilus. Then I umounted the folder. But later, when I mounted it once again, cryptkeeper said the password is wrong (though, I 100% know, it's true!). I've looked into cryptkeeper code and found, it calls encfs with -S option: execlp ("encfs", "encfs", "-S", crypt_dir, mount_dir, NULL); exit (0); While the password is passed to encfs using pipe in this way: // paranoid default setup mode //write (fd[1], "y

", 2); //write (fd[1], "y

", 2); write (fd[1], "p

", 2); write (fd[1], password, strlen (password)); write (fd[1], "

", 1); But it seems it's wrong. When I'm executing encfs program from console $ encfs -S crypt_dir mount_dir and I'm passing "p

", encfs exits and doesn't wait for a password itself. I do not know, who is blame, cryptkeeper or encfs, and even nothing about if the interface above exists ("p

" before the password). But decrypting using "p" password works for any encrypted directory, created using cryptkeeper. This obviously mustn't work such way. Kirill --- System information. --- Architecture: Kernel: Linux 4.9.3+ Debian Release: 9.0 500 unstable ftp.ru.debian.org 500 testing ftp.ru.debian.org 500 stable-updates ftp.ru.debian.org 500 stable security.debian.org 500 stable ftp.ru.debian.org 1 experimental ftp.ru.debian.org --- Package information. --- Depends (Version) | Installed ===================================-+-============= gconf-service | 3.2.6-4 libatk1.0-0 (>= 1.12.4) | 2.22.0-1 libc6 (>= 2.4) | libcairo2 (>= 1.2.4) | libfontconfig1 (>= 2.9.0) | libfreetype6 (>= 2.2.1) | libgcc1 (>= 1:4.1.1) | libgconf-2-4 (>= 2.31.1) | libgdk-pixbuf2.0-0 (>= 2.22.0) | libglib2.0-0 (>= 2.16.0) | libgtk2.0-0 (>= 2.10.0) | libpango1.0-0 (>= 1.14.0) | libstdc++6 (>= 4.1.1) | libx11-6 | zenity | fuse | encfs | Package's Recommends field is empty. Package's Suggests field is empty.

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Sat, 28 Jan 2017 15:39:05 GMT) (full text, mbox, link).

Acknowledgement sent to Simon McVittie <smcv@debian.org> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Sat, 28 Jan 2017 15:39:05 GMT) (full text, mbox, link).

Message #10 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org> To: Kirill Tkhai <ktkhai@virtuozzo.com>, 852751@bugs.debian.org Cc: secure-testing-team@lists.alioth.debian.org Subject: Re: Bug#852751: [cryptkeeper] Sets the same password "p" for everything independently of user input Date: Sat, 28 Jan 2017 15:34:42 +0000

Control: tags 852751 + stretch sid confirmed On Fri, 27 Jan 2017 at 02:27:31 +0300, Kirill Tkhai wrote: > today I tried to use cryptkeeper in the first time. I created > a new encrypted folder by wizzard, and copied my data into > the folder in Nautilus. ... > decrypting using "p" password works for any encrypted directory, > created using cryptkeeper. This obviously mustn't work such way. I can confirm this bug in a stretch virtual machine, but not in a jessie virtual machine. I'm assuming it applies to sid too. Steps to reproduce: * install gnome-session-flashback, lightdm, cryptkeeper, xterm * log in to GNOME Flashback session * Accessories -> System Tools -> Cryptkeeper * right-click the key icon that appears * New encrypted folder * enter name "secrets" * select home directory as its location * click Forward * enter some password other than "p", twice * click Forward * open the xterm * fusermount -u ~/secrets * encfs ~/.secrets_encfs ~/secrets * when prompted for "EncFS Password:" enter the correct password - good result: ~/secrets mounts successfully - bad result: password rejected * fusermount -u ~/secrets * encfs ~/.secrets_encfs ~/secrets * when prompted for "EncFS Password:" enter "p" - good result: password rejected - bad result: ~/secrets mounts successfully It looks as though cryptkeeper makes assumptions about encfs' command-line interface that are no longer valid. I also notice that cryptkeeper does not check what write() and close() return during its interactions with encfs, which seems very likely to lead to undesired results. I have recommended that the release team remove this package from stretch: it currently gives a false sense of security that is worse than not encrypting at all. Regards, smcv assisting the Cambridge BSP -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/3 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cryptkeeper depends on: ii encfs 1.9.1-3 ii fuse 2.9.7-1 ii gconf-service 3.2.6-4 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-8 ii libcairo2 1.14.8-1 ii libfontconfig1 2.11.0-6.7 ii libfreetype6 2.6.3-3+b1 ii libgcc1 1:6.2.1-5 ii libgconf-2-4 3.2.6-4 ii libgdk-pixbuf2.0-0 2.36.3-1 ii libglib2.0-0 2.50.2-2 ii libgtk2.0-0 2.24.31-1 ii libpango1.0-0 1.40.3-3 ii libstdc++6 6.2.1-5 ii libx11-6 2:1.6.4-2 ii zenity 3.22.0-1 cryptkeeper recommends no packages. cryptkeeper suggests no packages. -- no debconf information

Added tag(s) confirmed, sid, and stretch. Request was from Simon McVittie <smcv@debian.org> to 852751-submit@bugs.debian.org . (Sat, 28 Jan 2017 15:39:05 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Mon, 30 Jan 2017 17:21:06 GMT) (full text, mbox, link).

Acknowledgement sent to Daniel Moerner <dmoerner@gmail.com> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Mon, 30 Jan 2017 17:21:06 GMT) (full text, mbox, link).

Message #17 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Daniel Moerner <dmoerner@gmail.com> To: 852751@bugs.debian.org Cc: ktkhai@virtuozzo.com Subject: Re: Bug#852751: [cryptkeeper] Sets the same password "p" for everything independently of user input Date: Mon, 30 Jan 2017 12:20:12 -0500

Control: forwarded 852751 https://github.com/tomm/cryptkeeper/issues/23 Forwarded this upstream, but it seems basically dead. Fortunately, cryptkeeper was removed from Testing already (https://github.com/tomm/cryptkeeper/issues/23), perhaps it should just be removed from Debian altogether. Daniel

Set Bug forwarded-to-address to 'https://github.com/tomm/cryptkeeper/issues/23'. Request was from Daniel Moerner <dmoerner@gmail.com> to 852751-submit@bugs.debian.org . (Mon, 30 Jan 2017 17:21:06 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Tue, 31 Jan 2017 00:39:05 GMT) (full text, mbox, link).

Acknowledgement sent to Daniel Moerner <dmoerner@gmail.com> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Tue, 31 Jan 2017 00:39:05 GMT) (full text, mbox, link).

Message #24 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Daniel Moerner <dmoerner@gmail.com> To: 852751@bugs.debian.org Cc: blade@debian.org Subject: Re: Bug#852751: [cryptkeeper] Sets the same password "p" for everything independently of user input Date: Mon, 30 Jan 2017 19:35:14 -0500

Hi, The source of this bug is this upstream commit to encfs, which defaults to Config_Standard in the context in which cryptkeeper is trying to call encfs. Debian has applied this commit to encfs in the 1.9.1-3 release of encfs. https://github.com/vgough/encfs/commit/c3a7da5eff4055e77dc9404b0c15945485232bf2 The situation is then that cryptkeeper is no longer maintained upstream, and is assuming a certain behavior of encfs which is no longer valid. Daniel

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Tue, 31 Jan 2017 06:12:02 GMT) (full text, mbox, link).

Acknowledgement sent to Francesco Namuri <franam@hierax.net> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Tue, 31 Jan 2017 06:12:02 GMT) (full text, mbox, link).

Message #29 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Francesco Namuri <franam@hierax.net> To: Daniel Moerner <dmoerner@gmail.com>, 852751@bugs.debian.org Cc: blade@debian.org Subject: Re: Bug#852751: [cryptkeeper] Sets the same password "p" for everything independently of user input Date: Tue, 31 Jan 2017 07:02:13 +0100

Hello, thanks for the report, it wasn't necessary, but me too, I can confirm this behaviour. I'm sorry, but I wasn't using cryptkeeper for a while and I never noticed this bug. Due to the gravity of this bug I agree to request the removal of the package. Cheers, Francesco

Reply sent to Debian FTP Masters <ftpmaster@ftp-master.debian.org> :

You have taken responsibility. (Tue, 31 Jan 2017 13:09:17 GMT) (full text, mbox, link).

Notification sent to Kirill Tkhai <ktkhai@virtuozzo.com> :

Bug acknowledged by developer. (Tue, 31 Jan 2017 13:09:17 GMT) (full text, mbox, link).

Message #34 received at 852751-done@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org> To: 528000-done@bugs.debian.org,664599-done@bugs.debian.org,710692-done@bugs.debian.org,724022-done@bugs.debian.org,729727-done@bugs.debian.org,852751-done@bugs.debian.org, Cc: cryptkeeper@packages.debian.org, cryptkeeper@packages.qa.debian.org Subject: Bug#853725: Removed package(s) from unstable Date: Tue, 31 Jan 2017 13:06:08 +0000

Version: 0.9.5-5.1+rm Dear submitter, as the package cryptkeeper has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/853725 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Scott Kitterman (the ftpmaster behind the curtain)

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Tue, 31 Jan 2017 13:36:02 GMT) (full text, mbox, link).

Acknowledgement sent to Michael Stone <mstone@debian.org> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Tue, 31 Jan 2017 13:36:03 GMT) (full text, mbox, link).

Message #39 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org> To: 852751@bugs.debian.org Cc: franam@hierax.net, blade@debian.org Subject: Re: Bug#852751: [cryptkeeper] Sets the same password "p" for everything independently of user input Date: Tue, 31 Jan 2017 08:23:51 -0500

If I'm understanding this correctly, removing the package simply guarantees that people upgrading from jessie will have an instance that simply stops working properly? Is it possible to upload a version that remove the create functionality but lets people mount existing encrypted directories (which seems to be working?) and explains the situation in the README? Mike Stone

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Tue, 31 Jan 2017 16:03:07 GMT) (full text, mbox, link).

Acknowledgement sent to Alex Warhawk <w4rh4wk@bluephoenix.at> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Tue, 31 Jan 2017 16:03:08 GMT) (full text, mbox, link).

Message #44 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Alex Warhawk <w4rh4wk@bluephoenix.at> To: 852751@bugs.debian.org Subject: Setup vs. Unlocking Procedure Date: Tue, 31 Jan 2017 16:53:25 +0100

Having used Encfs in the past, and from glancing over this bug, it comes to my mind that there may be an issue in the setup / unlock process. Typically, when creating a new encfs setup, encfs asks for default or paranoid settings. The user can then type in "p" to choose paranoid settings. Maybe (wild guess) this setup logic got somehow mixed up with the unlocking procedure. - Alex

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Tue, 31 Jan 2017 16:21:07 GMT) (full text, mbox, link).

Acknowledgement sent to Francesco Namuri <franam@hierax.net> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Tue, 31 Jan 2017 16:21:07 GMT) (full text, mbox, link).

Message #49 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Francesco Namuri <franam@hierax.net> To: Michael Stone <mstone@debian.org> Cc: 852751@bugs.debian.org, blade@debian.org Subject: Re: Bug#852751: [cryptkeeper] Sets the same password "p" for everything independently of user input Date: Tue, 31 Jan 2017 17:17:44 +0100

On 31/01/2017 14:23, Michael Stone wrote: > If I'm understanding this correctly, removing the package simply > guarantees that people upgrading from jessie will have an instance > that simply stops working properly? Is it possible to upload a version > that remove the create functionality but lets people mount existing > encrypted directories (which seems to be working?) and explains the > situation in the README? > > Mike Stone Hello Mike, of course we can remove it only from the upcoming stable release, and removing it from testing already done it. ftpmaster also removed it from unstable. We asked also the removal from unstable due the gravity of the bug. I'd like to point that the problem only affects encrypted directories made using cryptkeeper, and that the problems it's easily discovered first time the user tries to mount the partition. Having said this, the issue still remains a huge, and I hope that nobody lost any kind of data. Cheers, Francesco

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Tue, 31 Jan 2017 16:27:04 GMT) (full text, mbox, link).

Acknowledgement sent to Francesco Namuri <franam@hierax.net> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Tue, 31 Jan 2017 16:27:04 GMT) (full text, mbox, link).

Message #54 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Francesco Namuri <franam@hierax.net> To: Alex Warhawk <w4rh4wk@bluephoenix.at>, 852751@bugs.debian.org Subject: Re: Bug#852751: Setup vs. Unlocking Procedure Date: Tue, 31 Jan 2017 17:22:12 +0100

On 31/01/2017 16:53, Alex Warhawk wrote: > Having used Encfs in the past, and from glancing over this bug, > it comes to my mind that there may be an issue in the setup / unlock > process. > > Typically, when creating a new encfs setup, encfs asks for default or > paranoid > settings. The user can then type in "p" to choose paranoid settings. > > Maybe (wild guess) this setup logic got somehow mixed up with the > unlocking > procedure. > > - Alex Hello Alex, yes, this is the problem. Look at: https://github.com/tomm/cryptkeeper/issues/23 Francesco

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Tue, 31 Jan 2017 16:33:07 GMT) (full text, mbox, link).

Acknowledgement sent to Michael Stone <mstone@debian.org> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Tue, 31 Jan 2017 16:33:07 GMT) (full text, mbox, link).

Message #59 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org> To: Francesco Namuri <franam@hierax.net> Cc: 852751@bugs.debian.org, blade@debian.org Subject: Re: Bug#852751: [cryptkeeper] Sets the same password "p" for everything independently of user input Date: Tue, 31 Jan 2017 11:30:46 -0500

On Tue, Jan 31, 2017 at 05:17:44PM +0100, Francesco Namuri wrote: >of course we can remove it only from the upcoming stable release, >and removing it from testing already done it. ftpmaster also removed >it from unstable. > >We asked also the removal from unstable due the gravity of the bug. > >I'd like to point that the problem only affects encrypted directories >made using cryptkeeper, and that the problems it's easily discovered >first time the user tries to mount the partition. Yes, I agree that it's easily discoverable--which is why I'm concerned that simply removing the entire functionality of the package without any kind of notification to the user isn't the best way to address the problem. Again: removing the package simply ensures that people upgrading to stretch will either end up with a cryptkeeper package that exhibits this bug, or will remove their cryptkeeper package and not know how to access their stored data, right? Mike Stone

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Tue, 31 Jan 2017 17:09:05 GMT) (full text, mbox, link).

Acknowledgement sent to Francesco Namuri <franam@hierax.net> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Tue, 31 Jan 2017 17:09:05 GMT) (full text, mbox, link).

Message #64 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Francesco Namuri <franam@hierax.net> To: Michael Stone <mstone@debian.org>, 852751@bugs.debian.org Cc: blade@debian.org Subject: Re: Bug#852751: [cryptkeeper] Sets the same password "p" for everything independently of user input Date: Tue, 31 Jan 2017 18:06:01 +0100

On 31/01/2017 17:30, Michael Stone wrote: > On Tue, Jan 31, 2017 at 05:17:44PM +0100, Francesco Namuri wrote: >> of course we can remove it only from the upcoming stable release, >> and removing it from testing already done it. ftpmaster also removed >> it from unstable. >> >> We asked also the removal from unstable due the gravity of the bug. >> >> I'd like to point that the problem only affects encrypted directories >> made using cryptkeeper, and that the problems it's easily discovered >> first time the user tries to mount the partition. > > Yes, I agree that it's easily discoverable--which is why I'm concerned > that simply removing the entire functionality of the package without > any kind of notification to the user isn't the best way to address the > problem. Again: removing the package simply ensures that people > upgrading to stretch will either end up with a cryptkeeper package > that exhibits this bug, or will remove their cryptkeeper package and > not know how to access their stored data, right? > > Mike Stone Hello Mike, thanks for the comments. This issue only affectes the cryptkeeper working with encfs 1.9.1-3, in stable we have 1.7.4-5 that works as cryptkeeper expects. People that upgrades from jessie to stretch simple "loses" cryptkeeper, package, of course they are still able to access their stored data using encfs or any other frontend to it. IMHO it's better to remove the program in any envrionment that is affected by this issue, putting a note in the README or also on the debconf isn't enough to balance the gravity of the issue. Users can think they lost data because of a wrong password, or even worst they can trust on a worthless data encryption. Francesco

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Tue, 31 Jan 2017 18:48:02 GMT) (full text, mbox, link).

Acknowledgement sent to ".. ink .." <mhogomchungu@gmail.com> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Tue, 31 Jan 2017 18:48:02 GMT) (full text, mbox, link).

Message #69 received at 852751@bugs.debian.org (full text, mbox, reply):

From: ".. ink .." <mhogomchungu@gmail.com> To: 852751@bugs.debian.org Subject: Why not fix buggy encfs behavior? Date: Tue, 31 Jan 2017 21:43:34 +0300

Greetings,i am a current maintainer of a project called "SiriKali"[1][4] and it is also affected[2] by this bug in encfs. encfs upstream has said that this "new" behavior of encfs is a bug that needs to be fixed[3]. Why not fix this buggy encfs behavior and let cryptkeeper among other front ends to encfs continue to work as expected? This bug is not in cryptkeeper,its in encfs and continuing with this buggy behavior of encfs will break a lot more projects than SiriKali and cryptkeeper and will cause encfs in debian to behave differently from everybody else when upstream release a new version that does not have this behavior. I think cryptkeeper should be left alone and focus be redirected to the change in encfs behavior that upstream now disagrees with that started all this. [1] https://mhogomchungu.github.io/sirikali/ [2] https://github.com/tomm/cryptkeeper/issues/23#issuecomment-276288921 [3] https://github.com/tomm/cryptkeeper/issues/23#issuecomment-276304206 [4] https://packages.debian.org/sid/sirikali

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Tue, 31 Jan 2017 22:24:07 GMT) (full text, mbox, link).

Acknowledgement sent to Francesco Namuri <franam@hierax.net> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Tue, 31 Jan 2017 22:24:07 GMT) (full text, mbox, link).

Message #74 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Francesco Namuri <franam@hierax.net> To: ".. ink .." <mhogomchungu@gmail.com>, 852751@bugs.debian.org Subject: Re: Bug#852751: Why not fix buggy encfs behavior? Date: Tue, 31 Jan 2017 23:22:31 +0100

On 31/01/2017 19:43, .. ink .. wrote: > Greetings,i am a current maintainer of a project called > "SiriKali"[1][4] and it is also affected[2] by this bug in encfs. > > encfs upstream has said that this "new" behavior of encfs is a bug > that needs to be fixed[3]. Why not fix this > buggy encfs behavior and let cryptkeeper among other front ends to > encfs continue to work as expected? > > This bug is not in cryptkeeper,its in encfs and continuing with this > buggy behavior of encfs will break a lot more > projects than SiriKali and cryptkeeper and will cause encfs in debian > to behave differently from everybody else when > upstream release a new version that does not have this behavior. > > I think cryptkeeper should be left alone and focus be redirected to > the change in encfs behavior that upstream now > disagrees with that started all this. > > [1] https://mhogomchungu.github.io/sirikali/ > [2] > https://github.com/tomm/cryptkeeper/issues/23#issuecomment-276288921 > [3] > https://github.com/tomm/cryptkeeper/issues/23#issuecomment-276304206 > [4] https://packages.debian.org/sid/sirikali Hello, thanks for the comment. Maybe a better solution could be to check output of encfs before piping anything, or maybe, we can do a mount result check to see if all worked fine; but we can't send "p" command trusting that encfs is waiting for a choice between "p" and "x". This is my humble opinion. Cheers, Francesco

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Wed, 01 Feb 2017 04:15:03 GMT) (full text, mbox, link).

Acknowledgement sent to Tony Sultana <chaz.anton@gmail.com> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Wed, 01 Feb 2017 04:15:03 GMT) (full text, mbox, link).

Message #79 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Tony Sultana <chaz.anton@gmail.com> To: 852751@bugs.debian.org Subject: Fix buggy encfs behavior Date: Tue, 31 Jan 2017 21:10:56 -0700

I agree with fixing the buggy behavior in encfs. I created an encfs paranoid folder and use cryptkeeper to open it without issues in Stretch. If someone creates one through cryptkeeper they will discover the problem quickly. That being said, I agree having a program with known bad behavior (cryptkeeper) is not preferred but the cause appears to come from another application. Tony

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Wed, 01 Feb 2017 10:57:05 GMT) (full text, mbox, link).

Acknowledgement sent to ".. ink .." <mhogomchungu@gmail.com> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Wed, 01 Feb 2017 10:57:05 GMT) (full text, mbox, link).

Message #84 received at 852751@bugs.debian.org (full text, mbox, reply):

From: ".. ink .." <mhogomchungu@gmail.com> To: 852751@bugs.debian.org Subject: Not possible to select expert mode when creating a new volume Date: Wed, 1 Feb 2017 13:54:33 +0300

I played around a bit with the encfs that has the new behavior and noticed that its now NOT possible to ask it to take the expert mode path because it automatically selects the standard configuration mode. I looked up documentations for encfs[1] and i did not find any command line argument to ask encfs select expert mode. The new behavior effectively removed the expert mode option. [1] https://linux.die.net/man/1/encfs

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Wed, 01 Feb 2017 22:57:03 GMT) (full text, mbox, link).

Acknowledgement sent to Eduard Bloch <edi@gmx.de> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Wed, 01 Feb 2017 22:57:03 GMT) (full text, mbox, link).

Message #89 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Eduard Bloch <edi@gmx.de> To: Francesco Namuri <franam@hierax.net> Cc: Michael Stone <mstone@debian.org>, 852751@bugs.debian.org Subject: Re: Bug#852751: [cryptkeeper] Sets the same password "p" for everything independently of user input Date: Wed, 1 Feb 2017 23:52:38 +0100

Hallo, * Francesco Namuri [Tue, Jan 31 2017, 06:06:01PM]: > > Yes, I agree that it's easily discoverable--which is why I'm concerned > > that simply removing the entire functionality of the package without > > any kind of notification to the user isn't the best way to address the > > problem. Again: removing the package simply ensures that people > > upgrading to stretch will either end up with a cryptkeeper package > > that exhibits this bug, or will remove their cryptkeeper package and > > not know how to access their stored data, right? > > > > Mike Stone > > Hello Mike, > thanks for the comments. > > This issue only affectes the cryptkeeper working with encfs 1.9.1-3, in > stable we have 1.7.4-5 that works as cryptkeeper expects. > > People that upgrades from jessie to stretch simple "loses" cryptkeeper, > package, of course they are still able to access their stored data using > encfs or any other frontend to it. > > IMHO it's better to remove the program in any envrionment that is affected > by this issue, putting a note in the README or also on the debconf isn't > enough to balance the gravity of the issue. Users can think they lost data > because of a wrong password, or even worst they can trust on a worthless > data encryption. Also many thanks from my side... So I guess I better upload an encfs package which simply conflicts with cryptkeeper or does anyone have a better idea? Best Regards, Eduard.

Information forwarded to debian-bugs-dist@lists.debian.org, Francesco Namuri <francesco@namuri.it> :

Bug#852751 ; Package cryptkeeper . (Fri, 03 Feb 2017 17:21:02 GMT) (full text, mbox, link).

Acknowledgement sent to Tony Sultana <chaz.anton@gmail.com> :

Extra info received and forwarded to list. Copy sent to Francesco Namuri <francesco@namuri.it> . (Fri, 03 Feb 2017 17:21:02 GMT) (full text, mbox, link).

Message #94 received at 852751@bugs.debian.org (full text, mbox, reply):

From: Tony Sultana <chaz.anton@gmail.com> To: Eduard Bloch <edi@gmx.de>,852751@bugs.debian.org Cc: Francesco Namuri <franam@hierax.net>,Michael Stone <mstone@debian.org> Subject: Re: Bug#852751: [cryptkeeper] Sets the same password "p" for everything independently of user input Date: Fri, 03 Feb 2017 10:19:59 -0700

Will a conflict encfs still permit use of cryptkeeper with existing encfs folders? If yes, then that may be a good approach. Another approach, probably out of scope, would be to disable New Folder functionality in cryptkeeper and instruct users to the shell with encfs.⁣ Tony On Feb 1, 2017, 3:57 PM, at 3:57 PM, Eduard Bloch <edi@gmx.de> wrote: >Hallo, >* Francesco Namuri [Tue, Jan 31 2017, 06:06:01PM]: > >> > Yes, I agree that it's easily discoverable--which is why I'm >concerned >> > that simply removing the entire functionality of the package >without >> > any kind of notification to the user isn't the best way to address >the >> > problem. Again: removing the package simply ensures that people >> > upgrading to stretch will either end up with a cryptkeeper package >> > that exhibits this bug, or will remove their cryptkeeper package >and >> > not know how to access their stored data, right? >> > >> > Mike Stone >> >> Hello Mike, >> thanks for the comments. >> >> This issue only affectes the cryptkeeper working with encfs 1.9.1-3, >in >> stable we have 1.7.4-5 that works as cryptkeeper expects. >> >> People that upgrades from jessie to stretch simple "loses" >cryptkeeper, >> package, of course they are still able to access their stored data >using >> encfs or any other frontend to it. >> >> IMHO it's better to remove the program in any envrionment that is >affected >> by this issue, putting a note in the README or also on the debconf >isn't >> enough to balance the gravity of the issue. Users can think they lost >data >> because of a wrong password, or even worst they can trust on a >worthless >> data encryption. > >Also many thanks from my side... > >So I guess I better upload an encfs package which simply conflicts with >cryptkeeper or does anyone have a better idea? > >Best Regards, >Eduard.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org . (Sat, 04 Mar 2017 07:32:33 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.