Load the token from the user settings DB as a blob because it might include

Load the token from the user settings DB as a blob because it might include
NULLs now that encrypt it.

BUG=49593
TEST=manually tested + updated unit tests

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=53210

[albertb, 2010-07-20 23:27:48]

Hi Tim, 

Since Encryptor is now *really* encrypting the auth token on Linux and Mac, the
token we get back from the DB might include some NULLs. The solution is to read
it back from the DB as a blob, so that NULLs aren't considered terminators.

I also updated the unit test to fail without this patch by making the test token
long enough that once encrypted it contains at least one NULL.

Thanks!
Albert

[ncarter (slow), 2010-07-20 23:33:00]

http://codereview.chromium.org/3058003/diff/2001/3001
File chrome/browser/sync/util/user_settings_posix.cc (right):

http://codereview.chromium.org/3058003/diff/2001/3001#newcode36
chrome/browser/sync/util/user_settings_posix.cc:36: statement.bind_string(2,
encrypted_service_token);
In the presence of null characters, does this have an effect equivalent to one
of the bind_blob variants?

[albertb, 2010-07-20 23:45:27]

http://codereview.chromium.org/3058003/diff/2001/3001
File chrome/browser/sync/util/user_settings_posix.cc (right):

http://codereview.chromium.org/3058003/diff/2001/3001#newcode36
chrome/browser/sync/util/user_settings_posix.cc:36: statement.bind_string(2,
encrypted_service_token);
On 2010/07/20 23:33:00, ncarter wrote:
> In the presence of null characters, does this have an effect equivalent to one
> of the bind_blob variants?
It doesn't because it takes the length of the string into account instead of
looking for NULLs. But for consistency, I've changed it to bind_blob.

[ncarter (slow), 2010-07-20 23:50:07]

LGTM