On 05/21 08:41, Ian Zimmerman wrote:
> On 2017-05-21 09:51, Neil Bothwick wrote:
>
> > Why are you using encfs with the associated FUSE baggage when ecryptfs
> > is in the kernel and performs the same function?
>
> Is ecryptfs behind the scenes when I run /sbin/cryptsetup ?
>
> I remember a few years back, still on debian, I resolved to replace my
> encfs usage with something more "modern" (phew) just to avoid getting
> left in the cold with no support, as may be happening to Meino. The
> first such modern thing that came to mind was what ubuntu (and maybe
> debian) used to mount encrypted filesystems on boot, and I think that
> was called ecryptfs, but that was so very complex and opaque that I
> didn't get far. After a while I found my current way usign cryptsetup.
>
> But the ubuntu stuff may have been just wrapping and packaging, hence
> my question.
>
> --
> Please *no* private Cc: on mailing lists and newsgroups
> Personal signed mail: please _encrypt_ and sign
> Don't clear-text sign:
> http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html
>
Hi Ian,
cryptsetup seems to be of another flavor than encfs, since its depends
on gpg (see below), which encfs does not use as far as I know.
I think encfs uses symmetric ciphers and cryptsetup uses a pub/private
key pair. But I am by no means a cryptologist (I even cant spell this
correctly...or...? ;)
>ldd /sbin/cryptsetup
linux-vdso.so.1 (0x00007ffd15560000)
libcryptsetup.so.4 => /usr/lib64/libcryptsetup.so.4 (0x00007fba2aa06000)
libpopt.so.0 => /usr/lib64/libpopt.so.0 (0x00007fba2a7f9000)
libc.so.6 => /lib64/libc.so.6 (0x00007fba2a463000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fba2a25e000)
libdevmapper.so.1.02 => /lib64/libdevmapper.so.1.02 (0x00007fba2a004000)
libgcrypt.so.20 => /usr/lib64/libgcrypt.so.20 (0x00007fba29cf1000)
libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007fba29adb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fba2ac2f000)
librt.so.1 => /lib64/librt.so.1 (0x00007fba298d3000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007fba296ad000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fba29491000)
libm.so.6 => /lib64/libm.so.6 (0x00007fba2918d000)
---
The encfs, which segfaults, was of version 1.9.1.
In parallel I searched the internet on "seqfault encfs"
and found quite a few people experience similiar problems.
Due to that reports I downgraded to version 1.7.5 and no
problems so far.
Smells like openssl: It's secure...but...
Time will tell, whether 1.7.5. is more stable than the
newer versions.
Cheers
Meino
