Le vendredi 04 mars 2011 à 05:47 -0700, Sankar P a écrit :
> > I'm working on "Enterprise" use of Evolution, and one of the big
> > requirements is encryption of data at rest. The answer "just encrypt the
> > whole of the user's home directory" only puts them off for so long.
> > 
> > So I'm looking at implementing this directly in camel-data-cache,
> > e-cal-backend-cache, etc.
> > 
> > I'll probably do the encryption with a randomly-generated key, which
> > itself is stored locally, encrypted with a password. 
> > 
> > That way, changing the password doesn't involve re-encrypting the whole
> > of the store; you only need to re-encrypt the master key. It also means
> > that we can tie the password for the cache to the password for the
> > server; entering one will allow access to both.
> > 
> > Hopefully, the changes required to code that *uses* the cache
> > functionality should be fairly limited. Mostly it should be handled by
> > extra arguments to camel_data_cache_new(), e_cal_backend_cache_new(),
> > camel_db_open() and similar functions.
> > 
> > I'm hoping that it's reasonable to declare that *filenames* are not
> > sensitive, and that we only need to encrypt the *contents* of files.
> > Does that seem fair?
> > 
> > Any other comments on the approach?
> Will it be not simpler if we can make Evolution use a custom location for 
> cache, that the user/root can set ? 

XDG_CACHE_HOME [1] ? with pam_mount and you get everything compliant
with XDG base directory specification to have encrypted cached data for

I don't think it's healthy for an application to implement this kind of
feature by itself, even if most of the heavy work is done by a library.

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html

Gilles Dartiguelongue <gilles.dartiguelon...@esiee.org>

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to