Ok, I included Max's description for the special PBE parameter handling.
Should be enough details...
Filed: https://bugs.openjdk.java.net/browse/JDK-8209038
Thanks,
Valerie
On 8/6/2018 7:16 AM, Sean Mullan wrote:
On 8/3/18 8:19 PM, Valerie Peng wrote:
I can file a follow-on issue.
On 8/3/18 8:19 PM, Valerie Peng wrote:
I can file a follow-on issue. However, I want to clarify what we want to
do before filing it.
Based on current exchanges: We want to update
Cipher.getParameters()/CipherSpi.engineGetParameters() with similar
format/wording as
I can file a follow-on issue. However, I want to clarify what we want to
do before filing it.
Based on current exchanges: We want to update
Cipher.getParameters()/CipherSpi.engineGetParameters() with similar
format/wording as Signature.getParameters(), e.g. expanding the meaning
when null
On 7/24/18 9:38 PM, Weijun Wang wrote:
Something related.
Cipher has a similar init(..,params) and getParameters() structure and the spec
is also similar.
* The returned parameters may be the same that were used to initialize
* this cipher, or may contain a combination of default and random
*
Something related.
Cipher has a similar init(..,params) and getParameters() structure and the spec
is also similar.
* The returned parameters may be the same that were used to initialize
* this cipher, or may contain a combination of default and random
* parameter values used by the underlying
Returning to this briefly, looks good to me too.
Brad
On 7/19/2018 6:23 PM, Valerie Peng wrote:
Thanks Max and Sean for the review and suggestions. I have updated the
webrev accordingly and finalized CSR.
Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.04/
CSR:
Thanks Max and Sean for the review and suggestions. I have updated the
webrev accordingly and finalized CSR.
Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.04/
CSR: https://bugs.openjdk.java.net/browse/JDK-8206864
Valerie
On 7/19/2018 3:13 PM, Wang Weijun wrote:
在
> 在 2018年7月20日，05:18，Valerie Peng 写道：
>
> Hi Sean,
>
> Thanks for the suggestion, I like it.
Me too.
>
> Max, any objection or concern before I update the webrev and CSR?
No.
Thanks
Max
>
> Valerie
>
>
>> On 7/19/2018 7:28 AM, Sean Mullan wrote:
>> Hi Valerie, Max -
>>
>> I took a
Hi Sean,
Thanks for the suggestion, I like it.
Max, any objection or concern before I update the webrev and CSR?
Valerie
On 7/19/2018 7:28 AM, Sean Mullan wrote:
Hi Valerie, Max -
I took a fresh look at this issue this morning. I think we are getting
bogged down by trying to adjust within
Sean,
Where do you think that we should add the part about "null must be
returned ..." paragraph? At the end of first or second paragraph?
I will go with majority.
Valerie
On 7/17/2018 8:38 PM, Weijun Wang wrote:
Is it better to append the new lines to the 2nd paragraph?
Thanks
Max
On
Is it better to append the new lines to the 2nd paragraph?
Thanks
Max
> On Jul 18, 2018, at 9:46 AM, Valerie Peng wrote:
>
>
> Ok, let's use "must" then. I have also added the part about default
> parameters.
> Hope that all is clear now.
>
> Latest webrev:
Ok, let's use "must" then. I have also added the part about default
parameters.
Hope that all is clear now.
Latest webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.03/
Latest CSR: https://bugs.openjdk.java.net/browse/JDK-8206864
Thanks,
Valerie
On 7/17/2018 5:50 PM, Weijun Wang
Ok, I will try add it back.
Thanks,
Valerie
On 7/17/2018 1:14 PM, Sean Mullan wrote:
On 7/16/18 9:46 PM, Valerie Peng wrote:
As for the part about "randomly generated", I am leaning toward not
having it as I don't see a value of specifying this.
Hmm, I think it is important to continue
> On Jul 18, 2018, at 8:23 AM, Valerie Peng wrote:
>
> Hi Max,
>
> Thanks for the suggestions. Please find comments inline.
>
> On 7/16/2018 7:38 PM, Weijun Wang wrote:
>> CSR at https://bugs.openjdk.java.net/browse/JDK-8206864.
>>
>> - At the end of the 1st paragraph, you have now
>>
>>>
Hi Max,
Thanks for the suggestions. Please find comments inline.
On 7/16/2018 7:38 PM, Weijun Wang wrote:
CSR at https://bugs.openjdk.java.net/browse/JDK-8206864.
- At the end of the 1st paragraph, you have now
However, for signature algorithm such as "RSASSA-PSS", it requires
On 7/16/18 9:46 PM, Valerie Peng wrote:
As for the part about "randomly generated", I am leaning toward not
having it as I don't see a value of specifying this.
Hmm, I think it is important to continue to document the case where an
implementation may return default/generated parameters even
CSR at https://bugs.openjdk.java.net/browse/JDK-8206864.
- At the end of the 1st paragraph, you have now
> However, for signature algorithm such as "RSASSA-PSS", it requires
> parameters and the one used for signing must be supplied for verification to
> succeed. It may be better to return
Hi Max,
Good catch on the SignatureSpi class and SunMSCAPI provider, I will
include them.
As for the part about "randomly generated", I am leaning toward not
having it as I don't see a value of specifying this.
Webrev and CSR has been updated.
New webrev:
Valerie
Would you like to retain the word "randomly generated" somewhere?
Also, the SignatureSpi class needs to be updated in the same way.
Can you also update the implementation in the MSCAPI Signature object?
Thanks
Max
> On Jul 17, 2018, at 6:16 AM, Valerie Peng wrote:
>
>
> No issues
No issues found and it seems ok to return null if no parameters is set.
Thus, I have updated the webrev and CSR accordingly.
Bug: https://bugs.openjdk.java.net/browse/JDK-8206171
Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/
CSR:
Hmm, I like the idea of expanding null to cover both cases.
I will explore it more and see.
Thanks for the feedback,
Valerie
On 7/13/2018 6:56 AM, Sean Mullan wrote:
On 7/12/18 10:23 PM, Weijun Wang wrote:
On Jul 13, 2018, at 10:01 AM, Valerie Peng
wrote:
Hi Max,
The javadoc is for
On 7/12/18 10:23 PM, Weijun Wang wrote:
On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote:
Hi Max,
The javadoc is for Signature.getParameters(), so null can be returned for
signature algorithms which do not use parameters, e.g. SHA256withDSA. As
Signature class covers all signature
> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote:
>
> Hi Max,
>
> The javadoc is for Signature.getParameters(), so null can be returned for
> signature algorithms which do not use parameters, e.g. SHA256withDSA. As
> Signature class covers all signature algorithms, I am not sure about
>
Hi Max,
The javadoc is for Signature.getParameters(), so null can be returned
for signature algorithms which do not use parameters, e.g.
SHA256withDSA. As Signature class covers all signature algorithms, I am
not sure about mentioning specific algorithm names as it may be lengthy
and even
Yes, I think if an implementation can throw an exception in this case,
we should add that as an @throws. For example, something like the following:
@throws ProviderException if this signature engine requires parameters
but does not support default or randomly generated parameter values
Hi Valerie
About "it *may* return", do you mean it could also return null? My
understanding is no.
Is it better to clarify when the implementation "may also fail"? From the CSR,
it's this method. Can you add a @throws spec to this method then?
Also, I am a little confused by "default and
26 matches
Mail list logo
