RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent
mandy chung
mandy.chung at oracle.com
Thu Oct 12 15:22:38 UTC 2017
On 10/12/17 8:18 AM, Harsha Wardhana B wrote:
>
>
>
> On Thursday 12 October 2017 08:40 PM, mandy chung wrote:
>>
>>
>> On 10/12/17 1:16 AM, Harsha Wardhana B wrote:
>>>
>>>> I'm thinking any better alternative to the new property name??
>>>> com.sun.management.jmxremote.password.hashes
>>>> com.sun.management.jmxremote.password.asHashes com.sun.management.jmxremote.passowrd.toHashes
>>
>> I suggest to rename
>> com.sun.management.jmxremote.password.hashpasswords to
>> com.sun.management.jmxremote.password.hashes.
>>
>> What do you think?
> We want the property to suggest an action and hence *.toHashes would
> be better than *.hashes.
"toHashes" suffix is also good to me.
>>
>>>> 67 # If multiple entries are found for the same role name, then the
>>>> last one 68 # is used.
>>>> If there are multiple entries of the same role, will all entries be
>>>> overridden with hash value? It may be better to detect as an error
>>>> when there are more than one entries of the same role?
>>> It would be better to log a warning. Throwing an error would seem a
>>> bit extreme.
>>
>> What happen to the duplicated entries? The clear password will
>> stay? Warning is fine.
> The duplicated entries will be removed. The last entry for a given
> role along with its hashed password will be written into the file.
>
The other alternative is to override it with its hash value and output a
warning that this entry is ignored. This will leave it for the user to
remove the entries.
Mandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20171012/140c47ed/attachment.html>
More information about the serviceability-dev
mailing list