Now that we only check "localhost" and "localhost.localdomain", the
following hack in the SSL.java test is not necessary any more:
92 // Run this after KDC, so our own DNS service can be started
93 try {
94 server =
InetAddress.getLocalHost().getHostName().toLo
27; and
I've reverted the prompt to its previous value: 'Enter the password to be
stored'.
Let me know if there are any other issues. Otherwise I'd like to push this
today.
On 19 Sep 2013, at 00:51, Weijun Wang wrote:
Hi Vinnie
Mostly good, but do you need to add a help lin
This looks fine.
Thanks
Max
On 10/3/13 11:26 PM, Vincent Ryan wrote:
Sorry. I've just refreshed it now:
http://cr.openjdk.java.net/~vinnie/8008296/webrev.00
On 3 Oct 2013, at 15:08, Weijun Wang wrote:
I don't have other issues. Have you updated the webrev? I see no change.
The code change looks fine. Do we need a CCC for it?
Thanks
Max
p.s. I would use the bugs.openjdk.java.net URL.
On 10/9/13 2:14 AM, Vincent Ryan wrote:
Please review the following change - it's a simple re-factoring to promote a
nested class to a stand-alone class:
Bug: http://bugs.sun.com/b
Hi Vinnie
Please take a review at
http://cr.openjdk.java.net/~weijun/8026235/webrev.00/
Thanks
Max
This looks harmless. But it looks more like a jtreg issue if it cannot
deal with that slash.
I haven't noticed it failing on Windows before. Can you point me to a
jtr file.
Thanks
Max
On 10/10/13 8:56 AM, Jason Uh wrote:
Please review this fix. This changeset removes trailing slashes at the
Changeset: 74b4d20769fd
Author:weijun
Date: 2013-10-10 15:24 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74b4d20769fd
8026235: keytool NSS test should use 64 bit lib on Solaris
Reviewed-by: vinnie
! test/sun/security/tools/keytool/autotest.sh
Hi All
Please review the fix at
http://cr.openjdk.java.net/~weijun/7025699/webrev.00/
The fix includes porting PolicyTool from AWT to Swing, defining
mnemonics for menu items and buttons, and adding keyboard shortcuts for
the File -> New/Open/Save items. Several tests are updated also.
T
Please review the fix at
http://cr.openjdk.java.net/~weijun/8025124/webrev.00/
This is an interop fix. We used to determine if a NULL key should be
used based on etype being new or old, now we just look at the etype
inside the EncryptedData. If it's 0 then there is no need to decrypt it.
N
zeros.
Any is OK, since the expected differences are big enough. Your code
change is fine.
Thanks
Max
Xuelei
On 10/14/2013 10:57 AM, Weijun Wang wrote:
Isn't 9 too big here? If I understand correctly, the probability of the
bias being up to 9 is (1/256)^9. If this happens, you should real
f the
threading limitations imposed by Swing and how those are going to be
addressed?
--
best regards,
Anthony
On 10/12/2013 04:49 AM, Weijun Wang wrote:
Hi All
Please review the fix at
http://cr.openjdk.java.net/~weijun/7025699/webrev.00/
The fix includes porting PolicyTool from AWT to
Changeset: a70aab9b373e
Author:weijun
Date: 2013-10-16 14:39 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a70aab9b373e
8025124: InitialToken.useNullKey incorrectly applies NULL_KEY in some cases
Reviewed-by: xuelei
! src/share/classes/sun/security/jgss/krb5/InitialToken.ja
to add test after ZBB. Of course, only
if I can get the regression test running fine.
Thanks
Max
On 10/14/13 9:06 PM, Xuelei Fan wrote:
Looks fine to me.
Xuelei
On 10/12/2013 5:28 PM, Weijun Wang wrote:
Please review the fix at
http://cr.openjdk.java.net/~weijun/8025124/webrev.00/
This
Hi Vinnie
Please take a review at this fix
http://cr.openjdk.java.net/~weijun/8026712/webrev.00
It seems the PKCS11Test.java file also hardcoded the paths. But I don't
know what other archs to add.
Thanks
Max
multi-arch thing), so still
in /usr/lib/nss.
--Max
On 17 Oct 2013, at 12:03, Weijun Wang wrote:
Hi Vinnie
Please take a review at this fix
http://cr.openjdk.java.net/~weijun/8026712/webrev.00
It seems the PKCS11Test.java file also hardcoded the paths. But I don't know
what other
Changeset: 37e3dcb798c3
Author:weijun
Date: 2013-10-17 20:56 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37e3dcb798c3
8026712: TEST_BUG: update sun/security/tools/keytool/autotest.sh with a new
location to find of libsoftokn3.so
Reviewed-by: vinnie
! test/sun/security/to
Changeset: c1616a944d1c
Author:weijun
Date: 2013-10-18 08:57 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1616a944d1c
7025699: Policy Tool is not accessible by keyboard
Reviewed-by: alexp, weijun
Contributed-by: Leif Samuelsson
! src/share/classes/sun/security/tools/poli
In AccessController.java, existing doc always has a "specified" between
"the" and "{@code AccessControlContext}".
BTW, maybe a little off-topic, I am not sure about the exact meaning of
"with no permissions". jre/lib/security/java.policy has granted some
permissions (e.g. reading "java.version
There is a bug on Solaris on DSA keypair generation, and DSA related
test has a 1/256 probability to fail at signature verification. This fix
updates all non algorithm related "keytool -genkeypair" calls to using RSA.
Please take a review:
http://cr.openjdk.java.net/~weijun/8027026/webrev.0
Changeset: d545d67e2f68
Author:weijun
Date: 2013-10-23 08:32 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d545d67e2f68
8027026: Change keytool -genkeypair to use -keyalg RSA
Reviewed-by: alanb, chegar, mullan
! test/ProblemList.txt
! test/java/util/TimeZone/TimeZoneDatePer
Changeset: e9ec0ca5bab1
Author:weijun
Date: 2013-10-25 08:38 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9ec0ca5bab1
8026929: remove accelerators from policytool resources
Reviewed-by: alexp, weijun
Contributed-by: Leif Samuelsson
! src/share/classes/sun/security/tools/
Hi All
Please take a review at this small fix at
http://cr.openjdk.java.net/~weijun/8027991/webrev.00/
The bug is https://bugs.openjdk.java.net/browse/JDK-8027991.
Thanks
Max
Changeset: 7304b3195212
Author:weijun
Date: 2013-11-11 16:54 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7304b3195212
8027991: InputStream should be closed in sun.security.tools.jarsigner.Main
Reviewed-by: xuelei
! src/share/classes/sun/security/tools/jarsigner/Main.java
Please take a look at
http://cr.openjdk.java.net/~weijun/8028479/webrev.00/
The fix includes 2 parts:
1. krb5-config not checking gssapi. This does not work on Solaris. Only
krb5 is available there. With an argument, a default will be used
(usually krb5).
2. A 64-bit Linux might only have
Changeset: 7b71e53c6a2b
Author:weijun
Date: 2013-11-19 14:14 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b71e53c6a2b
8028479: runNameEquals still cannot precisely detect if a usable native krb5 is
available
Reviewed-by: xuelei
! test/sun/security/krb5/runNameEquals.sh
Why not just put the file in the current directory? That's the real
scratch dir. Or the cfg file needs an absolute path?
Also, is it necessary to remove the files in finally? If the test fails,
the files will be retained by jtreg so we can look into the reason. Or,
these lines are added to mak
Please take a look at
http://cr.openjdk.java.net/~weijun/8029181/webrev.00/
Not really harmful, but still an error.
Thanks
Max
bel to
the bug before you push.
--Sean
On 11/26/2013 10:06 AM, Weijun Wang wrote:
Please take a look at
http://cr.openjdk.java.net/~weijun/8029181/webrev.00/
Not really harmful, but still an error.
Thanks
Max
Changeset: 1738dfb0c52a
Author:weijun
Date: 2013-11-27 09:56 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1738dfb0c52a
8029181: ts.sh generates invalid file after JDK-8027026
Reviewed-by: vinnie, mullan
! test/sun/security/tools/jarsigner/TimestampCheck.java
Changeset: e1bc55ddf1ad
Author:weijun
Date: 2013-12-04 09:14 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1bc55ddf1ad
8028351: JWS doesn't get authenticated when using kerberos auth proxy
Reviewed-by: xuelei
! src/share/classes/com/sun/security/auth/module/Krb5LoginModule
It looks good. Would you like to add a string message?
Thanks
Max
On 12/10/13, 9:47, Jason Uh wrote:
Hi Vinnie,
The change looks good to me.
Jason
(Not an official Reviewer)
On 12/9/13 3:25 PM, Vincent Ryan wrote:
Please review this fix to the OCSPResponse class in the internal
sun.securit
Before the fix, when the client starts the 2nd read, it's 8000 MS pass
the beginning, and this read will timeout at 11000 MS, which is good
because the server writes at 1 MS. After the fix, when the client
starts the 2nd read, it's already 10500 MS and the server has already
written the dat
Overall it's good, but the exception dealing part can be cleaner.
230 Exception exception = null;
231
232 /*
233 * Check various exception conditions.
234 */
235 if ((local != null) && (remote != null)) {
236 // If both failed, return t
Hi All
Please review the code changes at
http://cr.openjdk.java.net/~weijun/8031046/webrev.00/
In 8016594, we updated Windows LSA retrieval so that when the existing
TGT has a session key whose etype is not supported by Java (say,
aes-256), we re-acquire one using the default_tkt_enctypes
Hi All
Please take a look at
http://cr.openjdk.java.net/~weijun/8028780/webrev.00/
New codes are added to check for the validity of input raw data so that
a proper exception (say, GSSException, IOException) is thrown instead of
unchecked ones like IllegalArgumentException, IndexOutOfBoundE
hPortionLen) {
Xuelei
On 12/30/2013 8:57 AM, Weijun Wang wrote:
Hi All
Please take a look at
http://cr.openjdk.java.net/~weijun/8028780/webrev.00/
New codes are added to check for the validity of input raw data so that
a proper exception (say, GSSException, IOException) is thrown instead o
ping again.
On 12/27/13, 17:59, Weijun Wang wrote:
Hi All
Please review the code changes at
http://cr.openjdk.java.net/~weijun/8031046/webrev.00/
In 8016594, we updated Windows LSA retrieval so that when the existing
TGT has a session key whose etype is not supported by Java (say,
aes
Changeset: 4d891c8db5c1
Author:weijun
Date: 2014-01-21 12:08 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d891c8db5c1
8031572: jarsigner -verify exits with 0 when a jar file is not properly signed
Reviewed-by: mullan
! src/share/classes/java/util/jar/JarFile.java
+ test/s
Vote： yes
--Max
On 1/28/2014 21:27, Sean Mullan wrote:
I hereby nominate Jason Uh to Membership in the Security Group.
Jason Uh is a member of the Java security libraries team at Oracle and
has been an active contributor to the OpenJDK security group for almost
2 years. Jason was voted in as a
Hi All
Please review the code changes at
http://cr.openjdk.java.net/~weijun/8035986/webrev.00/
It's about using IANA names in KerberosKey instead of old non-standard
names.
Thanks
Max
me.
I was wondering, whether it is a little bit more instinctive to return a
string with the type number for "unknown" and "private" algorithm in
KerberosKey.getAlgorithm(). For example:
"unknown" -> "kid-2014"
"private" -> "
On 4/9/2014 9:15, Xuelei Fan wrote:
On 4/9/2014 8:53 AM, Weijun Wang wrote:
There is already getKeyType() and toString().
;-) They should not lower the standards to design another good method.
I just meant different methods serve for different purposes.
Also I don't think
"ki
Hi All
These two tests were changed from @ignore to @manual in JDK-8033271.
They can be liberated into automatic tests. Please review the changes at
http://cr.openjdk.java.net/~weijun/8039575/webrev.00/
Thanks
Max
Hi All
Please review the code changes at
http://cr.openjdk.java.net/~weijun/8029994/webrev.01/
Two major changes made:
1. The include and includedir directives are supported now. Read
http://web.mit.edu/kerberos/krb5-current/doc/admin/conf_files/krb5_conf.html
for a description. The part
The code change looks harmless, but I am not sure how it could provide
more information next time.
--Max
On 4/10/2014 20:17, Xuelei Fan wrote:
Hi,
Please review this test case update:
http://cr.openjdk.java.net/~xuelei/8037557/webrev.00/
This is a test timeout issue. Cause is still un
So you want to see which line throws SocketTimeoutException?
What does that thread.join(12) do? Is it possible that after it
finishes no exception was thrown yet and your test shown as succeeded?
--Max
On 4/10/2014 20:45, Xuelei Fan wrote:
On 4/10/2014 8:42 PM, Weijun Wang wrote:
The
On 4/11/2014 7:10, Xuelei Fan wrote:
What does that thread.join(12) do? Is it possible that after it
finishes no exception was thrown yet and your test shown as succeeded?
IO exception should be thrown when the client cannot read and write.
This is what I am worried about:
Suppose serv
On 4/11/2014 10:15, Xuelei Fan wrote:
When line 374 get called, the test is nearly done (client complete its
jobs, and server accepted all connections).
If it's nearly done and no bad thing will happen, then you don't need to
call serverThread.join(12). Otherwise, you risk a false succes
Looks fine to me.
Thanks
Max
On 4/11/2014 10:58, Xuelei Fan wrote:
updated: http://cr.openjdk.java.net/~xuelei/8037557/webrev.01/
Please review the code changes at
http://cr.openjdk.java.net/~weijun/8036779/webrev.00/
The problem is that Java treats kdc_timeout as milliseconds but others
(NetBSD here) might treat it as seconds. With this code change, when the
number is <= 120, it's seconds, otherwise, milliseconds.
dc_timeout spec (for example, using the known
platform) of the underlying configuration?
Xuelei
On 5/14/2014 8:38 AM, Weijun Wang wrote:
> Please review the code changes at
>
> http://cr.openjdk.java.net/~weijun/8036779/webrev.00/
>
> The problem is that Java treats kdc
On 5/14/2014 19:51, chris...@zoulas.com wrote:
On May 14, 2:04pm, weijun.w...@oracle.com (Weijun Wang) wrote:
-- Subject: =?utf-8?Q?=E7=AD=94=E5=A4=8D:_RFR_8036779:_sun.security.krb5.KdcC
| What do you mean by detecting the platform? So if I find the file is also u=
| sed by NetBSD krb5 then
On 5/14/2014 15:19, Xuelei Fan wrote:
On 5/14/2014 2:04 PM, Weijun Wang wrote:
What do you mean by detecting the platform? So if I find the file is
also used by NetBSD krb5 then I treat it as second and if not
millisecond?
Yes.
That's quite impossible. In my opinion, it all depends o
On 5/15/2014 9:27, Xuelei Fan wrote:
On 5/14/2014 8:24 PM, Weijun Wang wrote:
How is this unsafe, especially compared to if we don't fix it? The only
bad thing is that if someone wants to set the timeout to be less than
120 ms, now there will be no way to do it. But that should never h
On 5/28/2014 3:46, Sean Mullan wrote:
Ok. The fix looks fine to me, though it looks like the code in the 2
methods is very similar - could it be refactored into a common method?
Yes, it's now
http://cr.openjdk.java.net/~weijun/8036709/webrev.02/
Thanks
Max
Hi Mala
Code change looks fine.
When you say "Direct backport", is it equivalent to "applying the same
patch with no conflict"? :-)
Thanks
Max
On 8/5/2014 17:32, mala bankal wrote:
HI,
Request review for the direct backport of bug# 8031046 to 7u-dev.
http://cr.openjdk.java.net/~mbankal/80
On 8/6/2014 17:04, Erik Joelsson wrote:
Speaking of indentation, please also change the ifdef bodies to 2 spaces.
Sure. Whenever I edit a Makefile, I dare not use spaces and always use
TABs. Obviously an ifdef does not need it.
Thanks
Max
On 8/6/2014 20:55, Xuelei Fan wrote:
Weijun,
Where the krb5 impl will be packaged into in the future?
In the java.jgss module.
Still the
SunProvider but in a new jar file? I was wondering whether we can use
the provider service approach that we used to define other security
components im
I actually don't understand the details in the program. For example,
what does the different ReadModels mean? In each case, what bytes are
actually write into the streams? There are too many on and off and I
don't know what the program is doing.
Thanks
Max
On 08/19/2014 10:05 PM, zaiyao liu w
.read() and dos.on() *after* dos.write().
Is it possible to change the order so that I can easily see if the
read/write has any effect on the digest?
Thanks
Max
On 08/19/2014 10:29 PM, Weijun Wang wrote:
I actually don't understand the details in the program. For example,
what does the
Webrev updated at
http://cr.openjdk.java.net/~weijun/8042900/webrev.01/
as per Alan's suggestions.
Can anyone in the security team take a look?
Thanks
Max
I'd like other jgss/krb5-related tests also there:
test/sun/security/krb5 \
test/sun/security/jgss \
test/com/sun/security/jgss \
test/javax/security/auth/kerberos \
Is that OK?
Thanks
Max
On 9/10/2014 1:10, Seán Coffey wrote:
On some recent JPRT test jobs, I'v
On 12/4/2014 19:57, Xuelei Fan wrote:
These are calls with SHA (i.e. SHA1) or SHA2 in the stack
(depth=4), and time for SHA2 vs SHA1 is 45.38% vs 1.09%.
Where is the other 98.91% cost for SHA1? You only call message digest
in the test, instinctively, shall most of the resources are cost by t
I'd like to check if "SHA-256" is supported without calling
MessageDigest.getInstance("SHA-256"). Does such a method exist?
My case is a multi-thread digestor like this:
class Digestor {
Digestor(String alg) throws NSAE;
@ThreadSafe byte[] digest(byte[]) throws Nothing;
}
So a Digestor i
On 1/7/2015 14:26, Michael StJohns wrote:
Actually,www.rfc-editor.org/rfc/rfc.txt is probably a better long term
normative reference for documents in the RFC series.
Why?
I think Jamil's tools.ietf.org/html/rfc is better. The xml2rfc tool
generates this style.
--Max
Mike
On 1/23/2015 16:12, Artem Smotrakov wrote:
If the MANIFEST and the signature files must be at the beginning, should
it be considered as a bug in jarsigner? Should it reject such files?
I think so. Will file a bug.
The "jar u" way is to copy each old entry into destination unless the
entry
Ah yes, a whitespace was mistakenly removed. Please review my fix at
http://cr.openjdk.java.net/~weijun/8071562/webrev.00/
It's simply
cmd = System.getProperty("java.home") + "/bin/jarsigner";
}
- cmd += System.getProperty("test.tool.vm.opts")
+ cmd += " " + System.get
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8071643/webrev.00/
The static field is removed and a local MessageDigest is used. The
getInstance() method might spend some time but since there are already
quite some cipher and checksum operations during an AP-REQ
Hi All
A test helper tries to parse the "test.src.path" system property using
delimiter ":". This is not correct on Windows.
The fix is simply
diff --git a/test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java
b/test/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java
--- a/test/lib/
Hi All
Please review this change at
root: http://cr.openjdk.java.net/~weijun/8071338/root/webrev.00/
jdk: http://cr.openjdk.java.net/~weijun/8071338/jdk/webrev.00/
No actual java code change, just move everything inside the
s.s.t.policytool into another module. There are other make/test chang
Hi All
Please review the fix at
http://cr.openjdk.java.net/~weijun/8073181/webrev.00/
The old honored code have 2 problems:
1. type not read if bare name without critical suffix
2. extension not added if critical flag is not modified
Thanks
Max
Please review the fix at
http://cr.openjdk.java.net/~weijun/8073182/webrev.00/
This fix stores extensions inside CertificateExtensions using OID as key
so there will never be a type duplicate.
Existing test updated.
Thanks
Max
Yes, that line has 354 chars. There are quite a lot of long lines there,
maybe because keytool command is usually long. In fact, 43 lines are
longer than 150 chars, 345 lines longer than 80 chars. Shall I fix all
of them?
Thanks
Max
On 2/18/2015 3:42, Sean Mullan wrote:
Also, unrelated to yo
Hi Sean
Please review the change at
http://cr.openjdk.java.net/~weijun/8073853/webrev.00
After the change, the output of the following command does not change at
all.
javac -g:vars,source KeyToolTest.java
Thanks
Max
Looks fine.
Thanks
Max
On 2/26/2015 4:41, Amanda Jiang wrote:
Hi All,
Could you please review following changeset for 1 new test, which check
various combinations of permissions to execute the code from a signed
jar file.
Bug: https://bugs.openjdk.java.net/browse/JDK-8048360
webrev: http://cr
Empty:
- 29: I am not a fan of import static using like this, but you are free
to do anyway
- 34: "with expected message". You didn't check if the message is
expected, you only check if it's empty
- 39, 41, 43, 51: left brace should go back to previous lines
- line 48 and 49 can be fit in one
There is no problem the new API be in a separate module. It is
independent of keytool now.
Said that, I've been thinking about rewriting keytool to use this new API.
--Max
On 3/5/2015 16:23, Alan Bateman wrote:
On 05/03/2015 02:55, Wang Weijun wrote:
- Move keytool to jdk.security.util, it's
So what's your suggestion on their future?
A: Remove them and say "they are removed" in a "Changed since" section.
B: Move them to an appendix and say "they will not be developed anymore
and please do not use them".
C: Keep them in the old section and say "they will not be developed
anymore
Please review the change at
http://cr.openjdk.java.net/~weijun/8075575/webrev.00
The test checks for certain English text in the output, and cannot find
if running in another locale. Tests now forced running in English.
I've tried modifying the tests to check for localized texts returning
Hi All
Webrev updated at http://cr.openjdk.java.net/~weijun/8056174/webrev.01/.
Major changes:
1. JarSignerException is now a RuntimeException, no more ErrorCode
2. Action.java and Builder.java moved into sun.security.tools.jarsigner.
Hopefully the jarsigner tool can use them.
The code chan
Ping again.
On 3/26/2015 1:28 PM, Weijun Wang wrote:
Please review the change at
http://cr.openjdk.java.net/~weijun/8075575/webrev.00
The test checks for certain English text in the output, and cannot find
if running in another locale. Tests now forced running in English.
I've
Hi Artem
These are splendid tests. So do they just all pass? :-)
One question, does the policy file make any difference in
UnboundSSLMultipleKeys.java and UnboundSSLPrincipalProperty.java?
Thanks
Max
On 4/21/2015 10:41 PM, Artem Smotrakov wrote:
Hello,
Please review a couple of new tests f
Hi Artem
In StandardCallbacks.java, you provide an array of callbacks with an
unsupported one at the end, hoping all supported ones are processed
before the last one fails. It is very natural for a LoginModule
implementation to process them one by one in their original order (like
what Custom
Hi Daniel
Thanks for the report.
In fact, the bug behind the changeset you mentioned -- 8048194 -- was
just meant to make your case work. Before that, the server blindly
accepts the mechToken and process it no matter if the OID is supported.
Now it first looks at the OID and accept the token
call should be in a loop
until a context is established, and then you can call getSrcName(). Can
you try that? Hopefully after the client sees the server request for a
1.2.840.113554.1.2.2 mechToken it can send one and the server can go on.
Thanks
Max
On 4/23/2015 7:22 AM, Weijun Wang wrote:
Smotrakov wrote:
Hi Max,
On 04/22/2015 05:51 PM, Weijun Wang wrote:
Hi Artem
These are splendid tests. So do they just all pass? :-)
Yes, fortunately they do :)
One question, does the policy file make any difference in
UnboundSSLMultipleKeys.java and UnboundSSLPrincipalProperty.java?
No, these
All codes fine.
Thanks
Max
On 4/23/2015 2:18 PM, Artem Smotrakov wrote:
Hi Max,
Please see inline.
On 04/22/2015 06:24 PM, Weijun Wang wrote:
Hi Artem
In StandardCallbacks.java, you provide an array of callbacks with an
unsupported one at the end, hoping all supported ones are processed
s
application protocol has this loop defined.
Does the above make sense? Please do get in touch if I an provide any
other assistance in helping with the issue, and thanks again to everyone
looking into it.
Thanks.
On Thu, Apr 23, 2015 at 1:58 AM, Weijun Wang mailto:weijun.w...@oracle.com
Hi Joe
The changes look good.
I remember last time when Stuart updated JDK to use diamond there was a
rule that if the assignment of a variable is a little far from its
definition, then we don't use diamond. It seems we are not obeying it
anymore?
Thanks
Max
On 4/24/2015 6:34 AM, Joseph D.
Hi All
Please review a fix at
http://cr.openjdk.java.net/~weijun/8078495/webrev.00
which is essentially
GetSystemTimeAsFileTime(&Now);
EndTime.dwLowDateTime = msticket->EndTime.LowPart;
EndTime.dwHighDateTime = msticket->EndTime.HighPart;
-
Hi All
Please review a fix at
http://cr.openjdk.java.net/~weijun/8078439
This is a regression triggered by JDK-8048194. In SPNEGO, a client might
send NegTokenInit with OIDs being {MS_KRB5_OID, KRB5_OID} along with a
krb5 AP-REQ as mechToken. Java did not understand MS_KRB5_OID but before
myself, I find out that it does not
accept the "correct" ID and fail. Why didn't people notice that? My
understanding is that until now a client that sends those OIDs has
always been a browser, and this browser simply ignores the response if
it already sees a "200 OK" HTTP st
Looks fine.
Thanks
Max
On 4/23/2015 6:31 PM, Artem Smotrakov wrote:
Agree.
Please see an updated webrev:
http://cr.openjdk.java.net/~asmotrak/8075007/webrev.02/
Artem
On 04/23/2015 11:18 AM, Weijun Wang wrote:
One question:
As for the 3 boolean flags you added to KDC.java (BTW, maybe
On 4/28/2015 6:14 PM, Daniel Jones wrote:
I noticed in the bug report Internet Explorer is mentioned. We see the
same behaviour with IE, Firefox and Chrome.
Thanks. I've mentioned that in the comment.
BTW, are you able to build jdk yourself? If so, can you try out the fix?
http://cr.openj
in code review and not in dev repo yet.
--Max
Cheers!
On Tue, Apr 28, 2015 at 12:43 PM, Weijun Wang mailto:weijun.w...@oracle.com>> wrote:
On 4/28/2015 6:14 PM, Daniel Jones wrote:
I noticed in the bug report Internet Explorer is mentioned. We
see the
s
Maybe you can call JAVA_OPTS.trim().split("\\s+") to avoid the filtering.
And it seems Collections.addAll() can add an array to a list.
Of course, you are free to exercise any fancy jdk8 features. :-)
Thanks
Max
On 4/29/2015 3:23 PM, Artem Smotrakov wrote:
Hello,
Please review this fix for
j
eptor -> acceptor
2) line 59, currently, this test will accept all GSSException as the
expected exception which may be a little bit too liberal. Any chance
that we can narrow it down to a certain error status code? Just so we
don't accidentally allow the wrong exceptions.
Thanks,
Valerie
Is it safe to just run for-each on certs (if it's not null)?
--Max
On 5/2/2015 6:39 AM, Vincent Ryan wrote:
Please review this fix to correct the PKCS12 encoding when a secret key is
being stored in one keystore entry and a certificate in another.
Thanks.
Bug: https://bugs.openjdk.java.net/
me forget about simpler ways :-)
Please take a look
http://cr.openjdk.java.net/~asmotrak/8076486/webrev.01/
Thanks!
Artem
On 04/29/2015 05:04 PM, Weijun Wang wrote:
Maybe you can call JAVA_OPTS.trim().split("\\s+") to avoid the filtering.
And it seems Collections.addAll() can ad
Ping again.
On 4/24/2015 11:29 AM, Weijun Wang wrote:
Hi All
Please review a fix at
http://cr.openjdk.java.net/~weijun/8078495/webrev.00
which is essentially
GetSystemTimeAsFileTime(&Now);
EndTime.dwLowDateTime = msticket->EndTime.
301 - 400 of 3227 matches
Mail list logo
