[Bug 218556] Review Request: ecryptfs-utils - Linux eCryptfs utilities

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: ecryptfs-utils - Linux eCryptfs utilities


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218556





------- Additional Comments From mhalcrow at us.ibm.com  2007-06-08 12:50 EST -------
Kevin wrote:
> Thanks for looking at this!
> 
> We had gotten rid of the rpath in the past... looks like it's crept back. 
> Will get that fixed. 

I thought I had addressed this issue with the --disable-rpath
configure flag. I don't think there's anything funny in my makefiles
that should re-introduce it.

> >1) keyutils, openssl, pam requirements should be superfluous - library
> >dependencies take care of this
> 
> ok. Removed. 
> 
> >2) kernel requires are tricky. Generally, we do
> >
> >Conflicts: kernel < 2.6.19
> >
> >as there's no reason, for example, to pull a kernel into a buildroot.
> 
> Well, the tricky part here is we need to require a kernel with ecryptfs.ko in
> it. For F-7 and devel no problems, as all of them have it. For FC-6 however, the
> early kernels didn't, and the updated ones do. I thought that the error end
> users get from yum on Requires is more usefull than Conflicts?
> 
> >That's bad; these shouldn't be linked against things in /usr/lib. (Yes, some
> >people still run /usr separate.) Moreover, I suspect that both of these will
> >also dlopen the plugins in $(libdir)/ecryptfs?
> 
> Thats a good Question. Michael? Any thoughts?

It makes sense to link these statically. I will make it so in the next
ecryptfs-utils release.

> Yes, those .so's under libdir/ecryptfs/ do dlopen the so's. 
> This sounds like something for upstream to change?

The files in libdir/ecryptfs/ are pluggable key modules, sort of like
OpenSSL engines in /usr/lib/engines/.

However, they are necessary in order to insert the key for the given
key type into the user session keyring, and hence are necessary in
order to mount.

It sounds like the key modules shipping with the ecryptfs-utils
package would best be statically linked too.

> > -devel: what, if anything, will ever build against this? If there's nothing,
> >it may not be worth shipping. (Also,does this package maintain a stable ABI?)
> 
> I don't know of anything... Michael?

libecryptfs exists specifically to allow others to write their own
utilities (a GUI, for instance) to work with eCryptfs key management
functions. For instance, anyone who wants to write their own pluggable
key modules to interface with their own key management system will
need the -devel package.

The exported symbols in libecryptfs can be considered stable.

Mike

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.