On 02/24/2014 09:39 AM, Ladislav Smola wrote:
On 02/23/2014 01:16 AM, Clint Byrum wrote:
Excerpts from Imre Farkas's message of 2014-02-20 15:24:17 +:
On 02/20/2014 03:57 PM, Tomas Sedovic wrote:
On 20/02/14 15:41, Radomir Dopieralski wrote:
On 20/02/14 15:00, Tomas Sedovic wrote:
Are w
On 02/23/2014 01:16 AM, Clint Byrum wrote:
Excerpts from Imre Farkas's message of 2014-02-20 15:24:17 +:
On 02/20/2014 03:57 PM, Tomas Sedovic wrote:
On 20/02/14 15:41, Radomir Dopieralski wrote:
On 20/02/14 15:00, Tomas Sedovic wrote:
Are we even sure we need to store the passwords in t
On 21/02/14 10:03, Radomir Dopieralski wrote:
On 21/02/14 10:38, Dougal Matthews wrote:
At the moment we are guessing, we don't even know how many passwords
we need to store. So we should progress with the safest and simplest
option (which is to not store them) and consider changing this later.
On Fri, Feb 21, 2014 at 10:24:24AM +0100, Tomas Sedovic wrote:
> On 20/02/14 16:24, Imre Farkas wrote:
> > On 02/20/2014 03:57 PM, Tomas Sedovic wrote:
> >> On 20/02/14 15:41, Radomir Dopieralski wrote:
> >>> On 20/02/14 15:00, Tomas Sedovic wrote:
> >>>
> Are we even sure we need to store the
Excerpts from Imre Farkas's message of 2014-02-20 15:24:17 +:
> On 02/20/2014 03:57 PM, Tomas Sedovic wrote:
> > On 20/02/14 15:41, Radomir Dopieralski wrote:
> >> On 20/02/14 15:00, Tomas Sedovic wrote:
> >>
> >>> Are we even sure we need to store the passwords in the first place? All
> >>> th
On 21/02/14 10:38, Dougal Matthews wrote:
> On 21/02/14 09:24, Tomas Sedovic wrote:
>> On 20/02/14 16:24, Imre Farkas wrote:
>>> On 02/20/2014 03:57 PM, Tomas Sedovic wrote:
On 20/02/14 15:41, Radomir Dopieralski wrote:
> On 20/02/14 15:00, Tomas Sedovic wrote:
>
>> Are we even sur
On 21/02/14 09:24, Tomas Sedovic wrote:
On 20/02/14 16:24, Imre Farkas wrote:
On 02/20/2014 03:57 PM, Tomas Sedovic wrote:
On 20/02/14 15:41, Radomir Dopieralski wrote:
On 20/02/14 15:00, Tomas Sedovic wrote:
Are we even sure we need to store the passwords in the first place? All
this encryp
On 20/02/14 16:24, Imre Farkas wrote:
> On 02/20/2014 03:57 PM, Tomas Sedovic wrote:
>> On 20/02/14 15:41, Radomir Dopieralski wrote:
>>> On 20/02/14 15:00, Tomas Sedovic wrote:
>>>
Are we even sure we need to store the passwords in the first place? All
this encryption talk seems very pre
On 02/20/2014 03:57 PM, Tomas Sedovic wrote:
On 20/02/14 15:41, Radomir Dopieralski wrote:
On 20/02/14 15:00, Tomas Sedovic wrote:
Are we even sure we need to store the passwords in the first place? All
this encryption talk seems very premature to me.
How are you going to redeploy without th
On 20/02/14 16:02, Radomir Dopieralski wrote:
> On 20/02/14 15:57, Tomas Sedovic wrote:
>> On 20/02/14 15:41, Radomir Dopieralski wrote:
>>> On 20/02/14 15:00, Tomas Sedovic wrote:
>>>
Are we even sure we need to store the passwords in the first place? All
this encryption talk seems very
On 20/02/14 15:57, Tomas Sedovic wrote:
> On 20/02/14 15:41, Radomir Dopieralski wrote:
>> On 20/02/14 15:00, Tomas Sedovic wrote:
>>
>>> Are we even sure we need to store the passwords in the first place? All
>>> this encryption talk seems very premature to me.
>>
>> How are you going to redeploy
On 20/02/14 15:41, Radomir Dopieralski wrote:
> On 20/02/14 15:00, Tomas Sedovic wrote:
>
>> Are we even sure we need to store the passwords in the first place? All
>> this encryption talk seems very premature to me.
>
> How are you going to redeploy without them?
>
What do you mean by redeploy
On 20/02/14 15:00, Tomas Sedovic wrote:
> Are we even sure we need to store the passwords in the first place? All
> this encryption talk seems very premature to me.
How are you going to redeploy without them?
--
Radomir Dopieralski
___
OpenStack-dev m
On 20/02/14 14:47, Radomir Dopieralski wrote:
> On 20/02/14 14:10, Jiří Stránský wrote:
>> On 20.2.2014 12:18, Radomir Dopieralski wrote:
>
>>> Thinking about it some more, all the uses of the passwords come as a
>>> result of an action initiated by the user either by tuskar-ui, or by
>>> the tusk
Just to throw this out there, is this something we need for Icehouse?
Yes, I fully acknowledge that it's an ugly security hole. But what's our
story for how stable/clean Tuskar will be for Icehouse? I don't believe
the intention is for people to use this in a production environment yet,
so it
On 20/02/14 14:10, Jiří Stránský wrote:
> On 20.2.2014 12:18, Radomir Dopieralski wrote:
>> Thinking about it some more, all the uses of the passwords come as a
>> result of an action initiated by the user either by tuskar-ui, or by
>> the tuskar command-line client. So maybe we could put the key
On 20/02/14 14:10, Jiří Stránský wrote:
> On 20.2.2014 12:18, Radomir Dopieralski wrote:
>> On 20/02/14 12:02, Radomir Dopieralski wrote:
>>> Anybody who gets access to Tuskar-API gets the
>>> passwords, whether we encrypt them or not. Anybody who doesn't have
>>> access to Tuskar-API doesn't get t
On 20/02/14 10:12, Radomir Dopieralski wrote:
> On 19/02/14 18:29, Dougal Matthews wrote:
>> The question for me, is what passwords will we have and when do we need
>> them? Are any of the passwords required long term.
>
> We will need whatever the Heat template needs to generate all the
> configu
On 20.2.2014 12:18, Radomir Dopieralski wrote:
On 20/02/14 12:02, Radomir Dopieralski wrote:
Anybody who gets access to Tuskar-API gets the
passwords, whether we encrypt them or not. Anybody who doesn't have
access to Tuskar-API doesn't get the passwords, whether we encrypt
them or not.
Yeah,
On 20/02/14 12:02, Radomir Dopieralski wrote:
> On 20/02/14 11:46, Dougal Matthews wrote:
>> On 20/02/14 10:36, Radomir Dopieralski wrote:
>>> On 20/02/14 11:21, Dougal Matthews wrote:
If we do store passwords however, I wonder if we are
best to encrypt everything to be safe. The overhead
On 20/02/14 11:46, Dougal Matthews wrote:
> On 20/02/14 10:36, Radomir Dopieralski wrote:
>> On 20/02/14 11:21, Dougal Matthews wrote:
>>> If we do store passwords however, I wonder if we are
>>> best to encrypt everything to be safe. The overhead shouldn't be that
>>> big and it may be better than
On 20/02/14 10:36, Radomir Dopieralski wrote:
On 20/02/14 11:21, Dougal Matthews wrote:
If we do store passwords however, I wonder if we are
best to encrypt everything to be safe. The overhead shouldn't be that
big and it may be better than special casing the "NoEcho" values.
I think that befo
On 20/02/14 11:21, Dougal Matthews wrote:
> If we do store passwords however, I wonder if we are
> best to encrypt everything to be safe. The overhead shouldn't be that
> big and it may be better than special casing the "NoEcho" values.
I think that before we start encrypting everything, we need t
On 20/02/14 09:12, Radomir Dopieralski wrote:
If we do need to store passwords it becomes a somewhat thorny issue, how
does Tuskar know what a password is? If this is flagged up by the
UI/client then we are relying on the user to tell us which isn't wise.
All the template parameters that are pa
On 02/20/2014 10:12 AM, Radomir Dopieralski wrote:
On 19/02/14 18:29, Dougal Matthews wrote:
The question for me, is what passwords will we have and when do we need
them? Are any of the passwords required long term.
We will need whatever the Heat template needs to generate all the
configuratio
On 02/19/2014 06:10 PM, Ladislav Smola wrote:
Hello,
I would like to have your opinion about how to deal with passwords in
Tuskar-API
The background is, that tuskarAPI is storing heat template parameters in
its database, it's a
preparation for more complex workflows, when we will need to store
On 19/02/14 18:29, Dougal Matthews wrote:
> The question for me, is what passwords will we have and when do we need
> them? Are any of the passwords required long term.
We will need whatever the Heat template needs to generate all the
configuration files. That includes passwords for all services t
On 02/19/2014 06:29 PM, Dougal Matthews wrote:
On 19/02/14 17:10, Ladislav Smola wrote:
Hello,
I would like to have your opinion about how to deal with passwords in
Tuskar-API
The background is, that tuskarAPI is storing heat template parameters in
its database, it's a
preparation for more com
On 02/19/2014 08:05 PM, Dougal Matthews wrote:
On 19/02/14 18:49, Hugh O. Brock wrote:
On Wed, Feb 19, 2014 at 06:31:47PM +, Dougal Matthews wrote:
On 19/02/14 18:29, Jason Rist wrote:
Would it be possible to create some token for use throughout? Forgive
my naivete.
I don't think so, the
On 19/02/14 18:49, Hugh O. Brock wrote:
On Wed, Feb 19, 2014 at 06:31:47PM +, Dougal Matthews wrote:
On 19/02/14 18:29, Jason Rist wrote:
Would it be possible to create some token for use throughout? Forgive
my naivete.
I don't think so, the token would need to be understood by all the
se
On Wed, Feb 19, 2014 at 06:31:47PM +, Dougal Matthews wrote:
> On 19/02/14 18:29, Jason Rist wrote:
> >Would it be possible to create some token for use throughout? Forgive
> >my naivete.
>
> I don't think so, the token would need to be understood by all the
> services that we store passwords
On 19/02/14 18:29, Jason Rist wrote:
Would it be possible to create some token for use throughout? Forgive
my naivete.
I don't think so, the token would need to be understood by all the
services that we store passwords for. I may be misunderstanding however.
Dougal
___
On Wed 19 Feb 2014 10:29:32 AM MST, Dougal Matthews wrote:
> On 19/02/14 17:10, Ladislav Smola wrote:
>> Hello,
>>
>> I would like to have your opinion about how to deal with passwords in
>> Tuskar-API
>>
>> The background is, that tuskarAPI is storing heat template parameters in
>> its database, i
On 19/02/14 17:10, Ladislav Smola wrote:
Hello,
I would like to have your opinion about how to deal with passwords in
Tuskar-API
The background is, that tuskarAPI is storing heat template parameters in
its database, it's a
preparation for more complex workflows, when we will need to store the
d
Hello,
I would like to have your opinion about how to deal with passwords in
Tuskar-API
The background is, that tuskarAPI is storing heat template parameters in
its database, it's a
preparation for more complex workflows, when we will need to store the
data before the actual
heat stack-crea
35 matches
Mail list logo
