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  ? with pam_mount and you get everything compliant with XDG base directory specification to have encrypted cached data for free. 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.  http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html -- Gilles Dartiguelongue <gilles.dartiguelon...@esiee.org> _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers