> 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 [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
