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,
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.
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
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
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
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
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
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.
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.
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
Package: cryptkeeper
Version: 0.9.5-5.1
Severity: critical
Tags: security
X-Debbugs-CC: secure-testing-t...@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
11 matches
Mail list logo
