Re: RFR: 8280494: (D)TLS signature schemes [v13]
On Tue, 8 Feb 2022 20:18:20 GMT, Sean Mullan wrote:
>>> Are you maybe saying that this method returns the value of the system
>>> properties if they are set?
>>
>> The return value of this method depends on the following specs:
>>
>> * If the {@link #setSignatureSchemes} method has not been called, this
>> * method should return the default signature schemes for connection
>> * populated objects, or {@code null} for pre-populated objects.
>> ```
>>
>> If the setSignatureSchemes() method has been called, the get method will
>> return the set values. I may miss this spec. But I think it is a common
>> sense that the getter method returns the values set with setter method. Let
>> me know if you would like to have an explicit clarification in the spec.
>
> Ok, I get it now, the API wins if both are set. But I could not discern that
> from the current text. I think it is ok to be more clear about this. I
> suggest adding something like the following:
>
> "The set of signature schemes that will be used is determined in this order
> of preference: 1. explicitly set by application; 2. specified by system
> property; 3. specified by provider defaults. For example, setting the
> signature schemes in your application overrides settings specified in
> jdk.tls.client.SignatureSchemes or jdk.tls.server.SignatureSchemes, as well
> as JDK provider defaults."
>
> Does that accurately capture the implementation behavior?
Basically, the suggestion captures the implementation behaviors correctly. To
make it more accuracy, if we want to use it, we may need to consider more cases:
1. _explicitly set by application_, with null, empty or 1+ schemes.
2. _specified by system property_, with unset, empty or 1+ schemes.
I think the description could be in the following logic:
A. the system properties are used to customize the provider default schemes.
B. If the API set it to null, use the the provider default schemes (including
system properties customized default schemes).
C. If the API set it to empty, don't use any schemes.
D. if the API set it to 1+ scheme, use the API set schemes.
With logic A, we don't have to describe both _system properties_ and the
_provider default schemes_ each time when we talk about the interaction
behaviors of them. And then we can simplify the 3 interactive factors into 2
factors.
Here is the general 3 interactive factors:
1. the API.
2. the System properties.
3. the provider default.
Here is set 1 of the 2 interactive factors:
1. The System properties;
2. the provider default.
Here is set 2 of the 2 interactive factors:
1. the API
2. the provider default.
Then, we could describe set 1 and set 2 individually. I think it is easier to
understand.
Then, we could have the sections accordingly.
For A, we have (for set 1 of the 2 interactive factors):
* @implNote
* Note that the underlying provider may define the default signature
* schemes for each SSL/TLS/DTLS connection. Applications may also use
* the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
* {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
* customize the provider-specific default signature schemes.
```
For B, we have (for set 2 of the 2 interactive factors):
* If the returned array is {@code null}, then the underlying
* provider-specific default signature schemes will be used over the
* SSL/TLS/DTLS connections.
For C, we have (for set 2 of the 2 interactive factors):
* If the returned array is empty (zero-length), then the signature scheme
* negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
* the connections may not be able to be established if the negotiation
* mechanism is required by a certain SSL/TLS/DTLS protocol.
For D, we have (for set 2 of the 2 interactive factors):
*
* If the returned array is not {@code null} or empty (zero-length),
* then the signature schemes in the returned array will be used over
* the SSL/TLS/DTLS connections.
That's the current description we have. That's, in order to explain behavior
of the null, empty and 1+ schemes setting, I cut the sentence into 4 sections
above.
I understand it could be confusing when multiple facts are involved. It may be
clear if re-org the description. What do you think of the following
descriptions?
In the get method:
*
* Note that the underlying provider may define the default signature
schemes for
* each SSL/TLS/DTLS connection. Applications may also use the
{@systemProperty
* jdk.tls.client.SignatureSchemes} and/or {@systemProperty
* jdk.tls.server.SignatureSchemes} system properties to customize the
* provider-specific default signature schemes.
*
* The set of signature schemes that will be used over the SSL/TLS/DTLS
* connections is determined by the returned array of this method and the
* underlying provider-specif
Re: RFR: 8280494: (D)TLS signature schemes [v13]
On Mon, 7 Feb 2022 23:13:13 GMT, Xue-Lei Andrew Fan wrote:
>>> "If set, these properties will override the signature schemes returned by
>>> this method."
>>
>> If I understand your ideas correctly, the behavior should be "the returned
>> value of this method will override these properties", except the case if the
>> returned value is null.
>>
>> But let me trying if I could understand the spec by myself.
>>
>> For the getSignatureSchemes() method's spec:
>>
>> * If the returned array is {@code null}, then the underlying
>> * provider-specific default signature schemes will be used over the
>> * SSL/TLS/DTLS connections.
>>
>> With the spec above, the API getSignatureSchemes() returns null, and the
>> provider-specific default signature schemes will be used for the connection.
>> As the properties could be used to customize the default signature schemes,
>> the properties wins in this situation for your question. However, I would
>> like to express that the default signature schemes win (See bellow about why
>> I don't want to use the properties).
>>
>>
>> * If the returned array is empty (zero-length), then the signature
>> scheme
>> * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
>> * the connections may not be able to be established if the negotiation
>> * mechanism is required by a certain SSL/TLS/DTLS protocol.
>>
>> With the spec above, the API getSignatureSchemes() returns empty array, and
>> no signature schemes will be used. The API wins, the default signature
>> schemes are not used.
>>
>>
>> *
>> * If the returned array is not {@code null} or empty (zero-length),
>> * then the signature schemes in the returned array will be used over
>> * the SSL/TLS/DTLS connections.
>>
>> With the spec above, the API getSignatureSchemes() returns non-null and
>> non-empty, and the returned array will be used. The API wins, the default
>> signature schemes are not used.
>>
>>
>> * @implNote
>> * Note that the underlying provider may define the default signature
>> * schemes for each SSL/TLS/DTLS connection. Applications may also use
>> * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or
>> * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to
>> * customize the provider-specific default signature schemes.
>>
>> With the spec above, I could understand what are the default signature
>> schemes, and how they could be customized with properties.
>>
>> So back to my question above, why I don't want to use the properties, and
>> use the default signature schemes instead? We need to take care of three
>> things: the properties, the API set values and the provider default values.
>> If I use the properties values, I would have to describe the provider
>> default values as well. As the properties values are used to set the
>> provider default values, it should be sufficient to use the provider default
>> values for the description in this context.
>>
>> What if both the properties and the APIs are set? The properties are used
>> to set the provider default values, and the properties will change the
>> provider default values. So we only need to consider the provider default
>> values and the API, then I think we can refer to the 3 spec sections before
>> the @implNote tag above. Simply, if both set, the API wins.
>>
>> Similar to the set method.
>>
>> Please let me know if you are on the same page as well. I am open to make
>> more changes if the spec is still not clear.
>
>> Are you maybe saying that this method returns the value of the system
>> properties if they are set?
>
> The return value of this method depends on the following specs:
>
> * If the {@link #setSignatureSchemes} method has not been called, this
> * method should return the default signature schemes for connection
> * populated objects, or {@code null} for pre-populated objects.
> ```
>
> If the setSignatureSchemes() method has been called, the get method will
> return the set values. I may miss this spec. But I think it is a common
> sense that the getter method returns the values set with setter method. Let
> me know if you would like to have an explicit clarification in the spec.
Ok, I get it now, the API wins if both are set. But I could not discern that
from the current text. I think it is ok to be more clear about this. I suggest
adding something like the following:
"The set of signature schemes that will be used is determined in this order of
preference: 1. explicitly set by application; 2. specified by system property;
3. specified by provider defaults. For example, setting the signature schemes
in your application overrides settings specified in
jdk.tls.client.SignatureSchemes or jdk.tls.client.SignatureSchemes, as well as
JDK provider defaults."
Does that accurately capture the implementation behavior?
Integrated: 8279329: Remove hardcoded IPv4 available policy on Windows
On Wed, 2 Feb 2022 08:31:08 GMT, Masanori Yano wrote: > I added socket connection check same as IPv6_supported(). > Before this fix, when IPv4 is uninstalled (called `netsh interface ipv4 > uninstall`), and set property `-Djava.net.preferIPv4Stack=true`, > java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is always set to > 1(IPv4), because IPv4_supported() always returns TRUE. After applied this > fix, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is set to > 2(IPv6). > It looks fine that IPv4_supported() returns FALSE. > Would you review this fix? This pull request has now been integrated. Changeset: f2a9627c Author:Masanori Yano Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/f2a9627c05f9ef82eb83d8c1b9d4209bf42e7d8d Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8279329: Remove hardcoded IPv4 available policy on Windows Reviewed-by: djelinski, alanb, dfuchs, aefimov - PR: https://git.openjdk.java.net/jdk/pull/7317
