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