> 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 ? 

That way, we don't have to write (and more importantly maintain) yet another 
encryption/decryption library and instead just use a different folder for 
storing all secret/confidential data, which can be a custom mount point which 
runs on encrypted partition. 

>From a distro point of view, libraries with security packages usually have 
>extra maintenance overhead (Are you sure your package is not shipped to 
>america-banned countries ? etc.)  So I believe it will be a better idea if the 
>[en/de]cryption capable packages are less in number. 

Sankar
http://psankar.blogspot.com 

_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to