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


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

Reply via email to