Re: [ACS41] Current blocker status

2013-05-16 Thread Prasanna Santhanam 
On Wed, May 15, 2013 at 03:07:41PM -0700, Animesh Chaturvedi wrote:
  CLOUDSTACK-2516
  Create User API compability broken now
  
  Nobody has taken this on yet.
 [Animesh] I will update the JIRA ticket, looks like this was
 changed by Kishan to use clear text password. I think functionality
 wise it will still work but will cause double encryption. We will
 have to wait for Kishan  to respond on this.

I think Kishan only added regions support. That piece of code has
existed for a long time. I'm guessing something in the order of
authenticators is going wrong although componentContext.xml.in is
using MD5 auth first. Investigating ..

-- 
Prasanna.,


Powered by BigRock.com

RE: [ACS41] Current blocker status

2013-05-16 Thread Kishan Kavala 

 -Original Message-
 From: Prasanna Santhanam [mailto:t...@apache.org]
 Sent: Thursday, 16 May 2013 11:51 AM
 To: dev@cloudstack.apache.org
 Subject: Re: [ACS41] Current blocker status
 
 On Wed, May 15, 2013 at 03:07:41PM -0700, Animesh Chaturvedi wrote:
   CLOUDSTACK-2516
   Create User API compability broken now
  
   Nobody has taken this on yet.
  [Animesh] I will update the JIRA ticket, looks like this was changed
  by Kishan to use clear text password. I think functionality wise it
  will still work but will cause double encryption. We will have to wait
  for Kishan  to respond on this.
 
 I think Kishan only added regions support. That piece of code has existed for
 a long time. I'm guessing something in the order of authenticators is going
 wrong although componentContext.xml.in is using MD5 auth first.
 Investigating ..

[KK]  I'm looking into this issue and update with my findings.

 
 --
 Prasanna.,
 
 
 Powered by BigRock.com

Re: [ACS41] Current blocker status

2013-05-16 Thread Prasanna Santhanam 
On Thu, May 16, 2013 at 11:51:06AM +0530, Prasanna Santhanam wrote:
 On Wed, May 15, 2013 at 03:07:41PM -0700, Animesh Chaturvedi wrote:
   CLOUDSTACK-2516
   Create User API compability broken now
   
   Nobody has taken this on yet.
  [Animesh] I will update the JIRA ticket, looks like this was
  changed by Kishan to use clear text password. I think functionality
  wise it will still work but will cause double encryption. We will
  have to wait for Kishan  to respond on this.
 
 I think Kishan only added regions support. That piece of code has
 existed for a long time. I'm guessing something in the order of
 authenticators is going wrong although componentContext.xml.in is
 using MD5 auth first. Investigating ..
 

This change happened when the authenticators were moved in to use
adapters. That change was a logical one to support multiple Auth
mechanisms. Hugo made the change in (bd58cecc) and it is the right way
to do it.

Prior to Hugo's fix the MD5 authenticator,although called so, would
only do a plaintext match of passwords with the database. Also the
createUser() would simply persist the password coming in over with
wire into the db.  Thereby it assumed tht the passwd would be
pre-encoded as MD5 at the client. 

So, why did MD5 passwds get into the DB at all? 
The API documentation asks that the client send in a md5 hashed
password and our ui script (account.js, sharedFunction.js) is hashing
the passwords into md5.

There was probably a reason behind this. I'm not sure: Here's the
comment indicating the change:


// Will: The MD5Authenticator is now a straight pass-through comparison of the
// the passwords because we will not assume that the password passed in has
// already been MD5 hashed.  I am keeping the above code in case this 
requirement changes
// or people need examples of how to MD5 hash passwords in java.
if (!user.getPassword().equals(password)) {
return false


After Hugo's fix the MD5 Authenticator (the default authenticator)
now _actually_ does the encoding and not depend on the client. But the
UI code still seems to exist and double encodes the md5 entry in the
form. 

So the fix should be 
- UI removes the double hashing when account creation happens.
- Fix the API doc to ask user to send in plaintext password and allow
  to act based on authenticator configured in componentsContext.xml

As an aside:
Hugo, the SHA256 authenticator you introduced seems to have been
removed from the componentContexts. Do you want to include it back,
commented?

Thanks,
-- 
Prasanna.,


Powered by BigRock.com

RE: [ACS41] Current blocker status

2013-05-16 Thread Kishan Kavala 


 -Original Message-
 From: Kishan Kavala [mailto:kishan.kav...@citrix.com]
 Sent: Thursday, 16 May 2013 1:24 PM
 To: dev@cloudstack.apache.org
 Subject: RE: [ACS41] Current blocker status
 
 
 
  -Original Message-
  From: Prasanna Santhanam [mailto:t...@apache.org]
  Sent: Thursday, 16 May 2013 12:39 PM
  To: dev@cloudstack.apache.org
  Subject: Re: [ACS41] Current blocker status
 
  On Thu, May 16, 2013 at 11:51:06AM +0530, Prasanna Santhanam wrote:
   On Wed, May 15, 2013 at 03:07:41PM -0700, Animesh Chaturvedi wrote:
 CLOUDSTACK-2516
 Create User API compability broken now

 Nobody has taken this on yet.
[Animesh] I will update the JIRA ticket, looks like this was
changed by Kishan to use clear text password. I think
functionality wise it will still work but will cause double
encryption. We will have to wait for Kishan  to respond on this.
  
   I think Kishan only added regions support. That piece of code has
   existed for a long time. I'm guessing something in the order of
   authenticators is going wrong although componentContext.xml.in is
   using MD5 auth first. Investigating ..
  
 
  This change happened when the authenticators were moved in to use
  adapters. That change was a logical one to support multiple Auth
  mechanisms. Hugo made the change in (bd58cecc) and it is the right way
  to do it.
 
  Prior to Hugo's fix the MD5 authenticator,although called so, would
  only do a plaintext match of passwords with the database. Also the
  createUser() would simply persist the password coming in over with
  wire into the db.  Thereby it assumed tht the passwd would be
  pre-encoded as MD5 at the client.
 
  So, why did MD5 passwds get into the DB at all?
  The API documentation asks that the client send in a md5 hashed
  password and our ui script (account.js, sharedFunction.js) is hashing
  the passwords into md5.
 
  There was probably a reason behind this. I'm not sure: Here's the
  comment indicating the change:
 
  
  // Will: The MD5Authenticator is now a straight pass-through
  comparison of the // the passwords because we will not assume that the
  password passed in has // already been MD5 hashed.  I am keeping the
  above code in case this requirement changes // or people need examples
  of how to MD5 hash passwords in java.
  if (!user.getPassword().equals(password)) {
  return false
  
 
  After Hugo's fix the MD5 Authenticator (the default authenticator) now
  _actually_ does the encoding and not depend on the client. But the UI
  code still seems to exist and double encodes the md5 entry in the form.
 
  So the fix should be
  - UI removes the double hashing when account creation happens.
  - Fix the API doc to ask user to send in plaintext password and allow
to act based on authenticator configured in componentsContext.xml
 
  As an aside:
  Hugo, the SHA256 authenticator you introduced seems to have been
  removed from the componentContexts. Do you want to include it back,
  commented?
 
  Thanks,
  --
  Prasanna.,
 
  
  Powered by BigRock.com
 
 Agree with Prasanna.  Authenticator changes were introduced via commit
 bd58cecc prior to Regions related changes.
 
 Couple of ways to fix this now:
  1. UI/client sends plain text as suggested by Prasanna along with api doc 
 fix.
 This would mean breaking backward compatibility but it's the clean way.
  2. Other option is to add PlainTextAuthenticator in ComponentContext to
 support existing clients. Master already has these changes.
 

I've submitted patch [1] to add PlainTextAuthenticator. This will solve the 
backward compatibility issue.
- Recommended option is for clients to send plain text instead of MD5 after 
upgrading to 4.1. 
- For those who do not want to change their client, componentContext.xml has to 
be changed to use PlainTextAuthenticator as default authenticator.

Following scenario should be avoided:
 - Client sends MD5 hash and default authenticator is MD5UserAuthenticator. 
Password stored in DB will be MD5 hashed twice. This will work as long client 
keeps sending MD5 hash and default authenticator is MD5UserAuthenticator. 
If the default authenticator is changed or if client changes to send plain 
text, existing users won't be able to login. Things will get even more complex 
when SHA256 becomes the default in 4.2.

[1] https://reviews.apache.org/r/11194/

Re: [ACS41] Current blocker status

2013-05-16 Thread Chiradeep Vittal 
See this discussion

http://s.apache.org/gW

On 5/16/13 12:53 AM, Kishan Kavala kishan.kav...@citrix.com wrote:



 -Original Message-
 From: Prasanna Santhanam [mailto:t...@apache.org]
 Sent: Thursday, 16 May 2013 12:39 PM
 To: dev@cloudstack.apache.org
 Subject: Re: [ACS41] Current blocker status
 
 On Thu, May 16, 2013 at 11:51:06AM +0530, Prasanna Santhanam wrote:
  On Wed, May 15, 2013 at 03:07:41PM -0700, Animesh Chaturvedi wrote:
CLOUDSTACK-2516
Create User API compability broken now
   
Nobody has taken this on yet.
   [Animesh] I will update the JIRA ticket, looks like this was
   changed by Kishan to use clear text password. I think functionality
   wise it will still work but will cause double encryption. We will
   have to wait for Kishan  to respond on this.
 
  I think Kishan only added regions support. That piece of code has
  existed for a long time. I'm guessing something in the order of
  authenticators is going wrong although componentContext.xml.in is
  using MD5 auth first. Investigating ..
 
 
 This change happened when the authenticators were moved in to use
 adapters. That change was a logical one to support multiple Auth
 mechanisms. Hugo made the change in (bd58cecc) and it is the right way
to
 do it.
 
 Prior to Hugo's fix the MD5 authenticator,although called so, would
only do a
 plaintext match of passwords with the database. Also the
 createUser() would simply persist the password coming in over with wire
into
 the db.  Thereby it assumed tht the passwd would be pre-encoded as MD5
at
 the client.
 
 So, why did MD5 passwds get into the DB at all?
 The API documentation asks that the client send in a md5 hashed password
 and our ui script (account.js, sharedFunction.js) is hashing the
passwords into
 md5.
 
 There was probably a reason behind this. I'm not sure: Here's the
comment
 indicating the change:
 
 
 // Will: The MD5Authenticator is now a straight pass-through comparison
of
 the // the passwords because we will not assume that the password passed
 in has // already been MD5 hashed.  I am keeping the above code in case
this
 requirement changes // or people need examples of how to MD5 hash
 passwords in java.
 if (!user.getPassword().equals(password)) {
 return false
 
 
 After Hugo's fix the MD5 Authenticator (the default authenticator) now
 _actually_ does the encoding and not depend on the client. But the UI
code
 still seems to exist and double encodes the md5 entry in the form.
 
 So the fix should be
 - UI removes the double hashing when account creation happens.
 - Fix the API doc to ask user to send in plaintext password and allow
   to act based on authenticator configured in componentsContext.xml
 
 As an aside:
 Hugo, the SHA256 authenticator you introduced seems to have been
 removed from the componentContexts. Do you want to include it back,
 commented?
 
 Thanks,
 --
 Prasanna.,
 
 
 Powered by BigRock.com

Agree with Prasanna.  Authenticator changes were introduced via commit
bd58cecc prior to Regions related changes.

Couple of ways to fix this now:
 1. UI/client sends plain text as suggested by Prasanna along with api
doc fix. This would mean breaking backward compatibility but it's the
clean way.
 2. Other option is to add PlainTextAuthenticator in ComponentContext to
support existing clients. Master already has these changes.

Re: [ACS41] Current blocker status

2013-05-16 Thread Chip Childers 
On Wed, May 15, 2013 at 03:07:41PM -0700, Animesh Chaturvedi wrote:
 
 
  -Original Message-
  From: Chip Childers [mailto:chip.child...@sungard.com]
  Sent: Wednesday, May 15, 2013 12:43 PM
  To: dev@cloudstack.apache.org
  Subject: [ACS41] Current blocker status
  
  The following are currently blocking a new RC for 4.1.0:
  
  CLOUDSTACK-2039
  Improve console access security with 128-bit AES encryption and securely-
  randomized key generation
  
  This needs to be addressed.  Kelven, do you mind reviewing Wido's error?
 [Animesh] Kelven is offline for next two weeks, we will need someone else to 
 look into this issue

This was an upgrade process issue for Wido.  Bug resolved.

  
  
  CLOUDSTACK-2463
  CS Upgrade 2.Upgrade2.14 to 4.1.0 failed due to no public network found
  (configuration : advanced network with security groups)
  
  This is being discussed in another thread.
  
 [Animesh] I will respond in the other thread

We have a serious decision to make now...  we don't have anyone
currently working on VMware support, so we still have stranded users
even if we pull the feature in earlier than 4.2.

  
  CLOUDSTACK-2492
  System VM Clock Drift
  
  This is also being discussed in another thread.

We have fixes for KVM and VMware, but do not have an answer for
XenServer that doesn't involve rebuilding the system VM template.

  
  
  CLOUDSTACK-2516
  Create User API compability broken now
  
  Nobody has taken this on yet.
 [Animesh] I will update the JIRA ticket, looks like this was changed by 
 Kishan to use clear text password. I think functionality wise it will still 
 work but will cause double encryption. We will have to wait for Kishan  to 
 respond on this.
 

Outstanding work: document the upgrade scenario and pull the fix into
master.

Re: [ACS41] Current blocker status

2013-05-16 Thread Prasanna Santhanam 
On Thu, May 16, 2013 at 07:12:14PM +, Chiradeep Vittal wrote:
 See this discussion
 
 http://s.apache.org/gW
 
Nice - thanks for digging it up from the archives. I couldn't find it
and had to write a long email explaining things :)

-- 
Prasanna.,


Powered by BigRock.com

RE: [ACS41] Current blocker status

2013-05-15 Thread Animesh Chaturvedi 


 -Original Message-
 From: Chip Childers [mailto:chip.child...@sungard.com]
 Sent: Wednesday, May 15, 2013 12:43 PM
 To: dev@cloudstack.apache.org
 Subject: [ACS41] Current blocker status
 
 The following are currently blocking a new RC for 4.1.0:
 
 CLOUDSTACK-2039
 Improve console access security with 128-bit AES encryption and securely-
 randomized key generation
 
 This needs to be addressed.  Kelven, do you mind reviewing Wido's error?
[Animesh] Kelven is offline for next two weeks, we will need someone else to 
look into this issue
 
 
 CLOUDSTACK-2463
 CS Upgrade 2.Upgrade2.14 to 4.1.0 failed due to no public network found
 (configuration : advanced network with security groups)
 
 This is being discussed in another thread.
 
[Animesh] I will respond in the other thread
 
 CLOUDSTACK-2492
 System VM Clock Drift
 
 This is also being discussed in another thread.
 
 
 CLOUDSTACK-2516
 Create User API compability broken now
 
 Nobody has taken this on yet.
[Animesh] I will update the JIRA ticket, looks like this was changed by Kishan 
to use clear text password. I think functionality wise it will still work but 
will cause double encryption. We will have to wait for Kishan  to respond on 
this.