On Fri, 2011-03-04 at 12:58 +, David Woodhouse wrote:
> I wasn't planning to do any of the actual crypto code directly in
> Evolution; I was planning to use NSS for that. The additional
> functionality would presumably live inside #ifdef CAMEL_HAVE_NSS, like a
> lot of other code in e-d-s alrea
On Fri, 2011-03-04 at 07:49 -0500, Jeffrey Stedfast wrote:
> Anyways, do you also plan on encrypting mbox/maildir files? Might make
> sense...
Missed that bit; overtrimming my citations. I probably wouldn't do this
*myself* in the first round, but I'd hope that someone might add it
soon, and I mi
On Fri, 2011-03-04 at 05:47 -0700, Sankar P wrote:
>
> 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
On Fri, 2011-03-04 at 07:49 -0500, Jeffrey Stedfast wrote:
> Easiest way to implement this feature in Camel might be to implement a
> CamelMimeFilter or CamelStream that encrypts/decrypts the content as it
> reads/writes the data. Implementing it as a CamelStream might be the
> best approach as it
On 03/04/2011 06:40 AM, David Woodhouse wrote:
> 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
> 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-
On Fri, 2011-03-04 at 07:30 -0500, Matthew Barnes wrote:
> Got'cha. Seems reasonable. Thanks for humoring me.
No problem; thanks for paying attention to my ramblings.
--
dwmw2
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change
On Fri, 2011-03-04 at 12:25 +, David Woodhouse wrote:
> On Fri, 2011-03-04 at 07:17 -0500, Matthew Barnes wrote:
> > Perhaps it's a different story for mobile devices?
>
> To a large extent, yes. The 'encrypt it all' solution means that you are
> forced to unlock the device to do *anything* wi
On Fri, 2011-03-04 at 07:17 -0500, Matthew Barnes wrote:
> On Fri, 2011-03-04 at 11:55 +, David Woodhouse wrote:
> > On Fri, 2011-03-04 at 06:50 -0500, Matthew Barnes wrote:
> > > Can you go into more detail about why it's needed? Would help me to
> > > better understand the use cases.
> >
>
On Fri, 2011-03-04 at 11:55 +, David Woodhouse wrote:
> On Fri, 2011-03-04 at 06:50 -0500, Matthew Barnes wrote:
> > Can you go into more detail about why it's needed? Would help me to
> > better understand the use cases.
>
> Mostly corporate paranoia. If your phone/tablet/laptop is stolen, t
On Fri, 2011-03-04 at 06:50 -0500, Matthew Barnes wrote:
> On Fri, 2011-03-04 at 11:40 +, David Woodhouse wrote:
> > 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 directo
On Fri, 2011-03-04 at 11:40 +, David Woodhouse wrote:
> 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.
Can you go into more detail
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.
13 matches
Mail list logo