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 <e...@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.
