Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

In my understanding, the author deliberately wants to show the absolute paths when there are multiple jar files with the same name (Ex: a jar hell). Maybe we can add some more detail in the java.security so an admin knows what exact impact it has. --Max > On Sep 8, 2018, at 3:41 AM, Sean

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

> I adjusted the CSR , please approve : > > https://bugs.openjdk.java.net/browse/JDK-8207768 > > Best regards, Matthias > > > >> -Original Message- >> From: Weijun Wang >> Sent: Montag, 3. September 2018 17:14 >> To: Baesken, Matthias

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

pass in the full name ("/path/to/file.jar!META- >> INF/MANIFEST.MF") to "new Manifest(stream,name)" directly? >> >> So the name will be constructed in JarFile.java (after checking for >> jarPathInExceptionText). The getErrorPosition method simply c

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

ill be constructed in JarFile.java (after checking for jarPathInExceptionText). The getErrorPosition method simply concat the name (if not null) and the line number. Thus the exception thrown from parsing X.SF simply will not include any file info. If we want it we can enhance later. Thanks Max

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

Or you can smuggle it out through JavaUtilJarAccess with SharedSecrets. > On Aug 31, 2018, at 10:32 AM, Weijun Wang wrote: > > if we want to show the .SF name also, we will need a public API because > SignatureFileVerifier.java is inside sun.security.util. Something like

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

Sorry for making this complicated. Thanks Max > } > . > > > Best regards, Matthias > > > >> -Original Message- >> From: Weijun Wang >> Sent: Donnerstag, 30. August 2018 16:04 >> To: Baesken, Matthias >> Cc: Alan Ba

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

> On Aug 30, 2018, at 8:26 PM, Baesken, Matthias > wrote: > >> - What will the output look like? Is it "/tmp/x.jar:100"? >> > > Yes it look like this : > > line too long (/testdata/jars/file_with_long_line_1.jar:2) Is this a little misleading? I think you mean

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

ken, Matthias > wrote: > > Hi Max, thanks for your input . > > I created another webrev , this contains now the suggested > SecurityProperties class : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/ > > Best regards, Matthias > > > &

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

> On Aug 27, 2018, at 10:25 PM, Baesken, Matthias > wrote: > > Hi Alan , > >> Will sun.net.util.SocketExceptions be changed to use the supporting >> class or is that a separate issue? >> > > I think this is a separate issue . > >> In terms of approach then I think what you have is okay

Re: RFR[jdk8u-dev]: 8134124: sun/security/tools/jarsigner/warnings.sh fails when using Hindi locale

Changes looks fine. One day we can modify it to a Java program using SecurityTools::jarsigner. Thanks Max > On Jul 6, 2018, at 5:34 PM, Ramanand Patil wrote: > > Hi all, > Please review this trivial test fix: > Bug: https://bugs.openjdk.java.net/browse/JDK-8134124 > Webrev:

Re: RFR JDK-8066709 Make some JDK system properties read only

; different behavior and may be unpredictable. > > On 6/12/2018 10:10 PM, Weijun Wang wrote: >> In fact, why is setting user.name and user.home always evil? If I only want >> to set them on the command line so that a special "user environment" is >> used, why is it a pro

Re: RFR JDK-8066709 Make some JDK system properties read only

ot control the test runner's home directory. Thanks Max > On Jun 13, 2018, at 9:59 AM, Weijun Wang wrote: > > Hi Roger > > 1. Should all occurrences of reading of these system properties be updated? > For example, the following one is not touched > > http://hg.openjdk.

Re: RFR JDK-8066709 Make some JDK system properties read only

Hi Roger 1. Should all occurrences of reading of these system properties be updated? For example, the following one is not touched http://hg.openjdk.java.net/jdk/jdk/file/4d2e3f5abb48/src/java.base/share/classes/sun/security/tools/keytool/Main.java#l842 2. I assume that with this change not

Re: RFR JDK-8066709 Make some JDK system properties read only

Hi Roger Thanks for the explanation. Another question: Before this change, a SecurityException might be thrown when getProperty() is called, does you new code simulate this behavior? Or in these cases this is unnecessary? Also, looks like all change is inside java.base, do you have a

Re: RFR: JDK-8203839: API clarification: versioned jar entry verification in multi-release jar file

Looks fine to me. Thanks Max > On May 30, 2018, at 3:22 AM, Xueming Shen wrote: > > Hi, > > Please help review the proposed api spec update for JDK-8203839 (and its CSR) > > issue: JDK-8203839: API clarification: versioned jar entry verification in > multi-release jar file > csr:

Re: [11] RFR: 8202088: Japanese new era implementation

src/java.base/share/classes/sun/text/resources/FormatData.java @@ -106,6 +106,7 @@ "T", "S", "H", +"N", // New Era }; How about changing the comment to NewEra? When the name is available you can use grep to locate all places that need

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

https://stackoverflow.com/questions/27509061/macro-to-avoid-duplicate-case-value Someone has already used them in a switch expression... > On May 25, 2018, at 12:45 PM, David Holmes wrote: > >>> I also wonder whether a smart compiler might not flag code where the

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

> On May 25, 2018, at 11:58 AM, Ivan Gerasimov > wrote: > >> I also wonder whether a smart compiler might not flag code where the errors >> do infact have the same value: >> >> if (errno == 11 || errno == 11) ... >> > At least gcc -O completely removes the second

Re: [11] RFR: 8170769 Provide a simple hexdump facility for binary data

> On May 10, 2018, at 6:49 AM, Vincent Ryan wrote: > >> >> - As Max observes, being able to supply the delimiters might be a good >> addition. (I'm thinking IP addresses too). > > Sure. Add another toHexString method that takes a delimiter character? Good idea.

Re: [11] RFR: 8170769 Provide a simple hexdump facility for binary data

Nice tool. However, I am not sure how toFormattedHexString() and toPrintableString() are useful, seems only for providing a customizable dump format which is, actually, not very customizable. For me, toHexString and fromHexString are of course the most useful methods. As for dump, I can only

Re: Charsets for hex/base64

> On May 2, 2018, at 4:35 PM, Jonas Konrad wrote: > > "0a0b0c".getBytes(HexCharset.getInstance()) = new byte[] { 0x0a, 0x0b, 0x0c } > new String(new byte[] { 0x0a, 0x0b, 0x0c }, HexCharset.getInstance()) = > "0a0b0c" Normally a charset is to encode a string to byte[], but here

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

> On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie > wrote: > > https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth There is only one function to export and it already has JNIEXPORT, so you can just remove the new $(LIBJAAS_CFLAGS) [1].

Re: Cannot add attribute into main attributes of a jar if there is no version

> On Jan 30, 2018, at 8:57 AM, mandy chung <mandy.ch...@oracle.com> wrote: > > > > On 1/29/18 4:22 PM, Weijun Wang wrote: >> Ping again. >> >> >>> On Jan 22, 2018, at 1:12 PM, Weijun Wang <weijun.w...@oracle.com> >>> wrote: >

Re: Cannot add attribute into main attributes of a jar if there is no version

Ping again. > On Jan 22, 2018, at 1:12 PM, Weijun Wang <weijun.w...@oracle.com> wrote: > > src/java.base/share/classes/java/util/jar/Attributes.java: > > 329 @SuppressWarnings("deprecation") > 330 void writeMain(DataOutputStream out) throws

Re: RFR 8139206: Add InputStream readNBytes(int len)

+ * Therefore, the method may be safely called with very large values of + * {@code len} provided sufficient memory is available. What does "sufficient memory" mean? For len, or the number of available bytes? --Max > On Jan 23, 2018, at 4:49 AM, Brian Burkhalter

Re: RFR 8139206: Add InputStream readNBytes(int len)

t expected. I've checked some of the codes I wrote and each time readNBytes() can be used I only want the return value to be of exactly N bytes. Thanks Max > > $.02, Roger > > On 1/22/2018 5:42 AM, Weijun Wang wrote: >>> On Jan 22, 2018, at 5:01 PM, Weijun Wang <weijun.

Re: RFR 8139206: Add InputStream readNBytes(int len)

> On Jan 22, 2018, at 5:01 PM, Weijun Wang <weijun.w...@oracle.com> wrote: > > I wonder when readNBytes(n) will be useful if the return value has less than > n bytes. I mean I have seen protocols saying reading rest of the content, or reading N bytes, but never reading

Re: RFR 8139206: Add InputStream readNBytes(int len)

I wonder when readNBytes(n) will be useful if the return value has less than n bytes. > On Jan 22, 2018, at 4:52 PM, Alan Bateman wrote: > > > > On 17/01/2018 16:24, Brian Burkhalter wrote: >> : >> >> A negative value of ‘len’ will now cause an

Cannot add attribute into main attributes of a jar if there is no version

src/java.base/share/classes/java/util/jar/Attributes.java: 329 @SuppressWarnings("deprecation") 330 void writeMain(DataOutputStream out) throws IOException 331 { 332 // write out the *-Version header first, if it exists 333 String vername =

Re: RFR: 8189102: All tools should support -?, -h and --help

list. It prints the usage called with the flag, but > just because > it prints it on any wrong flag. > > So should I replace the comment here? > Or at least remove it? > > Best regards, > Goetz > >> -Original Message- >> From: Weijun Wang [mailto:weijun

Re: RFR: 8189102: All tools should support -?, -h and --help

help message and exit > -?, -h, --help print this help message > -?, -h, --helpprint this help message > -? -h --help Print this help message > -?, -h, --help[:compat]Give this, or optionally the compatibility, help > [-? -h --help]

Re: RFR: 8189102: All tools should support -?, -h and --help

I am OK with all commands supporting --help, but I am not sure if every tool should show it on the help screen if the tools's other options are still using the old single-"-" style. It looks like the tools are half-converted. Is there a timetable to add "--" support to all tools? Thanks Max >

Set a file readable/writable by owner only

I need to make a file rw only by the owner. How do you think of my code at the end? Especially, for the aclView case, I tried on Windows, and the result is like C:\>icacls x x NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) BUILTIN\Users:(I)(RX) Successfully processed 1 files;

Re: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar

Move to core-libs-dev. > On Sep 15, 2017, at 12:55 AM, Dominik Helm > wrote: > > I did not find a better place to report this, so I'm going to post it here: > > There is an obvious ArrayIndexOutOfBoundsException in >

Re: Scanning multi version jars?

> On Sep 14, 2017, at 5:07 PM, Alan Bateman wrote: > > On 13/09/2017 23:12, Greg Wilkins wrote: >> I hope this is the right group for this question. please redirect me if not. > Probably core-libs-dev as this isn't anything to do with modules but in any > case ... A

Re: RFR 8148371: Remove policytool

> On Sep 6, 2017, at 5:24 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > > > On 06/09/2017 05:17, Weijun Wang wrote: >> Hi All >> >> Please review the change, which spans to root, jdk and langtools repos. >> >> http://cr.ope

RFR 8148371: Remove policytool

Hi All Please review the change, which spans to root, jdk and langtools repos. http://cr.openjdk.java.net/~weijun/8148371/ I've searched for the "policytool" word in the whole jdk10/jdk10 forests, removed all files having the word inside the path name, and remove almost all occurrences of

Patch a DLL in JDK?

It's possible to patch classes with --patch-module but how do I shadow a DLL? I don't want to overwrite the existing one. I am talking about bin/w2k_lsa_auth.dll, which belongs to java.security.jgss. Thanks Max

Re: JDK 10 RFR of JDK-8183377: Refactor java/lang/ClassLoader/deadlock shell tests to java

> On Jul 14, 2017, at 4:23 PM, Mandy Chung wrote: > > >> On Jul 13, 2017, at 5:14 PM, Amy Lu wrote: >> >> java/lang/ClassLoader/deadlock/TestCrossDelegate.sh >> java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh >> >> Please review this patch to

Test after JDK-8181761, the explicit @build actions

Hi Igor I’ve about to add a new test that uses jdk.test.lib.SecurityTools and I see in your fix for JDK-8181761 that a lot of seemingly-unrelated classes are added into a @build action. How do I determine what classes are needed? Or shall I just copy it from a test nearby? I remember this

Re: Ping~ Re: RFR 8181080/10, Refactor several sun/net shell tests to plain java tests

On 06/06/2017 01:43 PM, Felix Yang wrote: Missed "Add back read access" before trying to delete it? Based on my test results (local and JPRT), it deleted w/o any exceptions. This was originally added by Max in https://bugs.openjdk.java.net/browse/JDK-7078355. TO Max, could you comment if

Re: RFR(S) : 8180888: move jdk.testlibrary.JarUtils to the top level testlibrary

Hi Igor Your change looks fine. BTW, the http://cr.openjdk.java.net/~iignatyev//8180888/webrev.00/jdk10.patch link is empty. Anything wrong with your version of webrev? Thanks Max On 05/31/2017 08:40 AM, Igor Ignatyev wrote:

Re: [9] RFR(S): 8178726: Can't load classes from classpath if it is a UNC share

I see some changes: - relative url won't be supported - path is no longer canonicalized Maybe these are no problem for URLClassPath. Just my 2 cents. --Max On 04/14/2017 04:41 PM, Alan Bateman wrote: On 13/04/2017 19:50, Volker Simonis wrote: Hi, can you please review the following

Re: [9] RFR 8177969: Faster FilePermission::implies by avoiding the use of Path::relativize

is doing so that it is easier to understand. --Sean On 4/7/17 10:50 AM, Weijun Wang wrote: Webrev updated at http://cr.openjdk.java.net/~weijun/8177969/webrev.01/ Changes since webrev.00 [1] 1. Copyright years. 2. Test fix. check() should include Windows drive tests like contains

Re: [9] RFR 8177969: Faster FilePermission::implies by avoiding the use of Path::relativize

/interdiff.patch.html On 04/05/2017 10:13 PM, Roger Riggs wrote: Hi Max, The code looks ok. How much faster does it make FilePermission compares? I assume if it is not accepted to be fixed in JDK 9, you will push it to JDK 10. Roger On 4/3/2017 11:30 AM, Weijun Wang wrote: http://cr.openjdk.java.net/~weijun

[9] RFR 8177969: Faster FilePermission::implies by avoiding the use of Path::relativize

http://cr.openjdk.java.net/~weijun/8177969/webrev.00/ This new implementation of containsPath(Path,Path) uses the logic of Path::relativize without directly calling it, which is much faster now. Thanks Max

Re: JDK 9 RFR of JDK-8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.group

The com/sun/jarsigner line should be added to jdk_security3. Roughly, the categories mean: 1: public APIs 2: JCE 3: implementation and private APIs 4: JGSS/krb5 Thanks Max On 03/27/2017 11:06 AM, Amy Lu wrote: jdk/internal/loader jdk/internal/util com/sun/jarsigner jdk/internal/agent

Compare a Path element to a string

Hi Alan I'm profiling the new FilePermission implementation and found a lot of time spending on comparing a Path to a string, and the path has only one element. Here are them: 1. Comparing with "-": Path lastName = npath.getFileName(); if (lastName != null &&

Re: How to profile in jdk9?

pling rate? Thanks Max On 03/17/2017 06:43 PM, Weijun Wang wrote: Sorry if the question reveals my ignorance. I need to profile with the latest jdk9 but everything I tried does not work: - hprof gone - try jvisualvm 1.3.9 but does not work with jdk9+161 on my Ubuntu. Even if I added 2 --add-opens

How to profile in jdk9?

Sorry if the question reveals my ignorance. I need to profile with the latest jdk9 but everything I tried does not work: - hprof gone - try jvisualvm 1.3.9 but does not work with jdk9+161 on my Ubuntu. Even if I added 2 --add-opens still got a blank window because "cannot load even default

Re: Is @deprecated javadoc comment still useful?

Hi Stuart This issue may be moot since this example (sun.security.tools.policytool.PolicyTool) is in a private package. I don't know if we deliver the javadoc output for this package. If not, then it doesn't really matter what you write for the @deprecated javadoc tag, or if you omit it

Re: Is @deprecated javadoc comment still useful?

Hi Remi On 03/08/2017 06:10 PM, Remi Forax wrote: attachments are skipped by the mailer daemon :( That's bad. The module page has: *Deprecated, for removal: This API element is subject to removal in a future version.* The policytool tool has been deprecated and is planned to be removed in

Is @deprecated javadoc comment still useful?

Hi, Mr Deprecator I'm adding @Deprecated annotations with arguments to a module and a class, and at the same time I add @deprecated javadoc comments. The resulting javadoc pages are attached. As you can see, the bold sentence (I assume it's generated from the annotation) and the line below

Re: RFR [JAXP] [TESTBUG] JDK-8175043 Multiple jaxp tests failing across platforms

Hi Frank You got the idea here correctly, that is to say, the path used in permission granting must match the style of how you access the file. The fix should work. On the other hand, the code change touches too many files. You'll need someone in the JAXP field to confirm if this is the

RFR: Release note for 8164705: Remove pathname canonicalization from FilePermission

before -> as before Brian On Sep 12, 2016, at 12:23 AM, Weijun Wang <weijun.w...@oracle.com <mailto:weijun.w...@oracle.com>> wrote: BTW, please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8165836 Thanks Max

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

mentioned in response to Alan’s comments all appear good. Thanks, Brian On Sep 1, 2016, at 7:25 AM, Weijun Wang <weijun.w...@oracle.com <mailto:weijun.w...@oracle.com>> wrote: Webrev updated at http://cr.openjdk.java.net/~weijun/8164705/webrev.01 Most suggestions from Alan accepte

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

On 9/13/2016 2:13, Brian Burkhalter wrote: Only picky comments: not sure but maybe change: 1) vice versa -> and vice versa 2) When it’s set to true -> When true 3) just like before -> as before All accepted. Thanks Max Brian On Sep 12, 2016, at 12:23 AM, Weijun Wang

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

BTW, please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8165836 Thanks Max On 9/1/2016 22:25, Weijun Wang wrote: Webrev updated at http://cr.openjdk.java.net/~weijun/8164705/webrev.01

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

in ReadFileOnPath.java. Still using "ugly" method names. Thinking they are clear enough. Thanks Max On 8/29/2016 20:18, Alan Bateman wrote: On 25/08/2016 04:55, Weijun Wang wrote: Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8164705/webrev.00 From the beginn

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

On 8/29/2016 20:18, Alan Bateman wrote: FilePermCompat is a ugly, particularly FilePermission changing its public fields. Do you prefer the traditional SharedSecrets way? SharedSecrets.setJavaIoFilePermissionAccess( new JavaIoFilePermissionAccessImpl()); Also method names like

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

wrote: On 25/08/2016 04:55, Weijun Wang wrote: Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8164705/webrev.00 From the beginning of JDK, FilePermission canonicalizes the input path and use the result in implies() and equals(). This has been a big performance hurt and

RFR 8164705: Remove pathname canonicalization from FilePermission

Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8164705/webrev.00 From the beginning of JDK, FilePermission canonicalizes the input path and use the result in implies() and equals(). This has been a big performance hurt and leads to confusing results when symlinks are

Re: How to change locale in a Windows terminal?

Mok wrote: Hi Max, Does setting -Duser.country=CN work for you? (I don't remember what the correct name for China should be, but setting that to US forces java to print the help message in English) - Kris On Tue, Aug 9, 2016 at 6:25 PM, Weijun Wang <weijun.w...@oracle.com <mailto:we

How to change locale in a Windows terminal?

My Windows 10 is English, but I want the java command to show Chinese help screen temporarily. I've tried "set LANG", chcp, "control intl.cpl,, /f:" but none works. Thanks Max

Re: RFR 8161965 -> Fwd: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

MY suggestions on 2 security-related modules: java.security.jgss: The {@code java.security.jgss} module defines and exports the interfaces and classes related to the Java binding of the Generic Security Services Application Program Interface (GSS-API). This module also includes GSS-API

OT: working directory of another drive on cygwin

In Windows, there is a concept called working directory of another drive. For example, in a cmd.exe windows, you can call cd d:\xyz and although you are now still in C:, but if you call "D:" to go to the D: drive, you will find yourself in d:\xyz. In fact, Paths.get("d:").toAbsolutePath()

How to write test requiring a specific locale?

Hi All In https://bugs.openjdk.java.net/browse/JDK-8133910, the test tries to grep certain text from tool output, but when the default locale is not en_US it might fail. I don't want to rewrite the test to check localized text so there are only 2 ways: 1. Force the text to run with en_US.

setOut() and redirectOutput() together

I am writing something like this ByteArrayOutputStream bout = new ByteArrayOutputStream(); System.setOut(out); System.out.println(Hello); ProcessBuilder pb1 = new ProcessBuilder(./native-app); pb1.redirectOutput(ProcessBuilder.Redirect.INHERIT); pb1.start(); Now Hello

Re: RFR 8064924: Update java.net.URL to work with modules

It should be checked, otherwise a non-initialized parent object comes into being. On 2/4/2015 22:38, Peter Levart wrote: Just a thought,... Is JVM bytecode verifier checking that a constructor chains to super constructor? If yes, we are ok. If not, specially crafted bytecode could skip

Re: [9] request for review: 8049171: Additional tests for jarsigner's warnings

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

Create a child class object based on a parent one

I have a class A and a sub class B. B contains no extra fields than A. Now there is an object of A and I want to create a B which is identical to it. What I am doing is public B(A old) { for (Field f: A.class.getDeclaredFields()) { if

hg: jdk8/tl/jdk: 8031572: jarsigner -verify exits with 0 when a jar file is not properly signed

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 +

hg: jdk8/tl/jdk: 8028351: JWS doesn't get authenticated when using kerberos auth proxy

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 !

hg: jdk8/tl/jdk: 8029181: ts.sh generates invalid file after JDK-8027026

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

.split(:).length?

Is this just changed? jdk8b118 shows 1 and now it's 0. Thanks Max

Re: .split(:).length?

On 11/19/13, 19:48, Weijun Wang wrote: Is this just changed? jdk8b118 shows 1 and now it's 0. Typo. b114. Thanks Max

Re: .split(:).length?

b114: 1 my (previous) own build: 0 I fetched changes for JDK-8028321 (the un-do) and now it's back to 1. So we are keeping this compatibility even if it does not look correct? Thanks Max On 11/19/13, 20:03, Alan Bateman wrote: On 19/11/2013 11:48, Weijun Wang wrote: Is this just changed

jar command shows bit length overflow

I just rebuild jdk8/tl on Windows and calling jar uvf shows a lot of bit length overflow code ?? bits ?-? A little grep shows jdk/src/share/native/java/util/zip/zlib-1.2.5/trees.c could print this. Something goes wrong or is it just me? Said that, it looks like the jar file is fine.

hg: jdk8/tl/jdk: 8028479: runNameEquals still cannot precisely detect if a usable native krb5 is available

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

hg: jdk8/tl/jdk: 8027991: InputStream should be closed in sun.security.tools.jarsigner.Main

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

hg: jdk8/tl/jdk: 8026929: remove accelerators from policytool resources

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 leif.samuels...@oracle.com !

hg: jdk8/tl/jdk: 8027026: Change keytool -genkeypair to use -keyalg RSA

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 !

SCTP build failure on Ubuntu 13.10

Just installed Ubuntu 13.10 and see this build failure /space/repos/jdk8/tl/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c: In function 'Java_sun_nio_ch_sctp_SctpChannelImpl_initIDs': /space/repos/jdk8/tl/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:86:24: error: unused

hg: jdk8/tl/jdk: 8026712: TEST_BUG: update sun/security/tools/keytool/autotest.sh with a new location to find of libsoftokn3.so

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 !

hg: jdk8/tl/jdk: 7025699: Policy Tool is not accessible by keyboard

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 leif.samuels...@oracle.com !

hg: jdk8/tl/jdk: 8025124: InitialToken.useNullKey incorrectly applies NULL_KEY in some cases

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 !

hg: jdk8/tl/jdk: 8026235: keytool NSS test should use 64 bit lib on Solaris

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

hg: jdk8/tl/jdk: 8024861: Incomplete token triggers GSS-API NullPointerException

Changeset: eb2c81533876 Author:weijun Date: 2013-09-27 15:25 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb2c81533876 8024861: Incomplete token triggers GSS-API NullPointerException Reviewed-by: mullan ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java +

hg: jdk8/tl/jdk: 8012615: Realm.getRealmsList returns realms list in wrong

Changeset: ee8b292ee568 Author:weijun Date: 2013-09-18 18:22 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee8b292ee568 8012615: Realm.getRealmsList returns realms list in wrong Reviewed-by: valeriep, xuelei ! src/share/classes/sun/security/krb5/Config.java !

hg: jdk8/tl/jdk: 8011402: Move blacklisting certificate logic from hard code to data

Changeset: 07d73060e0da Author:weijun Date: 2013-09-18 21:37 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07d73060e0da 8011402: Move blacklisting certificate logic from hard code to data Reviewed-by: erikj, mullan ! make/java/security/Makefile ! makefiles/CopyFiles.gmk !

hg: jdk8/tl/jdk: 8024046: Test sun/security/krb5/runNameEquals.sh failed on 7u45 Embedded linux-ppc*

Changeset: 6bfabb71ae1e Author:weijun Date: 2013-09-09 11:08 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6bfabb71ae1e 8024046: Test sun/security/krb5/runNameEquals.sh failed on 7u45 Embedded linux-ppc* Reviewed-by: xuelei ! test/sun/security/krb5/runNameEquals.sh

hg: jdk8/tl/jdk: 2 new changesets

Changeset: ca53110f1c74 Author:weijun Date: 2013-08-27 17:50 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca53110f1c74 8015669: KerberosPrincipal::equals should ignore name-type Reviewed-by: mullan ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java +

Re: RFR 8022761: SQE test regression on wrongly signed indexed jar file

Ping again. On 8/19/13 9:11 PM, Weijun Wang wrote: Hi Sherman I try out jar i after signing and it puts INDEX.LIST at the very beginning of the file. Does this mean INDEX.LIST was actually an exception? Or it just jari bug? Anyway, I think I should update the fix for 8021788 and here

RFR 8022761: SQE test regression on wrongly signed indexed jar file

usually be true because it only happens when you call jar i after signing a jar which means INDEX.LIST *is* unsigned. Thanks Max On 8/12/13 12:18 PM, Weijun Wang wrote: Hi Sherman SQE observes a regression in their test suite and the reason is my recent fix for 8021788 at http

A 8021788 regression? 8022761: SQE test regression on wrongly signed indexed jar file

Hi Sherman SQE observes a regression in their test suite and the reason is my recent fix for 8021788 at http://hg.openjdk.java.net/jdk8/tl/jdk/rev/758e3117899c The jar file mentioned contains 66 Mon Jun 04 15:42:18 CST 2007 META-INF/INDEX.LIST 323 Sat Apr 01 15:47:28 CST 2000

hg: jdk8/tl/jdk: 8016594: Native Windows ccache still reads DES tickets

Changeset: b7d594716f86 Author:weijun Date: 2013-08-08 21:13 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7d594716f86 8016594: Native Windows ccache still reads DES tickets Reviewed-by: dsamersoff, xuelei ! src/share/classes/sun/security/krb5/Credentials.java !

hg: jdk8/tl/jdk: 8021788: JarInputStream doesn't provide certificates for some file under META-INF

Changeset: 758e3117899c Author:weijun Date: 2013-08-09 11:41 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/758e3117899c 8021788: JarInputStream doesn't provide certificates for some file under META-INF Reviewed-by: chegar, sherman !

hg: jdk8/tl/jdk: 7151062: [macosx] SCDynamicStore prints error messages to stderr

Changeset: 906dd23334c1 Author:weijun Date: 2013-08-07 19:06 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/906dd23334c1 7151062: [macosx] SCDynamicStore prints error messages to stderr Reviewed-by: xuelei ! src/macosx/native/java/util/SCDynamicStoreConfig.m

Code review request: 8021788: JarInputStream doesn't provide certificates for some file under META-INF

Please take a look at http://cr.openjdk.java.net/~weijun/8021788/webrev.00/ The problem is that the method treats no META-INF entry as normal. If we can be sure that MANIFEST.MF and signature-related files are always at the beginning, we can safely treat an entry normal when we have done

hg: jdk8/tl/jdk: 8021789: jarsigner parses alias as command line option (depending on locale)

Changeset: 29f153e11683 Author:weijun Date: 2013-08-02 08:59 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29f153e11683 8021789: jarsigner parses alias as command line option (depending on locale) Reviewed-by: vinnie !

<    1   2   3   4   5   6   >