Jay Pipes wrote:
> On Mon, Mar 7, 2011 at 10:43 AM, Dan Prince wrote:
>> Bugs vs. Blueprints is sort of a gray area. When a larger blue print is
>> accepted (like the Openstack 1.1 API) should we file component features as
>> bugs or blueprints?
>>
>> In my case I could have easily considered th
On Mon, Mar 7, 2011 at 10:43 AM, Dan Prince wrote:
> Hi Thierry,
>
> Appoligies for the late blueprint submission. I guess I like using Blueprints
> for missing features so that I can setup the dependencies in launchpad. On
> this specific issue I just wanted some community comments and communic
should
already support the v1.0 API right?
Dan
-Original Message-
From: "Thierry Carrez"
Sent: Saturday, March 5, 2011 4:14pm
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] OS API server password generation
Jay Pipes wrote:
> Does anyone else feel it'
Jay Pipes wrote:
> Does anyone else feel it's a bit late to be targeting new blueprints
> for Cactus since we're 2 weeks from branch merge proposal freeze?
>
> http://wiki.openstack.org/CactusReleaseSchedule
Yes.
SpecSubmissionDeadline for Cactus was one month ago. It was tolerated so
far to add
cool. It's just the timing :)
-jay
> Dan
>
> -Original Message-
> From: "Jay Pipes"
> Sent: Friday, March 4, 2011 10:27am
> To: "Dan Prince"
> Cc: "Openstack"
> Subject: Re: [Openstack] OS API server password generation
>
> D
nce"
Cc: "Openstack"
Subject: Re: [Openstack] OS API server password generation
Does anyone else feel it's a bit late to be targeting new blueprints
for Cactus since we're 2 weeks from branch merge proposal freeze?
http://wiki.openstack.org/CactusReleaseSchedule
-jay
On W
Does anyone else feel it's a bit late to be targeting new blueprints
for Cactus since we're 2 weeks from branch merge proposal freeze?
http://wiki.openstack.org/CactusReleaseSchedule
-jay
On Wed, Mar 2, 2011 at 4:11 PM, Dan Prince wrote:
> We created a blueprint on adding support for password g
On Mar 3, 2011, at 3:13 PM, Scott Moser wrote:
> The reason I piped up, and the reason I think there is some
> misunderstanding is (from Ed):
>
>> Again, you seem to have missed my point. OpenStack is *not* working on
>> this.
>
> This is an OpenStack mailing list. The original mail says:
On Thu, 3 Mar 2011, Ed Leafe wrote:
> On Mar 3, 2011, at 10:36 AM, George Reese wrote:
>
> > It's a mistake to send OpenStack pursuing a flaw in Cloud Servers.
Boy...
Isn't this a rat hole that I've helped us go down.
I am completely "pro-agent" (well, more agnostic). I would certainly
hop
> fundamental change in trust by having them.
> >>>
> >>> Ewan.
> >>>
> >>>> -Original Message-
> >>>> From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
> >>>> [mailto:openstack-
> bounces+
> -Original Message-
> From: George Reese [mailto:george.re...@enstratus.com]
> Sent: 03 March 2011 18:41
> To: Ewan Mellor
> Cc: Ed Leafe; Openstack; Mark Washenberger
> Subject: Re: [Openstack] OS API server password generation
>
> So why don't we give the provider
's no
>>> fundamental change in trust by having them.
>>>
>>> Ewan.
>>>
>>>> -Original Message-
>>>> From: openstack-bounces+ewan.mellor=citrix....@lists.launchpad.net
>>>> [mailto:openstack-bounces+ewan.mellor=citrix@lists.l
[mailto:openstack-bounces+ewan.mellor=citrix....@lists.launchpad.net]
>>> On Behalf Of George Reese
>>> Sent: 03 March 2011 15:36
>>> To: Ed Leafe
>>> Cc: Openstack; Mark Washenberger
>>> Subject: Re: [Openstack] OS API server password generation
&
gt;
>> -Original Message-
>> From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
>> [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
>> On Behalf Of George Reese
>> Sent: 03 March 2011 15:36
>> To: Ed Leafe
>>
om: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
> [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
> On Behalf Of George Reese
> Sent: 03 March 2011 15:36
> To: Ed Leafe
> Cc: Openstack; Mark Washenberger
> Subject: Re: [Openstack] OS API server
On Mar 3, 2011, at 10:36 AM, George Reese wrote:
> I don't agree with this approach.
>
> The current Cloud Servers approach is flawed. I wrote about this a year ago:
>
> http://broadcast.oreilly.com/2010/02/the-sacred-barrier.html
FWIW, I agree with what you're saying. Please understand
George Reese wrote:
> It's a mistake to send OpenStack pursuing a flaw in Cloud Servers.
As much as I agree with Scott and you, I fail to see why OpenStack
cannot support both ways and let the deployer choose ?
--
Thierry Carrez (ttx)
Release Manager, OpenStack
_
I don't agree with this approach.
The current Cloud Servers approach is flawed. I wrote about this a year ago:
http://broadcast.oreilly.com/2010/02/the-sacred-barrier.html
It's a mistake to send OpenStack pursuing a flaw in Cloud Servers.
-George
On Mar 3, 2011, at 9:32 AM, Ed Leafe wrote:
>
On Mar 3, 2011, at 8:40 AM, George Reese wrote:
> Any mechanism that requires an agent or requires any ability of the
> hypervisor or cloud platform to inject a password creates trust issues. In
> particular, the hypervisor and platform should avoid operations that reach
> into the guest. The g
On Thu, 3 Mar 2011, George Reese wrote:
> Of all the boostrapping mechanisms I have encountered, the AWS model
> still remains the best. Specifically, with the guest OS pulling the keys
> from a trusted platform source.
>
> Any mechanism that requires an agent or requires any ability of the
> hype
Of all the boostrapping mechanisms I have encountered, the AWS model still
remains the best. Specifically, with the guest OS pulling the keys from a
trusted platform source.
Any mechanism that requires an agent or requires any ability of the hypervisor
or cloud platform to inject a password cre
On Mar 2, 2011, at 11:41 PM, Mark Washenberger wrote:
> To your main point, I share your desire to be able to turn off password
> injection during instance creation. (For clarity, I'm assuming that your
> preference is to create the vm with no root password and only ssh keys as a
> means of acc
On Wed, Mar 2, 2011 at 8:41 PM, Mark Washenberger <
mark.washenber...@rackspace.com> wrote:
> Yikes, I'm sorry. I didn't mean to give the impression of promoting bad
> code. I was coming at it from a simplicity perspective because I mistakenly
> thought my approach was cryptographically equivalent
Yikes, I'm sorry. I didn't mean to give the impression of promoting bad code. I
was coming at it from a simplicity perspective because I mistakenly thought my
approach was cryptographically equivalent, assuming a case where the user does
not want to skip password injection.
To your main point,
Why go to all this effort to promote bad code, when writing good code is
just as easy? This is a fairly trivial fix we're talking about, probably
comparable to the effort of running strace.
Anyway, my focus is on users that don't want you setting passwords into
their boxes (especially after readi
Each time I call random.seed() on my box, it grabs another 256 bits from
/dev/urandom (verified by strace).
I feel like we can just rely on the old standby [random.choice(pwchars) for i
in xrange(pwlength)], peppering a few random.seed() calls in periodically to
skip onto a new pseudorandom loo
We should be "secure out of the box", and not require the user to change
their password or manually lock down SSH to disable password auth.
A secure password would still be just as readable: I was thinking we'd use
the secure bytes to generate a readable password (either using them as a
seed or e.
On Mar 2, 2011, at 8:01 PM, Justin Santa Barbara wrote:
> Also, I know security through obscurity isn't really security, but if we're
> open source, I think we must have "strong" password generation, whatever may
> or may not have been the case in the past. I suggest beefing up the
> generate_
I think we need the option _not_ to inject a password (e.g. if I'm on Linux
and am going to use SSH private keys, or if I have another higher-security
means of accessing my server) Does the API support this (yet)?
Also, I know security through obscurity isn't really security, but if we're
open so
On Mar 2, 2011, at 4:11 PM, Dan Prince wrote:
> We created a blueprint on adding support for password generation when
> creating servers. This is needed for Openstack API/Cloud Servers API v1.0
> parity.
>
> We are anxious to get this work started so if you are interested please
> review the f
30 matches
Mail list logo
