An clarification is added to FilePermission::implies:
* @implNote
* a simple {@code npath} is recursively inside a wildcard {@code npath}
* if and only if {@code simple_npath.relativize(wildcard_npath)}
- * is a series of one or more "..". An invalid {@code FileP
Looks fine to me.
Xuelei
On 12/13/2016 6:09 PM, Wang Weijun wrote:
NIST 800-57 Part 1 has a new revision. The lines below are newly introduced in
jdk9.
diff --git a/src/java.base/share/classes/sun/security/x509/AlgorithmId.java
b/src/java.base/share/classes/sun/security/x509/AlgorithmId.java
> On Dec 14, 2016, at 10:11 AM, Xuelei Fan wrote:
>
> On 12/13/2016 5:45 PM, Wang Weijun wrote:
>> A major behavior change is that <> now implies an invalid
>> permission, I hope this is good to minimize incompatibility.
> Looks like two sides of the same coin. If there is an invalid <>
> (no
On 12/13/2016 5:45 PM, Wang Weijun wrote:
A major behavior change is that <> now implies an invalid
permission, I hope this is good to minimize incompatibility.
Looks like two sides of the same coin. If there is an invalid > (not existing in practice, I think), it now implies all; if no
NIST 800-57 Part 1 has a new revision. The lines below are newly introduced in
jdk9.
diff --git a/src/java.base/share/classes/sun/security/x509/AlgorithmId.java
b/src/java.base/share/classes/sun/security/x509/AlgorithmId.java
--- a/src/java.base/share/classes/sun/security/x509/AlgorithmId.java
+
I copied the exact @implNote from JarSigner into the release note.
BTW, I noticed NIST 800-57 Part 1 has a new revision 4, which has the same
tables as in revision 3. A new bug
https://bugs.openjdk.java.net/browse/JDK-8171190 created and I'll create a
webrev soon.
Thanks
Max
> On Dec 14, 2016
Webrev updated at
http://cr.openjdk.java.net/~weijun/8168979/webrev.01
One comment is moved to its correct position and a typo fixed.
Thanks Daniel for the comment. Can someone with a reviewer hat take a look?
Thanks
Max
> On Dec 12, 2016, at 6:03 PM, Daniel Fuchs wrote:
>
> Hi Max,
>
>
Jon
Will there be a dedicated page for all non-SE javadocs? We already had some in
jdk.security.auth, jdk.security.jgss on the security guide home page [1].
Also, I am not sure if this belongs to the docs or build category if the
javadoc is meant to be generated automatically. Therefore I let i
On 12/13/2016 8:46 AM, Thomas Lußnig wrote:
Hi,
even if the case is with the current time not active. Is it an good idea
to define an fixed value
for random generator under special conditions that are time depending ?
The issue was fixed in JDK 9:
https://bugs.openjdk.java.net/browse/JDK-8
I would check with Jon Gibbons to see if there may be a more "official"
place for exported, non-SE javadocs; otherwise it seems ok to me.
--Sean
On 12/12/16 9:50 PM, Wang Weijun wrote:
Hi All
I've create a new bug to include the javadoc of the non-Java SE JarSigner API
into security doc:
Hi,
even if the case is with the current time not active. Is it an good idea
to define an fixed value
for random generator under special conditions that are time depending ?
Gruß Thomas
---
package sun.security.ssl;
RandomCookie(final SecureRandom sr) {
final long ts0 = System.c
Hi Max,
Could you include more information that shows what signature algorithm
is used based on the key size range and algorithm?
--Sean
On 12/11/16 9:53 PM, Wang Weijun wrote:
Please take a review at the release note at
https://bugs.openjdk.java.net/browse/JDK-8157389
Thanks
Max
On 12/13/16 1:43 PM, Adam Petcher wrote:
Here is the latest diff that simply adds a null check to the existing
code. When the provider is null, the debug output will be "...algorithm
from: (no provider)". The test code is the same as the last diff.
Looks good to me.
--Sean
diff --git a/src
Here is the latest diff that simply adds a null check to the existing
code. When the provider is null, the debug output will be "...algorithm
from: (no provider)". The test code is the same as the last diff.
diff --git a/src/java.base/share/classes/java/security/Signature.java
b/src/java.base
On 12/13/16 11:30 AM, Adam Petcher wrote:
Thanks for the review.
After thinking about this some more, I don't like the idea of using
Optional for a member variable due to the limitations of this class and
the lack of support for this usage of it. I'll send out a new diff that
uses a standard nul
Thanks for the review.
After thinking about this some more, I don't like the idea of using
Optional for a member variable due to the limitations of this class and
the lack of support for this usage of it. I'll send out a new diff that
uses a standard null check.
See below for other comments.
16 matches
Mail list logo
