Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue

On 12/11/18 10:38 AM, Baesken, Matthias wrote: File paths are, in general, always something that demands extra scrutiny as it can be the source of security issues (privacy leaks, traversal attacks, etc). It's not just me that thinks that way, you can do a search on the Internet and find lots of

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

The API link should be http://cr.openjdk.java.net/~vinnie/8170769/javadoc.06/api/java.base/java/util/Hex.htm --Sean On 11/23/18 9:51 AM, Vincent Ryan wrote: Hello, Please review this proposal for a new API to conveniently generate and display binary data using hexadecimal string

Re: RFR: 8148188: Enhance the security libraries to record events of interest

/shared_selection_certificateId.png/Screenshot%20from%202018-11-16%2015%3a28%3a59.png Regards, Sean. On 14/11/18 21:09, Seán Coffey wrote: Hi Sean, comments inline.. On 13/11/2018 18:53, Sean Mullan wrote: Looking good, a couple of comments/questions: * src/java.base/share/classes/java/security/Security.java

Re: RFR: 8148188: Enhance the security libraries to record events of interest

On 11/13/18 1:53 PM, Sean Mullan wrote: * src/java.base/share/classes/sun/security/x509/X509CertImpl.java  158 // Event recording cache list  159 private List recordedCerts; Shouldn't this be static? Otherwise each certificate would have it's own instance and duplicates would

Re: RFR: 8148188: Enhance the security libraries to record events of interest

SE properties and JDK properties. Hmm, I was reviewing v7, and the name was changed in v8. I think isJdkSecurityProperty method is a better name. --Sean --Max On Nov 14, 2018, at 2:53 AM, Sean Mullan wrote: * src/java.base/share/classes/java/security/Security.java The isJdkSecurityProp

Re: RFR: 8148188: Enhance the security libraries to record events of interest

Looking good, a couple of comments/questions: * src/java.base/share/classes/java/security/Security.java The isJdkSecurityProperty method could return false positives, for example there may be a non-JDK property starting with "security.". I was thinking it would be better to put all the JDK

Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue

ctory user names, etc? Once we understand if there are any security issues, then we can decide if allowing that via a system property is acceptable or not, and if so the security risks that we would have to document for that property. Thanks, Sean Thanks, Matthias -Original Messag

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

726 * The VM recoginizes this method as special, so any changes to the s/recoginizes/recognizes/ --Sean On 11/3/18 4:00 PM, dean.l...@oracle.com wrote: I made a pass at improving the comments based on feedback I've received.  I updated webrev.4 in place, along with an incremental diff:

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 11/1/18 3:21 PM, dean.l...@oracle.com wrote: On 11/1/18 9:48 AM, Sean Mullan wrote: On 11/1/18 1:29 AM, dean.l...@oracle.com wrote: On 10/31/18 9:39 PM, Bernd Eckenfels wrote: http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Some of the copyrights need to be updated to 2018. All else looks good to me as I had reviewed an earlier version of this before. We have talked about doing this for a while now, so I am finally glad we and are able to pretty much eliminate one of the more common SecurityManager related

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 11/1/18 1:29 AM, dean.l...@oracle.com wrote: On 10/31/18 9:39 PM, Bernd Eckenfels wrote: http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html In checkContext should the security manager be null checked first instead

Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue

On 10/12/18 10:33 AM, Langer, Christoph wrote: Sean, what is your take on this? Sorry, I haven't had time to look at this in more detail yet. But, let's take a step back first. Can you or Matthias explain in more detail why this fix is necessary? What are the use cases and motivation? The

Re: RFR: 8211860: Avoid reading security properties eagerly on Manifest class initialization

Looks good to me. --Sean On 10/8/18 11:24 AM, Claes Redestad wrote: Hi, JDK-8207768 cause a noticeable regression in a subset of our startup tests due eagerly loading security.properties for getting a property that's only used in exceptional circumstances. Ensuring Manifest doesn't eagerly

Re: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

, Sean On 03/10/2018 13:12, Sean Mullan wrote: For those of you that are not also subscribed to security-dev, this is mostly FYI, as the review is winding down, but if you have any comments, let me know. This change will add new token options ("allow" and

Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

issue and spec changes: https://bugs.openjdk.java.net/browse/JDK-8203316 Thanks, Sean Forwarded Message Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable Date: Tue, 2 Oct 2018 11:34:09 -0400 From: Sean Mullan Organization: Oracle Corpor

Re: SSL session cache default maximum number of entries

On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan" wrote: Hi Paul, Thank you for bringing this issue to our attention. While we agree that this does indeed seem like an issue that should be addressed, it is quite late in the JDK 11 schedule, a

Re: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped

On 9/13/18 7:52 PM, Stuart Marks wrote: I'd guess that security-dev would have reviewers for the change to default.policy. Cc'd. The default.policy file change looks like this is not specifically related to this change because the jdk.desktop module no longer exists. I guess it is ok to

Re: SSL session cache default maximum number of entries

as the "javax.net.ssl.sessionCacheSize" system property to customize the cache size. --Sean On 9/11/18 12:02 PM, Sean Mullan wrote: cross-posting to security-dev since this is related to SSL/TLS. On 9/11/18 11:41 AM, Hohensee, Paul wrote: The default value for the maximum number of entries in the SSL session ca

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

On 9/11/18 8:14 AM, Langer, Christoph wrote: Hi, first of all, I suggest to use "jarDetails" instead of "jarPath" as category name. Because with this contribution we add the notion of jar file plus line of manifest to Exceptions occurring when parsing jar manifests. And if there were further

Re: SSL session cache default maximum number of entries

cross-posting to security-dev since this is related to SSL/TLS. On 9/11/18 11:41 AM, Hohensee, Paul wrote: The default value for the maximum number of entries in the SSL session cache (which is a SoftReference cache) is infinite, and the entry timeout is 24 hours. With larger heaps, we’re

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

On 9/10/18 9:59 AM, Baesken, Matthias wrote: New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.9/ - SocketExceptions class has been adjusted to new sun.security.util.SecurityProperties - Attributes getErrorPosition adjusted (see proposal of Christoph " I think it would

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

On 9/10/18 4:21 AM, Baesken, Matthias wrote: I think it would be enough to drop the privileged section and just return "filename" as is. (without conveting to a file object). OK, any objections on this ? No, this is fine with me. --Sean

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

On 9/8/18 11:42 AM, Wang Weijun wrote: 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

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

ation such as the user.home system property even if it has not been granted permission to do so." I think we should consider not allowing this property to take effect if a SecurityManager is running. --Sean --Max On Sep 8, 2018, at 3:41 AM, Sean Mullan wrote: On 8/29/18 10:01 AM, Baesken, Matthias

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

On 8/29/18 10:01 AM, Baesken, 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/ java/util/jar/Attributes.java 469 return

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

On 8/27/18 10:25 AM, Baesken, Matthias wrote: 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 . I think we should fix it as part of this issue. It shouldn't be hard and then we don't have to file another

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

On 8/13/18 11:18 AM, Baesken, Matthias wrote: As Chris and Alan mentioned, you should move the parsing of the property to a more general location so it can be used by other code that uses this property. Hi Sean, Thanks for the input and comments . Could we do the moving of the property

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

ccodeguide-139067.html#7 - Attributes.java As Chris and Alan mentioned, you should move the parsing of the property to a more general location so it can be used by other code that uses this property. --Sean On 8/8/18 11:00 AM, Sean Mullan wrote: Cross-posting to security-dev since this fix is security

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

Cross-posting to security-dev since this fix is security related and should also be reviewed there. --Sean On 8/7/18 11:00 AM, Baesken, Matthias wrote: Ping  , any reviews / comments ? Thanks , Matthias -Original Message- From: Baesken, Matthias Sent: Dienstag, 31. Juli

Re: [11] RFR: 8208691: Tighten up jdk.includeInExceptions security property

On 8/7/18 3:09 AM, Alan Bateman wrote: On 06/08/2018 20:23, Sean Mullan wrote: After further evaluation of the new jdk.includeInExceptions security property originally introduced in JDK-8204233 [1] and further generalized in JDK-8207846 [2], I felt that a stronger warning should be added

Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces

Looks fine to me. --Sean On 8/6/18 3:11 PM, joe darcy wrote: Hello, Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to suppress future planned serial lint

[11] RFR: 8208691: Tighten up jdk.includeInExceptions security property

After further evaluation of the new jdk.includeInExceptions security property originally introduced in JDK-8204233 [1] and further generalized in JDK-8207846 [2], I felt that a stronger warning should be added to the description of the property alerting the user to the potential risks of

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

On 7/23/18 6:09 AM, Chris Hegarty wrote: After given this some more thought, I now think that I gave in to the comment to change whitespace handing too easy. While maybe not consistent, with the already inconsistent, whitespace handling in java.security, I think ( for this particular case ) the

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

On 7/20/18 11:08 AM, Chris Hegarty wrote: This is ambiguous, and needs to be clarified. Surely, it is better to use the same wording as the serial filter: "Whitespace is significant and is considered part of the value." Kind of on the fence on that one. If this were a general property/value

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

On 7/19/18 8:54 AM, Chris Hegarty wrote: On 19 Jul 2018, at 11:46, Alan Bateman wrote: On 19/07/2018 09:07, Baesken, Matthias wrote: Hello, in the meantime I prepared a CSR : https://bugs.openjdk.java.net/browse/JDK-8207768 jdk.includeInExceptions expands the scope. That might be okay

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

I think it is worth putting a stronger warning in each of the methods (and not just the class description) of StaticProperty that additional care should be taken when using these methods since there is no SecurityManager check. For example: "{@link SecurityManager#checkPropertyAccess} is NOT

Re: RFR: 8202419: Avoid creating Permission constants early

Looks fine to me. I think the TO DO comment on line 131 of ReflectionFactory can be removed - it looks like a leftover comment which doesn't seem relevant anymore. --Sean On 4/30/18 8:25 AM, Claes Redestad wrote: Hi, moving a couple of local permission constants to

Re: [11] RFR: 8193032: Remove terminally deprecated SecurityManager APIs

On 3/27/18 11:26 AM, Alan Bateman wrote: On 27/03/2018 16:15, Sean Mullan wrote: Please remove this change to remove several SecurityManager methods that have been marked for removal since Java SE 9: checkTopLevelWindow, checkSystemClipboardAccess, checkAwtEventQueueAccess

[11] RFR: 8193032: Remove terminally deprecated SecurityManager APIs

Please remove this change to remove several SecurityManager methods that have been marked for removal since Java SE 9: checkTopLevelWindow, checkSystemClipboardAccess, checkAwtEventQueueAccess, and checkMemberAccess. These methods no longer have any benefit, and removing them will follow

Re: RFR 8197595: Serialization javadoc should link to security best practices

Looks good to me. Minor nit, I would add "the" before "Secure Coding Guidelines for Java SE". I would also change "must" to "should" as these are recommended best practices, and not requirements that we can enforce. --Sean On 3/23/18 10:12 AM, Roger Riggs wrote: Please review adding a

Re: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only the permissions it really needs to expose the bean

Try running with -Djava.security.debug=access:domain:failure This will tell you what ProtectionDomain caused the AccessControlException, which should give you a better idea of where the problem is. Look for messages that start with "domain that failed ". --Sean On 11/14/17 1:22 AM,

Re: Manifest Related Bugs JDK-6372077, JDK-6202130, JDK-8176843, JDK-4842483, JDK-6443578, JDK-6910466, JDK-4935610, and JDK-4271239

Hi Phillip, All of these bugs are in the core-libs area, so I am copying the core-libs-dev list since that is where they should be discussed and reviewed. I have -bcc-ed security-dev (where this was originally posted). --Sean On 10/2/17 1:24 PM, Philipp Kunz wrote: Hi, While fixing

Re: Request for Review: Attributes.map generic types

Cross-posting to core-libs-dev as this proposal is really more appropriate for review on that list. --Sean On 10/3/17 1:48 AM, Philipp Kunz wrote: Hi This has not been asked for and there is also no bug yet but nevertheless let me propose to change Attributes.map to specific generic types.

Re: [10] RFR(S) 8188775: Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.hotspot

On 10/9/17 3:55 AM, Alan Bateman wrote: On 05/10/2017 00:05, Vladimir Kozlov wrote: https://bugs.openjdk.java.net/browse/JDK-8188775 Changes for 8182701[1] missed changes in default.policy for new module jdk.internal.vm.compiler.management. Add missing code:

Re: [10] RFR(S) 8188775: Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.hotspot

On 10/9/17 3:55 AM, Alan Bateman wrote: On 05/10/2017 00:05, Vladimir Kozlov wrote: https://bugs.openjdk.java.net/browse/JDK-8188775 Changes for 8182701[1] missed changes in default.policy for new module jdk.internal.vm.compiler.management. Add missing code:

Re: StackOverflowError - Java 9 Build 181

Cross-posting to security-dev as this is more relevant to that list and bcc-ing core-libs-dev. I think this might be an issue with the JavaWebStart SecurityManager not being granted the proper permissions. It is possible that the deployment policy files are not being loaded or there is some

Re: RFR[10]:8159526 Deprivilege jdk.httpserver

On 9/12/17 4:06 AM, vyom tewari wrote: Hi, Please review the below code change. BugId: https://bugs.openjdk.java.net/browse/JDK-8159526 Webrev-1: http://cr.openjdk.java.net/~vtewari/8159526/jdk/webrev/index.html Can you put the entry for jdk.httpserver after jdk.dynalink so you maintain

Re: RFR 8148371: Remove policytool

The jdk changes look fine to me. --Sean On 9/6/17 12:17 AM, Weijun Wang wrote: 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

Re: Review Request: JDK-8182137: Missing permissions in deprivileged java.xml.bind and java.xml.ws modules

Looks fine to me. The bug needs a noreg label. I agree with Alan that the empty jdk.incubator.httpclient entry should be removed. Also, please open a followon issue to fix the permissions (targeting it to 10 would seem appropriate to me). --Sean On 6/14/17 11:11 AM, Mandy Chung wrote:

Re: RFR 8150681 Update JAR specification for multi-release jar files

Couple of typos on a quick review: 55: s/the the/the/ 129-130: s/the exactly/exactly the/ 144: fukes -> files? --Sean On 5/3/17 5:44 PM, Paul Sandoz wrote: Hi, Please review an update to the JAR “specification” (in the loose sense of the term): - first, it has been moved from a closed

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

heckReadOld201 thrpt 152045.070 ±57.287 ops/s This time checkReadNewFixed02 looks even better than checkReadOld200 running on jdk8u131. I dare not run it again. :-) Thanks Max On 04/08/2017 04:48 AM, Sean Mullan wrote: This fix looks good to me. However, I would suggest adding some a

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

This fix looks good to me. However, I would suggest adding some additional comments to the body of the containsPath method explaining what it is doing so that it is easier to understand. --Sean On 4/7/17 10:50 AM, Weijun Wang wrote: Webrev updated at

Re: RFR: 8055206: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default

On 1/13/17 2:38 AM, Mandy Chung wrote: On Jan 9, 2017, at 11:25 AM, Sean Mullan <sean.mul...@oracle.com> wrote: Please review this JDK 9 change to make the SecurityManager::checkPackageAccess and checkPackageDefinition implementations restrict access to the same set of internal JDK pa

RFR: 8055206: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default

Please review this JDK 9 change to make the SecurityManager::checkPackageAccess and checkPackageDefinition implementations restrict access to the same set of internal JDK packages as the module system. This overall change will improve security by making these two mechanisms consistent and

Re: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module

Looks good. Are there any regression tests for this component that run with a SecurityManager? If not, it would be useful to add some to ensure that the proper permissions are being granted to this module. --Sean On 11/14/16 2:27 AM, Rachna Goel wrote: sorry, correction to typo As

Re: RFR 9: JDK-8168862:Tighten permissions granted to the jdk.zipfs module

On 11/8/16 4:30 PM, Xueming Shen wrote: On 10/31/2016 01:56 PM, Sean Mullan wrote: It would be good to add or modify existing test(s) to run with a Security Manager, if there is not one already. Hi Sean, All current zipfs tests are being run under "default" security mana

Re: RFR 9: JDK-8168862:Tighten permissions granted to the jdk.zipfs module

It would be good to add or modify existing test(s) to run with a Security Manager, if there is not one already. --Sean On 10/31/16 4:32 PM, Mandy Chung wrote: +1 Mandy On Oct 31, 2016, at 1:26 PM, Xueming Shen wrote: Please help review the change for issue:

Re: JDK 9 RFR of JDK-8039854: Broken link in java.lang.RuntimePermission

Actually, I don't really think this permission target belongs in RuntimePermission since it is specific to Oracle's Java Plugin. I would be in favor of removing it and only documenting it in the deployment guides. --Sean On 09/08/2016 02:17 PM, Lance Andersen wrote: all good Joe On Sep 8,

Re: RFR 9 7180225 : SecurityExceptions not defined in some class loader methods

Looks fine to me. --Sean On 08/16/2016 02:54 PM, Brent Christian wrote: Hi, Please review this change which does some cleanup around documenting conditions for throwing SecurityExceptions. It adds a missing @throws tag to Class.forName(String, boolean, ClassLoader), and consolidates

Re: RFR 8154189: Deprivilege java.sql and java.sql.rowset module

On 05/27/2016 02:10 PM, Lance Andersen wrote: The change looks fine. Thank you > >It’s okay to grants AllPermission to get started. It’d be nice if we could grant fine-grained permissions in the future. Agree, it is something to try and work towards. Hi Lance, Could you file a separate

Re: RFR(xs): 8156810 remove redundant sentence in SecurityManager.checkMemberAccess doc

Looks good. --Sean On 5/11/16 4:47 PM, Stuart Marks wrote: Hi all, Regarding this bug, https://bugs.openjdk.java.net/browse/JDK-8156810 I had recently "upgraded" the deprecation annotation of SecurityManager.checkMemberAccess() to include forRemoval=true. [1] [2] This included the

Re: RFR: regex changes -- sun.security.util.Debug issue

On 5/10/16 1:30 AM, Alan Bateman wrote: On 10/05/2016 06:36, Xueming Shen wrote: Hi, While testing for the attached regex changes, a fatal vm init error was triggered for test case with -Djava.security.debug=xyz turned on, as showed in following stacktrace. It appears

Re: RFR: 8155775: Re-examine naming of privileged methods to access System properties

On 05/02/2016 10:15 AM, Sean Mullan wrote: This looks good. Just a couple of comments: * src/java.base/share/classes/java/util/TimeZone.java 698 props.setProperty("user.timezone", id); This will only change the local copy of the property. I think you want to keep the ori

Re: RFR: 8155775: Re-examine naming of privileged methods to access System properties

This looks good. Just a couple of comments: * src/java.base/share/classes/java/util/TimeZone.java 698 props.setProperty("user.timezone", id); This will only change the local copy of the property. I think you want to keep the original code which does a System.setProperty. *

Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract

The changes to the security-libs portions look fine to me. --Sean On 04/21/2016 12:25 PM, joe darcy wrote: Hello, After a generally positive reception, please review the webrev to implement the deprecation of Class.newInstance and the suppression of the resulting warnings:

Re: RFR: 8154067: Avoid early use of limited privilege escalation in InnerClassLambdaMetafactory

On 04/12/2016 12:58 PM, Mandy Chung wrote: On Apr 12, 2016, at 5:38 AM, Claes Redestad wrote: Hi, the first usage of limited doPrivileged appears to have a small startup penalty (loads 8 permission-related classes and does some reflection), and is arguably

Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list

Looks good to me. --Sean On 03/11/2016 10:28 PM, joe darcy wrote: Hello, As Jon Gibbons has noted off-list, the problem list entries can directly include the bug number associated with the test in question, enabling better reporting. This format should be used rather than the current

Re: Custom security policy without replacing files in the OpenJDK?

On 03/02/2016 08:45 PM, David Holmes wrote: On 27/02/2016 2:56 AM, Marcus Lagergren wrote: Hi! Is it possible to override lib/security/local_policy on app level without patching jdk distro? i.e. -Duse.this.policy.jar= … or something? Can’t find a way to do it

Re: RFR: 8147607: Remove test library dependency on sun.security.tools.jarsigner.Main

On 01/28/2016 10:17 AM, Chris Hegarty wrote: On 28 Jan 2016, at 15:16, Wang Weijun wrote: Shouldn't you also include the FileOuputStream in try-with-resources? It is. Do you need to refresh your browers? If you read the code quickly, I missed it too, maybe it would

Re: RFR [9] 8145544: Move sun.misc.VM to jdk.internal.misc

On 01/04/2016 09:02 AM, Chris Hegarty wrote: sun.misc.VM provides a low-level interface for a small number of specific operations with the VM. In preparation for JEP 260, this class should be moved out of sun.misc and located in a non-exported package [.

Re: RFR [9] 8145544: Move sun.misc.VM to jdk.internal.misc

On 01/04/2016 09:14 AM, Chris Hegarty wrote: Note: as in other areas some tests that require access to internal APIs have been updated to use types from a more stable package, sun.security.x509. Not sure what you mean - which tests do you mean and why is sun.security.x509 related to this

Re: RFR 8145750: jjs fails to run simple scripts with security manager turned on

On 12/18/2015 07:55 AM, Sundararajan Athijegannathan wrote: inline comments below.. On 12/18/2015 6:22 PM, Alan Bateman wrote: On 18/12/2015 12:23, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ for

Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils

Looks fine to me, though I have one question below. On 10/7/15 2:19 PM, Chris Hegarty wrote: This primary motivation behind this bug [1] is the clearing out of sun.misc, in preparation for JEP 260 [2]. sun.misc.IOUtils is a JDK internal convenience utility class that provides a single method

Re: Optional used as method argument?

On 10/2/15 9:27 AM, Wang Weijun wrote: 在 2015年10月2日，下午8:49，Roger Riggs 写道： +1 The "no such value" makes me curious about the context. The @param tag really should be saying something about the parameter. In fact, I'm working on a method which is similar to /*

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 10/1/15 5:10 AM, Wang Weijun wrote: 在 2015年10月1日，上午7:53，Steve Drach 写道： - JDK 8 jar signer does not work with a JDK 9 created keystore - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with JDK 9 keystore - JDK 8 signed jar

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 9/30/15 2:30 PM, Steve Drach wrote: Hi Max, Can you describe if there is any effect on signed jars? Including: 1. Will jarsigner be able to sign such a jar? The jarsigner from 1.8.0_51 can sign the jar. The jarsigner from jdk9/dev can not, giving me the error jarsigner: unable to

RFR: 8087283 : Add support for the XML Signature here() function to the JDK XPath implementation

Please review this change to add support for the XML Signature here() function to the JDK XPath implementation. The here function is not defined in its own namespace. Therefore it needs to be implemented by extending the function library of XPath in the same namespace. Currently, the JDK XML

Re: RFR: 8078139 : jdk.xml.dom should be loaded by the ext class loader

On 04/21/2015 02:20 PM, Mandy Chung wrote: OK. I think it's better to follow up this after further discussion for the deprivileging work and understand what can or can't be done in editing the policy files. For now, we should keep existing behavior to grant jdk.xml.dom AllPermissions. How

Re: Review Request: 8073361: Missing doPrivileged in com.sun.xml.internal.bind.v2.ClassFactory

This fix looks fine. --Sean On 02/20/2015 01:54 PM, Mandy Chung wrote: This fixes a regression due to JDK-8057645 moving JAXB to ext loader that was tested before the fix for JDK-8054367 went in jdk9. This was uncovered after JDK-8057645and JDK-8054367 met. The fix is simple.

Re: No read FilePermission for JTREG test.classes - on Windows only (was Re: RFR 9: 8068578: ...)

On 01/29/2015 12:44 PM, Brent Christian wrote: Hi, I ran my updated test through our automated testing system, and it failed *on Windows only*. The toURI() call I added came back with an AccessControlException due to not being able to read the test.classes directory. The test uses its own

Re: FilePermission Canonical path optimization

Hi, Can you elaborate more on the performance degradation that you are seeing at startup? Are you seeing this when you are running with or without a SecurityManager? If without a SecurityManager, can you provide some code paths/examples? As far as I can see, with the proposed fix you are

Re: FilePermission Canonical path optimization

On 12/05/2014 08:00 AM, Peter Levart wrote: The question is what to do with the remaining data race that was present before. The 'mask' field. The best would be to make it final, but deserialization needs to set it. I don't see the pre-existing race condition on the mask field, but I'm

Re: RFR 8060068 : Remove the static initializer block from DriverManager

On 12/03/2014 10:03 AM, Lance Andersen wrote: Note, I also tweaked the doPriviliged block for the JDBC property It's nice to see use of limited doPrivileged. Limited doPrivileged restricts the permissions be accessed by the doPrivileged block. On the other hand, since it only calls

Re: Review request: JDK-8043277: Update jdk regression tests to extend the default security policy instead of override

On 10/23/2014 02:10 PM, Mandy Chung wrote: Sean, I have included a few security tests in this patch: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8043277/webrev.01/ Looks good. --Sean

JEP Review Request: Improve Security Manager Performance

Hello all, I have submitted a JEP for Improve Security Manager Performance that I am seeking further review and feedback: https://bugs.openjdk.java.net/browse/JDK-8043631 This is very similar to a draft I posted earlier [1], but has been re-drafted using the JEP 2.0 process. The JEP is

Re: ThreadLocalRandom clinit troubles

I don't see a pointer to the webrev/patch -- did you forget to include it? --Sean On 07/11/2014 07:33 PM, Martin Buchholz wrote: Thanks to Peter for digging into the secure seed generator classes and coming up with a patch. Openjdk security folks, please review. I confess to getting lost

Re: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo

The security specific files look fine to me. --Sean On 06/03/2014 09:22 PM, Henry Jen wrote: Hi, In an effort to determine APIs availability in a given version, it became obvious that a consistent way to express @since tag would be beneficial. So started with the most obvious ones, where we

Re: Review request: 8040059 Change default policy for extensions to no permission

On 04/23/2014 05:29 PM, Mandy Chung wrote: On 4/23/2014 1:10 PM, Sean Mullan wrote: Just a few comments: 1. When you write a test that uses the jtreg /policy option, the policy file overrides the system policy file. If the test depends on a standard extension, then you may get

Re: Review request: 8040059 Change default policy for extensions to no permission

Just a few comments: 1. When you write a test that uses the jtreg /policy option, the policy file overrides the system policy file. If the test depends on a standard extension, then you may get SecurityExceptions unless additional perms are granted. Thus, there are quite a few tests that

Re: JAXP JEP: Update Xerces implementation in the JDK

On 02/03/2014 02:19 PM, huizhe wang wrote: The JDK contains an older Xerces implementation, version 2.7.1. Although there were updates in JDK 7 to bring in some changes, we did not bring it completely up to date to any later release. The goal of this JEP is to complete the update and bring

Re: RFR(S): 8033154: PPC64: Fix AIX build after integration into jdk9/dev

The java.security-aix file looks fine to me. --Sean On 01/29/2014 12:59 PM, Volker Simonis wrote: Hi, please review the following small change: http://cr.openjdk.java.net/~simonis/webrevs/8033154/ which fixes the AIX build after the integration of ppc-aix-port/stage-9/jdk to jdk9/dev/jdk.

hg: jdk8/tl/jdk: 8031825: OCSP client can't find responder cert if it uses a different subject key id algorithm than responderID

Changeset: 57c26829deb6 Author:mullan Date: 2014-01-22 19:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57c26829deb6 8031825: OCSP client can't find responder cert if it uses a different subject key id algorithm than responderID Reviewed-by: vinnie, xuelei !

hg: jdk8/tl/jdk: 2 new changesets

Changeset: aef6c726810e Author:mullan Date: 2013-12-23 14:03 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aef6c726810e 8030813: Signed applet fails to load when CRLs are stored in an LDAP directory Summary: Skip JNDI application resource lookup to avoid recursive JAR

Re: 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission

On 12/10/2013 08:51 AM, Alan Bateman wrote: In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods checkTopLevelWindow, checkSystemClipboard and checkAccessAwtEventQueueAccess with a warning that they would be changed in a future release to check AllPermission. At the same time we

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

comments (20 Sept [4]) - Steffan Larsen (svc): APPROVED (20 Sept [5]) - Phil Race (2d): Initial comments (18 Sept [6]); Additional comments (15 Oct [7]) - Sean Mullan (sec): Initial comments (26 Sept [8]) [2]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html [3

Re: [8] Review Request: 8027696 Incorrect copyright header in the tests

The security tests look fine. --Sean On 11/01/2013 07:18 AM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk 8. Most of tests in the sound area, and some tests in the client, java.lang, security, jmx etc has incorrect copyright. According to the http://openjdk.java.net/faq GPL v2 +

hg: jdk8/tl/jdk: 3 new changesets

Changeset: 5f4aecd73caa Author:mullan Date: 2013-10-22 08:03 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f4aecd73caa 8021191: Add isAuthorized check to limited doPrivileged methods Reviewed-by: weijun, xuelei ! src/share/classes/java/security/AccessControlContext.java !

Re: Please Review javadoc fixes 8026982 (updated)

The changes in the security area look fine to me. --Sean On 10/22/2013 04:31 PM, roger riggs wrote: Thanks for the comments, updated with Webrev with the suggestions. http://cr.openjdk.java.net/~rriggs/webrev-javadoc-8026982/ Roger On 10/22/2013 2:53 PM, roger riggs wrote: Please

hg: jdk8/tl/jdk: 2 new changesets

Changeset: fc7a6fa3589a Author:ascarpino Date: 2013-10-22 19:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc7a6fa3589a 8025763: Provider does not override new Hashtable methods Reviewed-by: mullan ! src/share/classes/java/security/Provider.java Changeset: b065de1700d3

hg: jdk8/tl/jdk: 3 new changesets

Changeset: 5d866df64ae3 Author:mullan Date: 2013-10-17 10:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d866df64ae3 8026346: test/java/lang/SecurityManager/CheckPackageAccess.java failing Reviewed-by: vinnie ! src/share/lib/security/java.security-macosx !

<    1   2   3   >