Hi,
On Mon, Apr 27, 2020 at 9:21 AM Daniel Lange 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
