1662 for (int i = 0; i < chainLen; i++) {
On 5/4/2015 6:08 PM, Vincent Ryan wrote:
Which line?
On 2 May 2015, at 02:22, Weijun Wang wrote:
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 thi
Looks fine.
Thanks
Max
On 5/5/2015 8:49 AM, Jason Uh wrote:
Please review this fix, which enables parsing of X400Address-type
Subject Alternative Names.
webrev: http://cr.openjdk.java.net/~juh/8058543/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8058543
Jason
array on each iteration of the outer
loop but it doesn’t seem to gain much overall.
On 4 May 2015, at 13:10, Weijun Wang wrote:
1662 for (int i = 0; i < chainLen; i++) {
On 5/4/2015 6:08 PM, Vincent Ryan wrote:
Which line?
On 2 May 2015, at 02:22, Weijun Wang wrote:
Is
r (int i = 0; i < chainLen; i++) {
+for (int i = 0; i < certs.length; i++) {
// create SafeBag of Type CertBag
DerOutputStream safeBag = new DerOutputStream();
safeBag.putOID(CertBag_OID);
On 5 May 2015, at 15:10, Weijun
}
-for (int i = 0; i < chainLen; i++) {
+for (int i = 0; i < certs.length; i++) {
// create SafeBag of Type CertBag
DerOutputStream safeBag = new DerOutputStream();
safeBag.putOID(CertBag_OID);
On
als policy.two.principals
NestedActionsTwoPrincipals.jar WriteToFileAction.jar
ReadFromFileAction.jar ReadPropertyAction.jar
...
But anyway, I added trim(), so now the test doesn't rely on jtreg.
Please take a look:
http://cr.openjdk.java.net/~asmotrak/8076486/webrev.02/
Artem
On 05/04/20
I think they are good, at least for those wrong tags or @params with
wrong names. It's always nice to use correct format even if the doc is
not published.
You're welcomed to fix other docs in java.security.* or jdk.security.*
modules.
Is there a handy tool so that we don't make same mistakes
Hi Valerie
Please review the code change at
http://cr.openjdk.java.net/~weijun/803/webrev.00/
The codes to read local addresses are updated. We are also supporting
the extra_addresses krb5.conf setting.
This code change triggers a bug (MSOID2.java) in a test I've recently
added, plea
Hi All
Please take a look at
http://cr.openjdk.java.net/~weijun/8077102/webrev.00/
Before this fix, dns_lookup_realm true is by default. This is not
consistent with other krb5 vendors. It also leads to lot of time waste
when Kerberos 5 is not configured at all.
The no-krb5.conf test case
Hi All
This is about the bug
https://bugs.openjdk.java.net/browse/JDK-8058290
I'm now thinking that with renewTGT=true we should always renew the
ticket no matter if it's new or old. This means the TGT will be always
the latest inside the subject.
How is your opinion? The source fix will
Hi Vinnie
Is there any reason why they cannot be simply created in the current
directory?
In fact, if you put them there, then you don't need to clean them up
because jtreg will do that for you. If the test fails some day, they
will be retained for your diagnostics.
Thanks
Max
On 5/13/201
The code change looks fine.
If it were me, I won't do any clean up.
--Max
On 5/14/2015 11:14 PM, Vincent Ryan wrote:
That makes more sense. I’ve updated the webrev in place.
On 14 May 2015, at 15:29, Weijun Wang wrote:
Hi Vinnie
Is there any reason why they cannot be simply creat
Code change is fine.
Thanks
Max
On 5/21/2015 12:58 AM, Ivan Gerasimov wrote:
Hi!
The backport required some manual editing, thus I'm asking for a review
too.
Would you please review and approve backporting this fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8077102
WEBREV: http://cr.op
NEED_UNWRAP_AGAIN:
So you are asking the user to call unwrap() on nothing? Or no matter
what the argument is you just don't touch it? I'd rather see a new
status NEED_PROCEED and a new method proceed() that has no argument at all.
Tests:
I see you send/receive data with DatagramSocket. Not s
Looks good.
Are you also going to remove the policy.ignoreIdentityScope definition
inside jdk\src\java.base\share\conf\security\java.security?
Thanks
Max
On 5/22/2015 10:25 PM, Sean Mullan wrote:
This is the second in a series of fixes for JEP 232 (Improve Secure
Application Performance) [1
On 5/23/2015 1:52 AM, Sean Mullan wrote:
After further thought, I think it makes sense to leave the property in
for now.
The one change I will make is to add a sentence to the java.security
file that the default JDK policy provider does not support this
property. This is just documenting existin
On 5/23/2015 3:20 AM, Simone Bordet wrote:
Hi,
On Fri, May 22, 2015 at 9:14 PM, Bernd Eckenfels wrote:
I would suggest to make this encoded in latin1 instead. This is
supposed to be a 8bit clean encoding (and will be compatible to all
ASCII only strings). It is still ugly and needs to be doc
On 5/23/2015 9:13 AM, Bradford Wetmore wrote:
Weijun wrote:
> But in the RFC the name is in uppercase and chars in string are all
> lowercases.
> ...deleted...
> - Compare with equalsIgnoreCase()
Not following here, the spec is specific about the over-the-wire byte
values, and http/1.1 !=
Hi All
Please review a code change at
http://cr.openjdk.java.net/~weijun/8080911/webrev.00/
I've limit the synchronized block to Config creation only and therefore
won't deadlock with EType's class initialization.
Noreg-hard. The EType call is at class initialization and only run once
in
ot be common in production, but I don't want
to make any behavior change.
--Max
[1] https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.6
Xuelei
On 5/25/2015 10:16 PM, Weijun Wang wrote:
Hi All
Please review a code change at
http://cr.openjdk.java.net/~weij
On 5/26/2015 9:22 AM, Xuelei Fan wrote:
On 5/26/2015 9:06 AM, Weijun Wang wrote:
On 5/26/2015 7:59 AM, Xuelei Fan wrote:
synchronized on class looks a little bit unsafe to me.
Why? Isn't it the same as making a static method synchronized? [1]
Other code may be also able to lock on
This is the latest webrev of this bug
http://cr.openjdk.java.net/~weijun/8038089/webrev.06/
No significant change from the previous one, mainly rebase.
There are some issues which need changes inside JSSE. I'd like to file
another bug for them.
1. JsseJce.java still uses core reflection t
n.
Xuelei
On 5/26/2015 10:40 AM, Weijun Wang wrote:
On 5/26/2015 9:22 AM, Xuelei Fan wrote:
On 5/26/2015 9:06 AM, Weijun Wang wrote:
On 5/26/2015 7:59 AM, Xuelei Fan wrote:
synchronized on class looks a little bit unsafe to me.
Why? Isn't it the same as making a static method synchroniz
Oh, not the last one. Here is a new one that uses String instead of
CipherSuite.KeyExchange in the service interface. 1) below is thus resolved.
http://cr.openjdk.java.net/~weijun/8038089/webrev.07/
Thanks
Max
On 5/26/2015 11:32 AM, Weijun Wang wrote:
This is the latest webrev of this bug
There are several places you write
// DTLS bans stream ciphers.
if (suite.cipher.cipherType == CipherType.STREAM_CIPHER) {
return true;
}
According to rfc6347
4.1.2.5. New Cipher Suites
Upon registration, new TLS cipher suites MUST indica
Please review the fix below:
diff --git
a/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java
b/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java
---
a/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCr
Hi Darwin
Thanks for looking into this file. Most of your words are correct, but
I'd like to explain what was behind those changesets.
See comments below.
On 5/21/2015 3:58 PM, Seán Coffey wrote:
FYI,
concerns from Darwin on the 8078439: 8048194 fixes.
regards,
Sean.
Forwarded Me
ot sure at the momemnt) which is
impossible for a SPNEGO token. Furthermore, if we really want to worry
about it, we will need to expand the length octets from 2 bytes to 3
bytes and it will be much more complicated.
Thanks
Max
Valerie
On 5/8/2015 8:00 AM, Weijun Wang wrote:
Hi Valerie
Please r
Hi Sean
Everything is fine, some comments:
FilePermission (also in SocketPermission, PropertyPermission,
ServicePermission):
int oldMask = ((FilePermission)existingVal).getMask();
int newMask = ((FilePermission)newVal).getMask();
if (oldMask != newMask) {
int effective = o
ServicePermission:
We can also add a ServicePermission(String,int) like FilePermission has.
--Max
http://cr.openjdk.java.net/~mullan/webrevs/8065942-8056179/webrev.00/
Great. Everything is fine.
Thanks
Max
On 06/08/2015 10:24 PM, Sean Mullan wrote:
On 06/05/2015 11:24 PM, Weijun Wang wrote:
ServicePermission:
We can also add a ServicePermission(String,int) like FilePermission has.
Good point. Updated webrev:
http://cr.openjdk.java.net/~mullan/webrevs
Hi Sean
I remember you mentioned that although no name lookup is performed here
the permissions will be calculated correctly, even if they are granted
to different host strings which are actually equivalent (your new test
proves this). The URL strings still must be resolved somewhere else to
1478 final int plast = restrictedPkg.length() - 1;
Why is it named plast?
1494//- we check that restrictedPkg.length is pkg.length + 1,
1495//- we check that restrictedPkg starts with pkg,
1496//- and we check that the last character in restrictedPkg
1497/
Possibly - but that would be a behavioral change. The current test:
plast == plen && restrictedPkg.startsWith(pkg) &&
restrictedPkg.charAt(plast) == '.'
is strictly equivalent to the old test:
restrictedPkg.equals(pkg + ".")
Yes, I understand.
Right, and this is an interesting observatio
This fix is also a part for JEP 232 (Improve Secure Application
Performance) [1].
webrev: http://cr.openjdk.java.net/~weijun/8064890/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8064890
The fix uses a ConcurrentHashMap to avoid synchronization.
Note:
1. ConcurrentHashMap does not
Change looks fine.
Thanks
Max
On 6/18/2015 7:00 AM, Rajan Halade wrote:
May I request you to review small fix to CheckBlacklistedCerts test to
correctly determine if OpenJDK build is used.
Webrev: http://cr.openjdk.java.net/~rhalade/8060103/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/
Hi Amanda
The test looks fine.
Thanks
Max
On 2/26/2015 4:54 AM, Amanda Jiang wrote:
Hi All,
Could you please review following changeset, which includes one new test
to test permission checks with Subject.getPrivateCredentials.
Bug: https://bugs.openjdk.java.net/browse/JDK-8050409
Webrev:http
I might have found a reason for SunMSCAPI crash
http://cr.openjdk.java.net/~weijun/8023546/webrev.00
Before this fix, the native function convertToLittleEndian() fails if
you want to convert a 63 byte array to a 64 byte one. However, I
observed that when a 1024 bit RSA private key is generat
Hi Amanda
I'd rather see 5 JAAS conf files directly included (instead of
generating them with codes). Then it seems you can write a single test
with 5 @run lines.
Thanks
Max
On 6/20/2015 6:33 AM, Amanda Jiang wrote:
Hello,
Please help to review following changeset, which includes new tests
Hi Michael
Webrev updated at
http://cr.openjdk.java.net/~weijun/8023546/webrev.01
I added a check about the extra sign byte, I even added a null check in
KeyStore.java, although if the fix is done right they should never happen.
The return value of the convertToLittleEndian() function is n
On 06/24/2015 11:26 PM, Sean Mullan wrote:
Also, https://bugs.openjdk.java.net/browse/JDK-8025202 might be a
duplicate. The symptoms look similar.
Yes. Closed.
--Max
Please review the code change at
http://cr.openjdk.java.net/~weijun/8058290/webrev.00/
After this fix, a "renewTGT=true" in JAAS config for Krb5LoginModule
means "renew if old enough", as suggested by the bug reporter [1].
Thanks
Max
[1] https://bugs.openjdk.java.net/browse/JDK-8058290
Good.
Do you need me pushing it for you?
--Max
On 06/25/2015 07:33 PM, Artem Smotrakov wrote:
Sure, http://cr.openjdk.java.net/~asmotrak/delegation_permission/webrev.02/
Artem
On 06/25/2015 02:14 PM, Sean Mullan wrote:
Looks good. There is an incorrect period at the end of line 152, can
you
Please review the fix at
http://cr.openjdk.java.net/~weijun/8069253/webrev.00/
This is about an intermittent test failure that shows
Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
at java.util.ArrayList.add(ArrayList.java:461)
at CipherTestUtils.addFailure(CipherTestUtils.java:314)
L
Please review the fix at
http://cr.openjdk.java.net/~weijun/8058849/webrev.00
The overridden NamingManager needs to return a Context object whose
getAttributes() method returns hard coded data. Since Context includes a
lot of interface methods, choosing a non-abstract child and only
overri
On 06/29/2015 04:02 PM, Alan Bateman wrote:
In any case, the change looks okay to me. Trivially, I think I would use
specific imports rather than changing it a wildcard.
IntelliJ IDEA automatically does this for me:
1. I am typing InitialDirCo and it hints InitialDirContext, I accept it
2.
Hi Siba
There is one case not covered:
1. sun.security.krb5.principal not set
2. an existing principal set in jaas.conf
In your jaas.conf.principal, a non-existing 1USER principal is used. In
fact, why not add both accounts into the KDC and then check if the login
user is what you expected?
t/browse/JDK-8130112]
Thanks,
Siba
-Original Message-----
From: Weijun Wang
Sent: Tuesday, June 30, 2015 7:45 AM
To: Sibabrata Sahoo; Security Libs OpenJDK
Subject: Re: [9] RFR: 8075301: Tests for sun.security.krb5.principal system
property
Hi Siba
There is one case not covered:
Hi All
Please take a look at
http://cr.openjdk.java.net/~weijun/8130112/webrev.00/
You only need to read the jdk.patch file. Basically I just remove the
@modules tags in each test and combine them into a single TEST.properties.
Two other small changes:
1. HttpNegotiateServer no longer us
Hi All
Please review the fix at
http://cr.openjdk.java.net/~weijun/8130720/webrev.00/
As the bug description [1] says, at this stage, when k1 and k2 are on,
although the most likely output is 1212 (try #1 without preauth,
succeeds; try #1 with preauth, succeed), the actual output we spotte
Hi Iris
The change to S11N.java looks fine.
Thanks
Max
On 07/08/2015 01:48 AM, Iris Clark wrote:
Hi.
Please review changes to resolve the following bug:
8130696: Security Providers need to have their version numbers updated
for JDK 9 (Verona)
Bug: https://bugs.openjdk.java.net/browse/JDK-81
One major question:
Is it necessary for one side to send both the status and the data to its
peer? Your server side does not read the status but the client uses it.
And some style things:
81-86: "new String[] { QOP_AUTH }" is defined as authQop on line 90. Why
not move lines 88-93 to the beg
Hi All
Please take a look at the fix at
http://cr.openjdk.java.net/~weijun/8131051/webrev.00/
When a ticket request has a ticket_lifetime that the KDC considers too
long it will issue a renewable ticket with a shorter lifetime.
Unfortunately, JDK does not accept this.
Thanks
Max
ther comments:
http://cr.openjdk.java.net/~asmotrak/8049814/webrev.02/
Artem
On 07/12/2015 06:47 PM, Weijun Wang wrote:
One major question:
Is it necessary for one side to send both the status and the data to
its peer? Your server side does not read the status but the client
uses it.
And some style things:
The logic in RefreshKrb5Config.java is very good. Why not also try
NotRefreshable again after writing the correct krb5.conf in BogusKDC.java?
Thanks
Max
On 07/16/2015 01:38 PM, Artem Smotrakov wrote:
Hello,
Please review a couple of new tests that check that:
- Kerberos client tries slave KDC
Hi All
Please take a look at
http://cr.openjdk.java.net/~weijun/8131350/webrev.00/
Policytool contains a lot of hard coded strings for permission class
names, which can be changed to actual Class types. That allows checking
at compile-time rather than failing at run-time if any name had a
One final point.
You have the timeout set to 5 minutes in
+ * @run main/othervm/timeout=300 BogusKDC
Did you observe the test spending a lot of time? A kerberos client is
designed to timeout after 30 seconds if there is no reply from a KDC but
sometimes it could be very fast if the KDC does
Although the java.security.krb5.kdc/realm system properties are able to
override the values inside krb5.conf, it is better to write one without
realm/kdc info at all. So, instead of
60 KDC.saveConfig(KRB5_CONF_FILENAME, kdc, "max_retries = 1");
How about just manually write
Files
e-use existing KDC.saveConfig(). It is just shorter.
Artem
On 07/17/2015 04:19 PM, Weijun Wang wrote:
Although the java.security.krb5.kdc/realm system properties are able
to override the values inside krb5.conf, it is better to write one
without realm/kdc info at all. So, instead of
The change looks fine.
That said, is CodeSource's hashCode/equals used somewhere else? I mean,
can we directly update them?
Thanks
Max
On 07/18/2015 05:32 AM, Sean Mullan wrote:
One of the changesets for JEP 232 (Improve Secure Application
Performance) introduced a regression in the Protecti
A new version at
http://cr.openjdk.java.net/~weijun/8131350/webrev.01/
"public" modifiers of methods/fields inside Prin/Perm and child classes
removed.
Thanks
Max
On 07/16/2015 09:43 PM, Weijun Wang wrote:
Hi All
Please take a look at
http://cr.openjdk.java.net/~weij
On 07/20/2015 07:37 AM, Sean Mullan wrote:
On 07/17/2015 08:00 PM, Weijun Wang wrote:
The change looks fine.
That said, is CodeSource's hashCode/equals used somewhere else? I mean,
can we directly update them?
It might affect third party policy providers. We would also need to
updat
+jdk.security.jgss
jdk.rmic
Thanks
Max
On 07/18/2015 08:26 AM, Weijun Wang wrote:
A new version at
http://cr.openjdk.java.net/~weijun/8131350/webrev.01/
"public" modifiers of methods/fields inside Prin/Perm and child classes
removed.
Thanks
Max
On 07/16/2015 09:43 PM, W
, it issues a ticket with a
lifetime of 10 hours, but makes it renewable with 2 days
Thanks
Max
On 07/13/2015 05:12 PM, Weijun Wang wrote:
Hi All
Please take a look at the fix at
http://cr.openjdk.java.net/~weijun/8131051/webrev.00/
When a ticket request has a ticket_lifetime that the KDC
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8132111/webrev.00/
Java Kerberos was designed to provide the addresses of a service when
requesting for a forwarded TGT. However, the field was never filled,
because of a bug that the service principal does not have
Hi Artem
First, you shouldn't need any @modules here, the sun/security/krb5/auto
already contains a TEST.properties file covering everything. For the
same reason, you should place KinitConfPlusProps.java somewhere inside
auto. If you think a subdir is better, put it into auto/tools.
Back to
Hi All
JDK 9 is more restricted on calling sun.* public methods but we know
there are users calling sun.security.tools.jarsigner.Main to sign jar
files. A new API is proposed for this very purpose in OpenJDK. Please
note it is defined in a jdk.* package therefore not a Java SE API. We
are als
Everything is fine.
One thing in AuthPermission.java:
+ * {@link javax.security.auth.login.LoginContext}, and
+ * {@link javax.security.auth.login.Configuration} objects.
I remember you can add an additional label in {@link}, otherwise, the
text is too long.
Thanks
Max
On 08/07/2015 04:06 AM
On 08/11/2015 07:47 PM, Sean Mullan wrote:
On 08/10/2015 10:47 PM, Weijun Wang wrote:
Everything is fine.
One thing in AuthPermission.java:
+ * {@link javax.security.auth.login.LoginContext}, and
+ * {@link javax.security.auth.login.Configuration} objects.
I remember you can add an
Hi Sergey
Sorry for the late reply. The change looks fine.
If you want me to push it, please show me the changeset block you like,
including contributed-by or your openjdk id if you already had an author
role.
Thanks
Max
On 08/05/2015 08:09 PM, Sergey Kuksenko wrote:
Hi All,
Please review
useless. A user can modify a
setting and create another JarSigner.
--Max
Mandy
On Aug 8, 2015, at 6:56 AM, Weijun Wang wrote:
Hi All
JDK 9 is more restricted on calling sun.* public methods but we know there are
users calling sun.security.tools.jarsigner.Main to sign jar files. A new API is
There are something I don't understand.
MyConfiguration.java:
- optionOrder: Is it possible to make this an argument of the constructor?
- getConfiguration/setConfiguration: If these are useless, why adding
these methods?
SmartLoginModule.java:
- initialize: Why don't you use the callbackHa
Hi All
Please take a look at the draft JEP at
https://bugs.openjdk.java.net/browse/JDK-8051408
With this JEP, we'd like to add new pure-Java SecureRandom
implementations to OpenJDK, which are based on DRBG mechanisms in NIST
SP 800-90Ar1 [1].
According to 800-90C [3], RBG (SecureRandom i
PKCS10AttrOrder.java:
- Why not inline revAttributes(), prov() and constructMap()? They are
only used once. Putting the content into the main method is more clear.
- You can create separate method for the while look checks. The 2 look
identical.
PKCS10AttributeReader.java:
- Is it OK to in
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8056174/webrev.02/
A new JarSigner public API is introduced to OpenJDK. The code change
chooses a two-layer implementation style, with public JarSigner/Builder
in jdk.security and private JarSignerX/BuilderX in sun.s
Typo, short method names.
(Strange, I was typing in Linux and no auto-correct is on).
--Max
On 08/24/2015 09:56 PM, Weijun Wang wrote:
I am still using should method names
Please take a look at
http://cr.openjdk.java.net/~weijun/8077670/webrev.00/
The test now tries to find an available port in a loop.
Thanks
Max
don't know the specifics of this test, but can it use the ephemeral
port pattern, ds = new DatagramSocket(); ds.getLocalPort()? Rather than
looping.
-Chris.
On 26/08/15 08:57, Weijun Wang wrote:
Please take a look at
http://cr.openjdk.java.net/~weijun/8077670/webrev.00/
The test now tri
Great it works for me.
Webrev updated at http://cr.openjdk.java.net/~weijun/8077670/webrev.01/.
Thanks
Max
On 08/26/2015 10:11 PM, Weijun Wang wrote:
Hi Chris
I don't know about that method. Will try.
This test is trying to start a UDP server that does nothing so that its
client rec
Please review
http://cr.openjdk.java.net/~weijun/8134555/webrev.00/
The test was mistakenly removed in a previous changeset. Restored now.
Thanks
Max
This looks good.
Thanks
Max
On 08/31/2015 04:58 PM, Vincent Ryan wrote:
Please review this spec change in java.security.KeyStore to clarify that a
keystore integrity check is not performed when a null password is supplied.
Thanks.
Webrev: http://cr.openjdk.java.net/~vinnie/8130800/webrev.00/
Updated a little: rewrite of jarsigner tool itself using the JarSigner
API included. Still at the same URL below.
--Max
On 08/24/2015 09:56 PM, Weijun Wang wrote:
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8056174/webrev.02/
A new JarSigner public API is
Please review this spec clarification at
http://cr.openjdk.java.net/~weijun/8129789/webrev.00
Thanks
Max
Hi Sean
You closed 8016345 as a dup of 8007706, but it's about the 1st letter in
a DNSName and 8007706 is about '_' inside. Should they be treated
differently?
Thanks
Max
On 09/08/2015 12:52 PM, k...@sg.ibm.com wrote:
I have a question on one of the bug
described at
https://bugs.openjdk.jav
On 09/08/2015 08:32 PM, Sean Mullan wrote:
On 09/08/2015 02:15 AM, Weijun Wang wrote:
Hi Sean
You closed 8016345 as a dup of 8007706, but it's about the 1st letter in
a DNSName and 8007706 is about '_' inside. Should they be treated
differently?
Yes, probably. Please
wrote:
On 09/01/2015 02:50 AM, Weijun Wang wrote:
Updated a little: rewrite of jarsigner tool itself using the JarSigner
API included. Still at the same URL below.
I notice that you don't use the new JarSigner API at all in the
jarsigner tool and go straight to the BuilderX/JarSignerX cl
Missing from the webrev, some extra lines needed in modules.xml of the
parent repo jdk9/dev:
jdk.jartool
java.base
com.sun.jarsigner
+
+ jdk.security.jarsigner
+
Thanks
Max
On 09/22/2015 09:12 AM, Weijun Wang wrote:
OK, webrev updated at
Max,
Thanks for your comments ,please check updated webrev and my replies
inline.
webrev: http://cr.openjdk.java.net/~amjiang/8050427/webrev.02/
Regards,
Amanda
On 8/17/15, 12:29 AM, Weijun Wang wrote:
There are something I don't understand.
MyConfiguration.java:
- optionOrder: Is it poss
a.net/~amjiang/8050427/webrev.03/
Thanks,
Amanda
On 9/22/15, 6:45 PM, Weijun Wang wrote:
OK, the code is much easier to understand now.
In some places, there are modern and simple ways to code. For example,
in SmartLoginModule.java,
170 // verify the username/password
171 bo
Hi Lance
I've updated policytool to match your new SQLPermission target names,
webrev at:
http://cr.openjdk.java.net/~weijun/6845220/webrev.00/
It seems there's an extra name "setNetworkTimeout" (compared with
original RFE description) in your latest changeset at:
http://hg.openjdk
Changeset: f7915efcba1b
Author:weijun
Date: 2010-09-13 09:32 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f7915efcba1b
6845220: Need to update Policytool for Rowset 1.1 and JDBC 4.1 MR added
permissions
Reviewed-by: lancea
! src/share/classes/sun/security/tools/policytool
Changeset: 5c3bad1d7f8a
Author:weijun
Date: 2010-09-14 10:18 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5c3bad1d7f8a
6982840: sun/security/tools/jarsigner/emptymanifest.sh fails
Reviewed-by: dholmes
! test/sun/security/tools/jarsigner/emptymanifest.sh
Changeset: ca630e91d473
Author:weijun
Date: 2010-09-23 10:46 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ca630e91d473
6982971: TEST failure: com/sun/security/sasl/ntlm/NTLMTest.java
Reviewed-by: wetmore
! test/com/sun/security/sasl/ntlm/NTLMTest.java
Changeset: 9eb9485ec45b
Author:weijun
Date: 2010-09-25 10:21 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9eb9485ec45b
6986868: TEST failure: sun/security/tools/jarsigner/crl.sh
Reviewed-by: ohair
! test/sun/security/tools/jarsigner/crl.sh
Changeset: 26c6ee936f63
Author:weijun
Date: 2010-09-29 15:26 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/26c6ee936f63
6988163: sun.security.util.Resources dup and a keytool doc typo
Reviewed-by: xuelei
! src/share/classes/sun/security/tools/KeyTool.java
! src/share/classe
Changeset: dfce5a0cc460
Author:weijun
Date: 2010-10-28 21:14 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dfce5a0cc460
6950546: "ktab -d name etype" to "ktab -d name [-e etype] [kvno | all | old]"
6984764: kerberos fails if service side keytab is generated using JDK ktab
Re
Changeset: 856843c444a0
Author:weijun
Date: 2010-11-06 09:11 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/856843c444a0
6997740: ktab entry related test compilation error
Reviewed-by: valeriep
! test/sun/security/krb5/auto/MoreKvno.java
! test/sun/security/krb5/auto/SSL.jav
Changeset: e27ad63b0f54
Author:weijun
Date: 2010-11-09 08:34 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e27ad63b0f54
6952519: kdc_timeout is not being honoured when using TCP
Reviewed-by: valeriep
! src/share/classes/sun/security/krb5/KrbKdcReq.java
+ src/share/classes/s
Changeset: 4565d120e514
Author:weijun
Date: 2010-11-11 15:51 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4565d120e514
6987827: security/util/Resources.java needs improvement
Reviewed-by: valeriep
! src/share/classes/com/sun/security/auth/NTDomainPrincipal.java
! src/share
Changeset: 1e7dc87fad95
Author:weijun
Date: 2010-11-12 21:33 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1e7dc87fad95
6960894: Better AS-REQ creation and processing
Reviewed-by: valeriep
! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
! src/share/cla
401 - 500 of 3227 matches
Mail list logo
