Ubuntu

libecryptfs_key_mod_openssl.so does not exist in ecryptfs-utils

Reported by dinexi on 2011-03-23
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)
High
Dustin Kirkland 

Bug Description

Man reads:
              Parameters that apply to individual key modules have the alias
              for the key module in the prefix of the parameter name. Key
              modules are pluggable, and which key modules are available on
              any given system is dependent upon whatever happens to be
              installed in /usr/lib*/ecryptfs/. By default, this includes, at
              a minimum, "passphrase" and "openssl."

Great. I have done `sudo aptitude install ecryptfs-utils libecryptfs-dev libecryptfs0` and ran `ls /usr/lib*/ecryptfs/` and what I see?

[stanis@dinexi ~] % ls /usr/lib*/ecryptfs/ [5:20:39]
/usr/lib64/ecryptfs/:
libecryptfs_key_mod_passphrase.so

/usr/lib/ecryptfs/:
libecryptfs_key_mod_passphrase.so

I see the passphrase here. I don't see openssl, which, as the man states, should be available "at a minimum". Why?

Related branches

dinexi (im-dinexi) wrote :

Also I have checked that in maverick amd64. The same.

dinexi (im-dinexi) on 2011-03-23
summary: - libecryptfs_key_mod_openssl.so does not exists in ecryptfs-utils
+ libecryptfs_key_mod_openssl.so does not exist in ecryptfs-utils
tags: added: ecryptfs man
Andreas Moog (amoog) on 2011-03-24
affects: ubuntu → ecryptfs-utils (Ubuntu)
Dustin Kirkland  (kirkland) wrote :

Unfortunately, we're not building ecryptfs against ssl at this time, due to license incompatibilities (as noted below). I'm going to leave this bug open, though, and try and get those sorted out.

ecryptfs-utils (66-2) unstable; urgency=low

  * Removing auth-client-config support, no longer used.
  * Adding ecryptfs-utils recommends to keyutils.
  * Building without ssl, ecryptfs_key_mod_openssl.c has incompatible
    license (GPL-2+).
  * Building without pkcs11 helper, ecryptfs_key_mod_pkcs11_helper.c
    links against openssl and has incompatible license (GPL-2+).
  * Building without pkcs11 helper, ecryptfs_key_mod_tspi.c links
    against openssl and has incompatible license (GPL-2+).

 -- Daniel Baumann <email address hidden> Tue, 18 Nov 2008 20:02:00 +0100

Changed in ecryptfs-utils (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in ecryptfs-utils (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Dustin Kirkland (kirkland)
Changed in ecryptfs-utils (Ubuntu):
status: In Progress → Fix Committed
Redsandro (redsandro) wrote :

How would I go about getting this committed fix or compiling
/usr/lib/ecryptfs/libecryptfs_key_mod_openssl.so myself?

There's not much information to be duckduckgo'ed about this, but I'd like to implement this module.

Tyler Hicks (tyhicks) wrote :

The fix is already committed and the module is already implemented.

You can build ecryptfs-utils from source. Pass --enable-openssl to ./configure to be sure that the OpenSSL module will be built. Then, copy the the key module to the appropriate place in /usr/lib.

I'm intentionally being vague with the instructions because I really don't want a lot of people to do this. It is sparingly tested, not supported, and you'll probably run into a handful of bugs. I don't recommend it at this time.

Redsandro (redsandro) wrote :

We're at 12.10 now. However, the module that should, according to the manual, be available "at a minimum", still hasn't made it to the main release.

Any comments about the stability and the chances of seeing this in this or the next release?

Redsandro (redsandro) wrote :

PS adding ppa:ecryptfs/ppa results in 404s, e.g.:
W: Failed to fetch http://ppa.launchpad.net/ecryptfs/ppa/ubuntu/dists/quantal/main/binary-amd64/Packages 404 Not Found

On 2012-12-13 14:01:50, Redsandro wrote:
> We're at 12.10 now. However, the module that should, according to the
> manual, be available "at a minimum", still hasn't made it to the main
> release.

Which man page? I don't see that stated in any of the 12.10 man pages.

> Any comments about the stability and the chances of seeing this in this
> or the next release?

Unfortunately, there are no plans to improve this feature in the near
term. It is a considerable amount of work, yet no developers have shown
interest in the feature.

Redsandro (redsandro) wrote :

Thanks for the reply.

> Which man page? I don't see that stated in any of the 12.10 man pages.

Sorry, I played with this at home (12.10) but I am at an old version (at work) now. :P I just assumed the manual was the same as here.

It's too bad there is little to no interest. Ecryptfs is really great technology. I am using it for encrypting mountable OTFE remote backups, and I like to use a simple password at the safe local site, yet have strong key based encryption on the files. Because, as the ecryptfs manual puts it (or used to put it): Cryptographic keys derived from passphrases are generally worthless.

It could be that I am using ecryptfs in a silly way, because otherwise, given the popularity of key+password based ssh login to servers for maintenance, one would think that typical devs would actually prefer keys over passwords.

Am I missing a trick? Is it possible to use a crazy password and store it in your keyring permanently so the ecryptfs will mount without a password dialog when logged in and keyring opened?

Redsandro (redsandro) wrote :

PS - I think ecryptfs-manager does exactly that - setting up passwordless mounting. But the 'kernel keyring' concept of ecryptfs-manager, as opposed to 'user keyring' scared me away of using it. I want to keep keys and secrets within my user, not something system-wide. But I guess terminology on this is not my strongsuit.

Redsandro (redsandro) wrote :

I just noticed that the ecryptfs manual itself still mentions the optional key that was removed from the ecryptfs-utils manual:

       openssl_keyfile=(filename)
              The filename should be the filename of a file containing an RSA SSL key.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers