Did you try the password file without a newline? Because the plugin uses the whole file content as a password, including the last newline character. Try

echo -n secret > pwdfile

OK, that was it. I wasn't aware of the difference of...

linux> echo secret > 1.txt
linux> echo -n secret > 2.txt
linux> cat 1.txt | wc -c && cat 2.txt | wc -c
7
6

I +1 for a chomp to be done on the password in the file.

Thanks.

Hi,

Sorry I don't quite understand the description. Could you please provide the exact combination of file_key_management* variables which does not work, and explain whether you set them at runtime, or add them to the cnf file, or put them on the command line; and the combination of the variables which works.

Thanks.

It's resolved. See above comments.

Cheers,

R

I still think this needs a chomp performed on the password obtained from the file.

Re-opening for the chomp consideration.

Yes, I agree that the current behavior is sometimes unexpected.

On the other hand, one may want to include a newline character in the key. I see these options:

1. always remove all newline characters (one won't be able to use a key that ends with a new line, but who cares?)
2. don't remove newline character, but print a warning that a key includes a newline character at the end (doesn't solve the problem, but at least makes the user aware of it)
3. only remove one last newline, one will be able to use a key with newline at the end by putting two newlines in the file (a bit difficult to document, don't look natural)
4. something else?

I would just chomp it. I think that's the expected behaviour for almost everybody. I've never come across anyone using, or advocating using, a newline in a password/passphrase. As a general rule I think we expect passwords to not have any leading or trailing whitespace characters.