> Where/when was this wording discussed though ?
It was discussed at the meetings on Jan 24, Jan 31, and Feb 7.
> may be a good place for ad-hoc discussions around an issue, I don't really
> think it is a good forum for reviewing of these final notices prior to an
The notes are also tracked thro
>> The quality of container isolation in LXC heavily depends on implementation.
>> While
>> pure LXC is generally well-isolated through various mechanisms (for example
>> AppArmor
>> in Ubuntu), LXC through libvirt is not. A guest who operates within one
>> container is
>> able to affect another
> The best idea I've heard for a secure windows password
> is the following:
>
> a) put a public key on the instance via metadata or config drive (for ease of
> use this could actually just be the ssh public key you normally use for
> logging into the vm).
> b) have a daemon in the windows instan
I wanted to throw in my two cents here. I generally agree with the
notion that we should have the ability to issue tokens with different
scopes. And that this will become increasingly useful down the road
as we seek to provide finer grained access control for each user.
Having said this, I do hav
> Data left on broken disks would be unreadable. --> You don't have to worry
> about data destruction before selling/throwing out your disks.
I can certainly see the goal here. But this may be harder than you
think. For example, if you encrypt the disk image, then launch the
VM, are you sure tha
5 matches
Mail list logo
