Define encoding of "password" to UTF-8

[zonyitoo]

Problem

The "password" could be passed in various ways, basic configration file, SIP008 online configuration, command line options, and other customized ways. Currently, the encoding of "password" is defined by implementations, for example

• shadowsocks-libev: UTF-8 in basic configuration file, but undefined in command line options
• shadowsocks-rust: UTF-8
• go-shadowsocks2: Undefined, os.Args in Go is a string[], which is an array of byte arrays of input arguments

So it is possible that if user uses libev with command line options and specifies "password" in UTF-16BE, and it shouldn't work with the rust version, because the "password"s are not the same in byte level.

Proposal

1. The "password" is a "string" in UTF-8 encoding
2. Implementations are allowed to accept "password" in other encoding, but they have to convert it to UTF-8 before set to ciphers

[Mygod]

You described the problem, not the motivation. Why do we need fancy characters in password anyway? A mix of upper/lower-case letters and numbers should always work, in which case the encoding does not matter.

[zonyitoo]

You are right. I am totally ok for limiting "password" to only ASCII characters, but the problem is that there is no standard about it. Implementations allow users to set non-ASCII "password" and that would eventually results in compatible issues.

Defining "password" to UTF-8 has no significant loss, because it is fully compatible to ASCII.

[Mygod]

Sure but we should probably not include anything beyond ASCII.

[zonyitoo]

So we could make a conclusion:

1. "password" must be an UTF-8 string
2. "password" is recommended to contain only ASCII characters for maximum compatiblity

[dev4u]

如果能支持ascii外的可见字符，可以使密码不用设置得那么长，也可以得到较高的安全等级。