On Wed, Apr 04, 2012 at 09:39:55PM +0100, Dale Amon wrote:
> I'm going to try to resolve this manually, but
> I thought it might perhaps be of interest
> to someone here.
>
> Unpacking libapt-pkg4.12:i386 (from
> .../libapt-pkg4.12_0.8.16~exp12ubuntu6_i386.deb) ...
> dpkg: error processing
> /va
On Wed, Apr 04, 2012 at 07:55:09PM -0400, Sam Smith wrote:
>
> I use "SpiderOak" because it offers client-side encryption. It provides the
> security & privacy I seek.
>
> I'd prefer to use Ubuntu One, but until it supports client-side AES 256-bit
> encryption & additionally encrypts the decryp
On Thu, Apr 5, 2012 at 8:18 AM, Dale Amon wrote:
> On Wed, Apr 04, 2012 at 07:55:09PM -0400, Sam Smith wrote:
>>
>> I use "SpiderOak" because it offers client-side encryption. It provides the
>> security & privacy I seek.
>>
>> I'd prefer to use Ubuntu One, but until it supports client-side AES 2
On Thu, Apr 05, 2012 at 11:32:33AM -0500, Jordon Bedwell wrote:
> On Thu, Apr 5, 2012 at 8:18 AM, Dale Amon wrote:
> Encrypting the encryption key has nothing to do with security, you
I agree.
> dedicated crypto hardware. Then you have to re-upload all that data
> again, wasting their bandwidth
Here's another nasty bug and some pointers from the developers
to how to fix it.
- Forwarded message from "Richard W.M. Jones" -
Date: Thu, 5 Apr 2012 20:16:06 +0100
From: "Richard W.M. Jones"
To: Dale Amon
Cc: libvirt-us...@redhat.com, ebl...@redhat.com, libgues...@redhat.com
Subject:
The point is that SpiderOak (and Lastpass) never know the user's password. And
never receive the encryption key. The key never leaves the user's computer. The
server never gets it. The only thing that ever lands on the server is an
encrypted blob.
What this means is that the user doesn't have
On Thu, Apr 05, 2012 at 10:13:26PM +0100, Dale Amon wrote:
> Here's another nasty bug and some pointers from the developers
> to how to fix it.
Thanks. I've requested a sync of febootstrap from unstable to fix this.
--
Colin Watson [cjwat...@ubuntu.com]
--
On Thu, Apr 05, 2012 at 06:42:23PM -0400, Sam Smith wrote:
>
> The point is that SpiderOak (and Lastpass) never know the user's password.
> And never receive the encryption key. The key never leaves the user's
> computer. The server never gets it. The only thing that ever lands on the
> server
On Thu, Apr 5, 2012 at 5:42 PM, Sam Smith wrote:
> The point is that SpiderOak (and Lastpass) never know the user's password.
> And never receive the encryption key. The key never leaves the user's
> computer. The server never gets it. The only thing that ever lands on the
> server is an encrypted
I would not be so harsh on these companies. They
are very quietly *told* that they will comply
with the will of certain agencies. Or else. And
they are not allowed to tell their customers. Or
else... But they are trying to sell security. So
what are they going to do? They are going to
do a doubleth
On 04/05/2012 01:33 PM, Jordon Bedwell wrote:
On Thu, Apr 5, 2012 at 5:42 PM, Sam Smith wrote:
The point is that SpiderOak (and Lastpass) never know the user's password.
And never receive the encryption key. The key never leaves the user's
computer. The server never gets it. The only thing that
Six statements rather... I added the other two
initial ones as I thought more deeply on it.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
On Thu, 2012-04-05 at 18:33 -0500, Jordon Bedwell wrote:
> On Thu, Apr 5, 2012 at 5:42 PM, Sam Smith wrote:
> > The point is that SpiderOak (and Lastpass) never know the user's password.
> > And never receive the encryption key. The key never leaves the user's
> > computer. The server never gets i
On Fri, 2012-04-06 at 01:41 +0100, Dale Amon wrote:
> I do not know the details, so I will ask: is it the case that:
All we can know for sure is the way the system is DOCUMENTED to work, as
I said in my other email.
> * The user crypto key is generated on the
> the user machine.
Ye
On Thu, Apr 05, 2012 at 09:18:37PM -0400, Paul Smith wrote:
> I'm sure that they felt that forcing you to keep both the passphrase AND
> the crypto key yourself was simply not a commercially viable solution
> for the general public. It would be nice if they offered an option
> (with appropriate ca
15 matches
Mail list logo
