auth, etcdserver: hash password in the API layer

[mitake]

With this change etcd gets hashed password for UserAdd and UserChangePassword. Log entries of WAL will be like below:

   2            10      norm    header:<ID:3632560226236973574 > auth_user_add:<name:"u1" password:"$2a$10$tc.gSL/vyM48WXtMzDTKZuXWyWIbMqPQPWLR20GY8he0OzSpU4jgi" options:<> >

Note that this PR is still WIP (conversion between string and byte array in the API layer).

[mitake]

Note that this PR changes the content of log entry and state machine behavior so cannot be backported to the stable releases.

[mitake]

I think it's ready to be reviewed, could you take a look @jingyih @gyuho @spzala ?

[mitake]

kindly ping, could you take a look? @xiang90 @jingyih @gyuho @spzala

[jingyih]

Note that this PR changes the content of log entry and state machine behavior so cannot be backported to the stable releases.

I just added feature label to this PR (usually we do not backport features). Maybe we want to create a do-not-backport label for this type of changes?

[jingyih]

Does this feature prevent user from performing rolling upgrade to their etcd clusters?

[tangcong]

Does this feature prevent user from performing rolling upgrade to their etcd clusters?

yes,if new member applies a UserAddRequest from old member, it is failed to add user and cause data inconsistency. if r.HashPassword == "" && r.Password != "" ,we have to be compatible with old version logic.how do you think so? @mitake

[mitake]

@jingyih

Maybe we want to create a do-not-backport label for this type of changes?

Yes, creating such a label is valuable. PRs which introduce changed behavior of the state machine should be labeled with it.

@tangcong

yes,if new member applies a UserAddRequest from old member, it is failed to add user and cause data inconsistency. if r.HashPassword == "" && r.Password != "" ,we have to be compatible with old version logic.how do you think so? @mitake

That's a good idea, I'll make a commit for implementing the strategy.

[mitake]

@tangcong @jingyih updated for the compatibility issue, could you take a look?

[mitake]

@jingyih could you take a look when you have a time? I think it's ok to merge this PR (the failed test isn't related to this PR).

[mitake]

cc @spzala

[spzala]

@mitake thank you, lgtm but can you please fix the build error - https://travis-ci.com/github/etcd-io/etcd/jobs/358895971#L413 I think you just need to remove the else loop on LOC 386 which is unnecessary. Thanks!

[mitake]

@spzala oops sorry for that, I fixed it in the latest commit

[spzala]

@spzala oops sorry for that, I fixed it in the latest commit

@mitake :) no problem at all and Thanks!
@jingyih hi, any final comments from you? Thanks!

[spzala]

@mitake thanks much! Merging it. @gyuho @xiang90 @jingyih