Hi, On Mon, Apr 27, 2020 at 9:21 AM Daniel Lange <dla...@debian.org> wrote: > we have the issue that eCryptfs has not made it into Buster and has > fallen out of testing due to bug #765854. Indeed, it hurts our users. :(
> To me it seems the most easy solution is from > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765854#107 > as non-interactive logins don't have any passphrase to unlock an > encrypted home dir anyways. I've updated packaging[1] and my testing shows it works now. > Additionally we have #936465 now (Python2 dependency). > This is tracked upstream at > https://bugs.launchpad.net/ecryptfs/+bug/1871236 Sorry, the Python 2 part is going to be removed. As I see, no plans to make it work with Python 3. > So questions: > > @Martin, Dustin: > Is there still upstream support for eCryptfs? > I.e. will you resolve the LP bug linked above? I may think there's no more development of eCryptfs. I don't know alternatives at the moment. > libecryptfs.py is just a SWIG generated wrapper. > So this probably trivial. But somebody that actually uses the > python-bindings would be needed to test. Do you know use cases for the Python wrapper? > @Laszlo, Julian: > Do we want to get eCryptfs back into Bullseye so Stretch users can > upgrade there (or may be document a work-around with testing packages, > or we do a stable update for these folks)? > I'd really like to offer a solution to users of eCryptfs in Debian. I don't think it can be reintroduced to stable, but backports would be possible. First if you can, please test the new package revision and report back how it works. Regards, Laszlo/GCS [1] dget -x https://people.debian.org/~gcs/ecryptfs-utils_111-5.dsc
