ust because
> the ContentSigner APIs are still there doesn't mean you have to use it in
> jarsigner (unless I am missing something).
>
> --Sean
>
>> —Max
>>>> 在 2020年4月9日，21:27，Sean Mullan 写道：
>>>
>>> On 4/9/20 3:13 AM, Wang Weijun w
Valerie in another reply suggested that the default parameters of the default
sigAlg depends on either the size of the key (if RSA) of the params of the key
(if RSASSA-PSS). I'll address all of these in another bug.
Thanks,
Max
> 在 2020年4月9日，03:47，Sean Mullan 写道：
>
> On 4/6/20 11:11 PM, Weij
Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA.
Sigh.
--Max
> 在 2020年4月9日，01:58，Sean Mullan 写道：
>
> We never actually deprecated the com.sun.jarsigner package with a
> forRemoval=true flag, so while it may be very low-risk to remove these APIs,
> I feel that we s
Yes, I am on vacation now.
When I’m back, I’ll post your changes to cr.openjdk.java.net first.
Thanks
Max
> 在 2018年10月4日，06:13，Valerie Peng 写道：
>
> Hi Nico,
>
> Thanks for submitting the patches, Max is off on Chinese holidays til 7th and
> I am going to be on vacation til 19th.
>
> I supp
This makes sense. No other comment.
Thanks
Max
> 在 2018年9月16日，05:10，Ivan Gerasimov 写道：
>
> Hi Max!
>
>
>> On 9/15/18 6:28 AM, Weijun Wang wrote:
>> In the bug description you listed some in jdk/internal/org/objectweb/asm,
>> but they are not included in the fix. Is it because those are not d
Thinking about this again. Looks like the absolute path is not necessary. Even
if there are multiple files using the same name, they will be in different
directories, no matter absolute or relative. Suppose the jarPath info is used
for debugging purpose mostly like the developer can find out wha
> 在 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
RFC 4120 5.5.1 has
> seq-number
> This optional field includes the initial sequence number to be used by the
> KRB_PRIV or KRB_SAFE messages when sequence numbers are used to detect
> replays. (It may also be used by application specific messages.) When
> included in the authenticator, this fie
The change looks fine.
Thanks
Max
> 在 2018年4月19日，19:32，bhanu.prakash.gopula...@oracle.com 写道：
>
> Hi All,
>
> Please review fix for following issue:
>
> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8200101
>
> Webrev: http://cr.openjdk.java.net/~bgopularam/8200101/webrev.00/
>
> It was
> 在 2017年11月14日，18:02，Severin Gehwolf 写道：
>
> This looks fine, but I wonder if a regression test would be in order.
> E.g. test/sun/security/tools/keytool/WeakAlg.java with
> -Duser.language=fr or some such.
But my change has not really fixed anything. It’s just a hint on how to
correctly tra
Some more suggestions on the test:
1. You can use readAllBytes() to ... err ... read all bytes.
2. I normally don’t remove intermediate files. Jtreg will do an automatic
cleanup, and it can be configured to retain those files when the test fails.
They will be very helpful in debugging.
Thank
Please review this doc bug
diff --git
a/src/java.base/share/classes/java/security/DrbgParameters.java
b/src/java.base/share/classes/java/security/DrbgParameters.java
--- a/src/java.base/share/classes/java/security/DrbgParameters.java
+++ b/src/java.base/share/classes/java/security/DrbgParamete
Is there a valid case where a security manager is created but not set?
--Max
> On Jan 12, 2560 BE, at 7:18 AM, Claes Redestad
> wrote:
>
> Hi again,
>
> On 2017-01-11 15:27, Claes Redestad wrote:
>> Hi Adam,
>>
>> On 01/11/2017 02:34 PM, Adam Petcher wrote:
>>> Please review the following bu
https://bugs.openjdk.java.net/browse/JDK-8165115
Thanks
Max
Sorry, I didn't notice it.
--Max
On 1/4/2017 7:59 AM, Xuelei Fan wrote:
On 1/3/2017 3:54 PM, Wang Weijun wrote:
This looks good.
On the other hand, it might be better to add exception stack trace or
links to failures to the bug report. Maybe you think they are too
useless?
As this
This looks good.
On the other hand, it might be better to add exception stack trace or links to
failures to the bug report. Maybe you think they are too useless?
Thanks
Max
> On Jan 4, 2017, at 7:23 AM, Xuelei Fan wrote:
>
> Hi,
>
> The intermittent test failure of
> test/sun/security/ssl/S
Ping again. Please review https://bugs.openjdk.java.net/browse/JDK-8157389.
JDK-8171190 was already resolved.
Thanks
Max
> On Dec 14, 2016, at 10:04 AM, Wang Weijun wrote:
>
> I copied the exact @implNote from JarSigner into the release note.
>
> BTW, I noticed NIST 800-57 P
Ping again.
On 12/22/2016 9:52 AM, Wang Weijun wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8170732/webrev.00/
According to https://tools.ietf.org/html/rfc4752#section-3.1:
The client then constructs data, with the first octet containing the
bit-mask specifying the
Ping again.
On 12/27/2016 3:25 AM, Wang Weijun wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8172017/webrev.00
On Solaris when launched by root, the rcache directory is a little
different.
I've manually tested this on a Solaris machine, and seen rcache
files creat
Please take a review at
http://cr.openjdk.java.net/~weijun/8172017/webrev.00
On Solaris when launched by root, the rcache directory is a little
different.
I've manually tested this on a Solaris machine, and seen rcache files
created at different directories when the test was launched by r
Please take a review at
http://cr.openjdk.java.net/~weijun/8170732/webrev.00/
According to https://tools.ietf.org/html/rfc4752#section-3.1:
The client then constructs data, with the first octet containing the
bit-mask specifying the selected security layer, the second through
fourth o
Change looks fine.
Thanks for taking care of CtrDrbg.java. I've make quite some changes like this
and it's a shame I missed it in my own code.
--Max
> On Dec 22, 2016, at 4:05 AM, Xuelei Fan wrote:
>
> Hi,
>
> Please review the fix:
>
> http://cr.openjdk.java.net/~xuelei/6972386/webrev.00
s "/foo" but not "foo".".
Good advice.
Thanks
Max
>
> Use the one you like, I'm OK with the either.
>
> Xuelei
>
> On 12/21/2016 3:58 PM, Wang Weijun wrote:
>>
>>> On Dec 22, 2016, at 4:39 AM, Xuelei Fan wrote:
>>>
>&
;-", the simple pathname's path
> * must be recursively inside the wildcard pathname's path.
Yes.
But the precise meaning of "recursively inside" is different between the
pre-jdk9 and jdk9 behaviors. The @implNote explains more.
--Max
>
> Xuelei
>
> On
Ping again.
> On Dec 14, 2016, at 1:53 PM, Wang Weijun wrote:
>
> An clarification is added to FilePermission::implies:
>
> * @implNote
>
> * a simple {@code npath} is recursively inside a wildcard {@code npath}
> * if and only if {@code
Hi Amanda
Everything is fine. I have no other comment.
Thanks
Max
> On Dec 19, 2016, at 2:43 PM, Amanda Jiang wrote:
>
>
>
> On 12/18/16 10:23 PM, Wang Weijun wrote:
>>> Please see updated webrev :
>>> http://cr.openjdk.java.net/~amjiang/8075618/webrev.04/
> Please see updated webrev :
> http://cr.openjdk.java.net/~amjiang/8075618/webrev.04/ (also attached)
>
> I moved the checkPermission() calls into v9/bersion/Version.java, but I did
> not check if the output contains "I'm running on version 9", I think it does
> not make sense to make test fai
is running,
I think you can call assertContains("I am running on version 10").
And if you don't intend to reuse Main.java, I think it's not worth passing into
arguments.
Thanks
Max
> other functional tests are covered by
> http://hg.openjdk.java.net/jdk9/dev/jdk/f
Hi Artem
I hope you are OK with this change:
diff --git a/test/lib/security/SecurityTools.java
b/test/lib/testlibrary/jdk/testlibrary/SecurityTools.java
rename from test/lib/security/SecurityTools.java
rename to test/lib/testlibrary/jdk/testlibrary/SecurityTools.java
--- a/test/lib/security/Secu
Please take a review at
http://cr.openjdk.java.net/~weijun/8171340/webrev.00/
All "openConnection()" modified to "openConnection(Proxy.NO_PROXY)".
Everything else is whitespace change.
Thanks
Max
7680 itself is 192 bits, and for any bitLength greater than 7680 I treat it as
in a "higher" level.
--Max
> On Dec 14, 2016, at 5:19 PM, Bernd Eckenfels wrote:
>
> Hello,
>
> I noticed in the existing code: Is the comment "256 bits" referring to the
> 'comparable strength'?
>
> # if (bitLen
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
> 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
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
+
n Dec 14, 2016, at 5:09 AM, Sean Mullan wrote:
>
> 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 rev
} are created with the same
>invalid path, one does *not* imply the other.
>
> best regards,
>
> -- daniel
>
> On 12/12/16 09:01, Wang Weijun wrote:
>> Please take a review at
>>
>> http://cr.openjdk.java.net/~weijun/8168979/webrev.00/
>>
; 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:
>>
>> http
Hi All
I've create a new bug to include the javadoc of the non-Java SE JarSigner API
into security doc:
https://bugs.openjdk.java.net/browse/JDK-8171135
If you think this is OK, I'll move the bug to doc.
Thanks
Max
Hi Amanda
Can you also test the new JarSigner API?
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce33c780cfbd
line 2.72 has an example on it.
> On Dec 13, 2016, at 9:22 AM, Artem Smotrakov
> wrote:
>
> You can use
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/d4d7f1f0d688/test/lib/securit
Hi Adam
The only behavior change is with the debug output, right?
Is this a new pattern that internal optional fields should be defined as an
Optional?
And, when there is no provider the string form "from: " looks strange, I would
rather make it "from nowhere". I would also move the space befo
* are created with the same invalid path, one does imply the other.
>
> should this be:
>
>Even if two {@code FilePermission} are created with the same
>invalid path, one does *not* imply the other.
Ah, yes.
Thanks
Max
>
> best regards,
>
> -- daniel
Please take a review at
http://cr.openjdk.java.net/~weijun/8168979/webrev.00/
This further clarifies what an invalid FilePermission behaves. A major behavior
change is that <> now implies an invalid permission, I hope this is
good to minimize incompatibility.
Thanks
Max
Please take a review at the release note at
https://bugs.openjdk.java.net/browse/JDK-8157389
Thanks
Max
Change looks fine.
One nit: the extra space at the beginning of line 24 looks strange.
Thanks
Max
On 11/30/2016 5:27 PM, Sibabrata Sahoo wrote:
Hi,
Please review the patch for,
JBS: https://bugs.openjdk.java.net/browse/JDK-8170247
Webrev: http://cr.openjdk.java.net/~ssahoo/8170247/webre
+1
--Max
> On Nov 29, 2016, at 5:16 PM, Seán Coffey wrote:
>
> Looks good.
>
> regards,
> Sean.
>
>
> On 29/11/2016 09:08, Ivan Gerasimov wrote:
>> Hello!
>>
>> It was reported that there's broken behavior exposed when the debug mode is
>> turned on, which is due to KerberosTicket.toString
Hi Sergei
Looks good to me.
Thanks
Max
On 11/28/2016 9:17 PM, Sergei Kovalev wrote:
R-sending request for review
17.11.16 15:43, Sergei Kovalev wrote:
Hello team,
Please review a small fix for security tests.
BugID: https://bugs.openjdk.java.net/browse/JDK-8169866
Web review: http://cr.op
Hi Alan
Updated webrev at
http://cr.openjdk.java.net/~weijun/8170364/webrev.01
Changes since webrev.00:
- a private constructor that can clones 4 fields and modifies 5 others
- using lambda
- test enhancement
Thanks
Max
> On Nov 27, 2016, at 7:13 PM, Wang Weijun wrote:
>
>>
>> On Nov 27, 2016, at 6:12 PM, Alan Bateman wrote:
>>
>> On 26/11/2016 08:54, Wang Weijun wrote:
>>
>>> Please take a review at
>>>
>>> http://cr.openjdk.java.
> On Nov 27, 2016, at 6:12 PM, Alan Bateman wrote:
>
> On 26/11/2016 08:54, Wang Weijun wrote:
>
>> Please take a review at
>>
>>http://cr.openjdk.java.net/~weijun/8170364/webrev.00/
>>
>> The compatibility layer introduced in the new File
This is not only a test update.
> On Nov 27, 2016, at 9:35 AM, Xuelei Fan wrote:
>
> Hi,
>
> Please review this test update:
>
> http://cr.openjdk.java.net/~xuelei/8170329/webrev.00/
>
> The new template (SSLSocketTemplate.java) could be used to avoid the
> anti-free-port issues. By using
Please take a review at
http://cr.openjdk.java.net/~weijun/8170364/webrev.00/
The compatibility layer introduced in the new FilePermission implementation
requires one FilePermission to imply another with either a relative path or an
absolute path. This is solved with a private field npath2 i
Hi Brad
I think I found a problem with the test. Before you set your local
java.security file, the system java.security file was already read (in
jtreg initialization) and limited was picked up. In fact, I modified the
java.security file of my own JDK to unlimited and the test fails.
This se
penjdk.java.net/~amjiang/8169911/webrev.02/
>
> Thanks,
> Amanda
>
>
> On 11/18/16 11:37 PM, Wang Weijun wrote:
>
>> Hi Amanda
>>
>> - There are many duplicates in signWithAlias() and sign(). I think it's
>> better to make one based on the o
Hi Amanda
- There are many duplicates in signWithAlias() and sign(). I think it's better
to make one based on the other. Maybe signWithAliasAndTsa() and sign().
- checkWeak2() is about combinations of weak/strong algs in a single signer.
I'd rather it be an individual test case, and not as a st
> On Nov 17, 2016, at 9:33 AM, Bradford Wetmore
> wrote:
>
>try (PrintWriter out = new PrintWriter(FILENAME)) {
>Files.lines(path)
>.filter(x -> !x.trim().startsWith("crypto.policy"))
>.forEach(out::println);
>}
Not very sure.
ced that before! We have NOT been consistent in whether we
>>> use:
>>>
>>>System.out.println()
>>> or
>>>debug.println()
>>>
>>> I knew SeanC wants to rework the JCA/JCE/Security debugging output in
>>> another project, so I
> On Nov 16, 2016, at 12:40 PM, Jamil Nimeh wrote:
>
> Oops, good catch. I'll fix that. I assume you don't need a third review for
> that?
No. Just push your change.
--Max
>
>
>
> --Jamil
>
> ---- Original message
> From: Wang
Looks fine.
Small nit: new test has copyright 2003, 2016.
--Max
> On Nov 16, 2016, at 11:45 AM, Jamil Nimeh wrote:
>
> Good suggestions, thanks.
>
> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.02
>
> --Jamil
>
>
> On 11/15/2016 06:1
us test.* properties. Having 2 run tags double the time and not what I
wanted.
--Max
>
> Xuelei
>
> On 11/16/2016 11:23 AM, Wang Weijun wrote:
>> Sorry, the webrev here http://cr.openjdk.java.net/~weijun/8169751/webrev.00/
>>
>> --Max
>>
>>> On Nov
Sorry, the webrev here http://cr.openjdk.java.net/~weijun/8169751/webrev.00/
--Max
> On Nov 16, 2016, at 10:40 AM, Wang Weijun wrote:
>
> Please take a review at
>
> 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris
>
> Different service names ar
AlgName ThreadSafe", "true");
or
putService(new Service(this, "SecureRandom", "AlgName", className,
null, Map.of("ThreadSafe", "true")));
{@code SecureRandom} will then call the applicable engine methods
without any synchron
Please take a review at
8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris
Different service names are used in the 2 tests (rcache_usemd5.sh and
ReplayCacheTestProc.java) now.
Thanks
Max
41 System.setSecurityManager(new SecurityManager());
This is strange. I suppose you only want to trigger a permission check?
If so, just change it to Policy.getPolicy(), and you can clean up the policy
file a little.
Thanks
Max
> On Nov 16, 2016, at 8:36 AM, Jamil Nimeh wrote:
>
> He
You create a debug field with a prefix string and then check both debug != null
and Debug.isOn("policy") and then use System.out.println to print the message.
Something must be useless.
--Max
> On Nov 16, 2016, at 3:31 AM, Bradford Wetmore
> wrote:
>
> Simple codereview:
>
>http://cr.op
> On Nov 9, 2016, at 5:06 AM, Sean Mullan wrote:
>
>> In fact, can we
>> deprecate the getSeed() method? It's not unsafe so we don't need to give
>> it a forRemoval value.
>
> Sounds reasonable. I would file a bug, but I don't think it is critical for 9
> - we can do it in 10.
https://bugs.op
Everything looks fine now.
--Max
> On Nov 8, 2016, at 11:09 AM, Artem Smotrakov
> wrote:
>
> Here is final version (I hope)
>
> http://cr.openjdk.java.net/~asmotrak/8168882/webrev.04/
>
> Artem
only if a jar file has been specified.
>>
>> Let me also check how "-printcert -file ..." and "-printcert -sslserver"
>> work.
>>
>> Artem
>>
>>
>> On 11/03/2016 07:27 AM, Wang Weijun wrote:
>>> I agree with Sean.
>
ureRandom.AlgName ThreadSafe", "true");
or
putService(new Service(this, "SecureRandom", "AlgName", className,
null, Map.of("ThreadSafe", "true")));
{@code SecureRandom} will then call the applicable engine methods
without an
> On Oct 13, 2016, at 3:38 AM, Venkat Iyer (veniyer) wrote:
>
> Do you know if the problem of obtaining TGT session key on Windows from LSA
> credential cache is resolved (see snippet below)?
I am not sure. Sometimes you just cannot get the session key.
One way to check this is to run Microso
I agree with Sean.
--Max
> On Nov 3, 2016, at 10:00 PM, Sean Mullan wrote:
>
> You should only unset the jdk.jar.disabledAlgorithms property if a jarfile
> has been specified.
>
> Also, you are printing the warning message for all usages of the -printcert
> option, -ssl, etc, which is not co
Everything is fine now.
Thanks
Max
On 11/3/2016 9:38 AM, Artem Smotrakov wrote:
My bad, I missed that.
http://cr.openjdk.java.net/~asmotrak/8168882/webrev.02/
Artem
On 11/02/2016 06:30 PM, Wang Weijun wrote:
On 11/01/2016 11:59 PM, Wang Weijun wrote:
>> Main.java:
>>
>>
> On Nov 3, 2016, at 8:27 AM, Artem Smotrakov
> wrote:
>
> Hi Max,
>
> Please see inline.
>
>
> On 11/01/2016 11:59 PM, Wang Weijun wrote:
>> Main.java:
>>
>> The warning (and the subsequent empty line) should be printed into
>> Sy
> 在 2016年11月2日，21:50，Xuelei Fan 写道：
>
> I may change "the service provider attribute" to "the service attribute".
I didn't invent that name, I remember it's named exactly like this in one of
the security guides. Will check tomorrow, not near a big screen now.
Thanks
Max
> On Nov 2, 2016, at 9:18 PM, Xuelei Fan wrote:
>
> On 11/2/2016 8:47 PM, Wang Weijun wrote:
>>
>>> On Nov 2, 2016, at 5:34 PM, Xuelei Fan wrote:
>>>
>>> 1. More specific
>>>
>>> "A SecureRandom service provider can adver
; per your current implementation.
>
> "Otherwise, this class will ... "
OK.
>
> May need to update the implementation accordingly if you accept the comments.
Why update the implementation?
Thanks
Max
>
> Xuelei
>
>
> On 11/2/2016 3:27 PM, Wang Weijun
Ping again.
There is an updated version at
http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only changes.
Thanks
Max
> On Aug 25, 2016, at 10:00 AM, Weijun Wang wrote:
>
> Please review the enhancement at
>
> http://cr.openjdk.java.net/~weijun/7004967/webrev.00/
>
> Basically
Main.java:
The warning (and the subsequent empty line) should be printed into System.err.
Resources.java:
"This tool accepts any algorithm" is a little confusing (sorry that I
originally suggested it). Maybe "This tool does not attempt to verify a signed
jar file, please run \"jarsigner -verif
Webrev updated at
http://cr.openjdk.java.net/~weijun/8168518/webrev.02/
The only change in src/ is the system property name from
"jdk.krb5.rcache.usemd5" to "jdk.krb5.rcache.useMD5".
Test enhanced, now I can launch the test like
jtreg -javacoption:-XDignore.symbol.file \
-javacoption:-so
One question: I thought for TLS, you check twice. First using
jdk.tls.disabledAlgorithms on cipher suites etc, and second using
jdk.certpath.disabledAlgorithms on certificates. Why is
jdk.tls.disabledAlgorithms applied to cert at all?
Thanks
Max
On 10/27/2016 8:30 AM, Wang Weijun wrote:
I
I don't think this applies to jdk.jar.disabledAlgorithms. While the
private key algorithm and key size are determined by the certificate, I
think they are always checked even if the end-entity cert is trusted
(For example, a trusted self-signed cert).
Thanks
Max
On 10/27/2016 8:04 AM, Xuelei
No more
>> free setting.
>>
>> 3. Test fixed. I forgot to pass the system property to child process.
>>
>> Please also review the release note at
>> https://bugs.openjdk.java.net/browse/JDK-8168635.
>>
>> Thanks
>> Max
>>
>>&g
more free
setting.
3. Test fixed. I forgot to pass the system property to child process.
Please also review the release note at
https://bugs.openjdk.java.net/browse/JDK-8168635.
Thanks
Max
> On Oct 25, 2016, at 1:46 PM, Wang Weijun wrote:
>
>
>
> On 10/25/2016 1:40 PM, X
more information.
OK, I'll change the message.
Otherwise, looks fine to me.
Xuelei
On 10/25/2016 12:18 PM, Wang Weijun wrote:
http://cr.openjdk.java.net/~weijun/8168518/webrev.00/
Please read https://bugs.openjdk.java.net/browse/JDK-8168518 for the
reason. This code change includes:
1.
http://cr.openjdk.java.net/~weijun/8168518/webrev.00/
Please read https://bugs.openjdk.java.net/browse/JDK-8168518 for the reason.
This code change includes:
1. Add a hashAlg field in AuthTimeWithHash.java.
2. Add AuthTimeWithHash.DEFAULT_HASH_ALG so we can change it later.
3. The fix of the b
On Oct 21, 2016, at 10:31 AM, Rob McKenna wrote:Hi folks,Looking for a codereview and push approval for the following:bug: https://bugs.openjdk.java.net/browse/JDK-81633049 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a25dbe45e618 webrev: http://cr.openjdk.java.net/~robm/8163304/webrev.
Please review the code change at
http://cr.openjdk.java.net/~weijun/8167646/webrev.00/
A new flag invalid is added so invalid FilePermissions (invalid Path) do not
equal or imply or is implied by anything else except for itself.
Thanks
Max
Please review this test change:
diff --git a/test/sun/security/tools/jarsigner/TsacertOptionTest.java
b/test/sun/security/tools/jarsigner/TsacertOptionTest.java
--- a/test/sun/security/tools/jarsigner/TsacertOptionTest.java
+++ b/test/sun/security/tools/jarsigner/TsacertOptionTest.java
@@ -31,6 +
Please review the code change at
http://cr.openjdk.java.net/~weijun/8168127/webrev.00/
Two changes:
1. npath2 is considered in equals and hashCode of FilePermission, so 2 objects
with different npath2 can be added to a map and different entries.
2. special name for newPermUsingAltPath and n
Updated at
http://cr.openjdk.java.net/~weijun/8163304/webrev.02/
changes to webrev.01 is at
http://cr.openjdk.java.net/~weijun/8163304/webrev.02/interdiff.patch.html
Thanks
Max
> Am Wed, 19 Oct 2016 16:13:24 -0400
> schrieb Sean Mullan <
> sean.mullan at oracle.com
> >:
>
> >
> 150 "The jar will be treated as unsigned, because it
>
> >
> is signed with a weak algorithm that is now disabled.\n\nRe-run
>
> >
> jarsigner with the -verbose option for mor
content.
> 70 * with the file name itself the content.
>
> These 2 lines would be more understandable if you changed "itself the
> content" to "itself as the content".
Yes.
>
> * TimestampCheck.java
>
> You will need to update this test bas
Please review the code change at
http://cr.openjdk.java.net/~weijun/8163304/webrev.01/
With this change, "jarsigner -verify -verbose" will print out how a jar was
signed.
For example, a jar which was signed and timestamped with many weak algorithms
will show
- Signed by "CN=old"
Digest
Please take a review on this change:
diff --git
a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java
b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java
---
a/src/java.security.jgss/share/classes/javax/security/auth/kerbero
Please review the code change for jdk9/dev/jdk repo at
http://cr.openjdk.java.net/~weijun/8167181/webrev.00
and for jdk9/dev which is simply
diff --git a/make/CompileJavaModules.gmk b/make/CompileJavaModules.gmk
--- a/make/CompileJavaModules.gmk
+++ b/make/CompileJavaModules.gmk
@@ -452,10 +
> On Sep 28, 2016, at 7:59 AM, Xuelei Fan wrote:
>
>> Currently the tests silently quit which looks like they pass. This makes
>> people think that everything went smoothly, but actually nothing was
>> tested.
>>
> I did not get the idea.
I think what Artem meant is that without the platform n
Looking at the webrev, it looks we've never tested on "Linux-arm-32" and
"Linux-aarch64-64" before and we only realized it now. This is a true problem.
On the other hand, I also agree with Xuelei's concern. If a new platform is
added and it does not have NSS libs tests will fail.
How about this
> On Sep 22, 2016, at 8:34 AM, Xuelei Fan wrote:
>
> > latch = (latch + 1) & 0x7FFF; // Mask the sign bit
> I'm fine with it.
>
> BTW, if you like, I may suggest to use a little bit small number for the
> mask, for example 0x1FFF, so that the counter variable does not overflow
> eith
I am OK with your fix, but I found "(latch + 1) % Integer.MAX_VALUE" a little
difficult to understand. Does rndTab[latch & 0xff] also work?
Thanks
Max
> On Sep 21, 2016, at 11:57 PM, Jamil Nimeh wrote:
>
> Hi Max and Xuelei,
>
> Yesterday I also reached out to the SQE engineer who submitted
Change looks fine.
One question: When you say the --limit-modules option, is it a new option for
jtreg that allows it to automatically choose modules described in the @modules
tags? Or it's just the standard VM option and you still need to provide the
module names yourself?
Thanks
Max
> On Se
> On Sep 21, 2016, at 9:58 AM, Xuelei Fan wrote:
>
> 359 while (System.nanoTime() - startTime < 25000) {
> 360 synchronized(this){};
> - 361 latch++;
> + 361 latch = (latch + 1) % Integer.MAX_VALUE;
> 362 }
>
> This block may be not CPU friendly as it may loop a lar
1 - 100 of 734 matches
Mail list logo
