Debian Bug report logs - #852751
[cryptkeeper] Sets the same password "p" for everything independently of user input

Toggle useless messages

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\n", 2);
//write (fd[1], "y\n", 2);
write (fd[1], "p\n", 2);
write (fd[1], password, strlen (password));
write (fd[1], "\n", 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\n", 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\n" 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.

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

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

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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

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)

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

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

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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

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

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

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

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

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

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

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

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

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

[Message part 1 (text/plain, inline)]

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.

[signature.asc (application/pgp-signature, inline)]

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

[Message part 1 (text/plain, inline)]

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.

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.