RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

[mandy chung]

On 10/26/17 8:57 PM, Harsha Wardhana B wrote:
>
> Hi,
>
> Below is the updated webrev incorporating review comments from Daniel, 
> Roger and Mandy. The password file will now be locked before writing.
>

What is the link to the new webrev?

> Mandy,
>
>> 49 # 
>> https://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#MessageDigest
>> 50 # MD5, SHA-1 and SHA-256 are supported algorithms.
>> 51 # This is an optional field. If not specified SHA-256 will be 
>> assumed.
>> I would avoid the link to the documentation of a specific JDK release.
>> Maybe say:
>>
>> Refer to "Java Security Standard Algorithm Names Specification"
>> for supported algorithm.
> Link to the documentation is required because the exact strings as 
> specified in the documentation must be specified. "Java Security 
> Standard Algorithm Names Specification" does not actually help. So I 
> have not removed the link to the documentation.

At least this should point to JDK 9 docs rather than JDK 7.

Mandy

> -Harsha
>
>
> On Thursday 12 October 2017 09:22 PM, Harsha Wardhana B wrote:
>>
>> Sure. I will send out a modified webrev soon.
>>
>> -Harsha
>>
>>
>> On Thursday 12 October 2017 08:52 PM, mandy chung wrote:
>>>
>>>
>>> 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/20171027/58f0faeb/attachment-0001.html>