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

On 12/06/2015 18:29, Sean Mullan wrote: 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

Re: RFR 7191662: JCE providers should be located via ServiceLoader

On 16/06/2015 00:58, Valerie Peng wrote: It seems that the jimage refresh change may still take some time, so we will end up removing the makefile related changes and then deferring the ServiceLoader related changes to Jake workspace. Here is the latest webrev (Security source/test changes

Re: RFR 8130112: Create a common TEST.properties for @modules in test/sun/security/krb5/auto

On 02/07/2015 08:46, Weijun Wang wrote: 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

Re: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics

On 26/06/2015 16:43, Zoltán Majó wrote: I updated the indentation as well. Here is the updated webrev: - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.06/ - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.06/ - hotspot:

Re: RFR 7191662: JCE providers should be located via ServiceLoader,

On 25/05/2015 09:53, Chris Hegarty wrote: If it is agreed that these files are needed, then I can look at expanding the ImageBuilder to do concatenate them. I agree with Mandy's point that java.security should be change to list the provider name rather than the class name. If that happens

Re: RFR 7191662: JCE providers should be located via ServiceLoader,

On 22/05/2015 13:55, Chris Hegarty wrote: : I think it could be done either way. Valerie - have you considered not pushing the services configuration files with this change? With the change then the java.security configuration is still class names, not provider names, so the fallback

Re: RFR 8058849: test/sun/security/krb5/config/dns.sh needs to re-examined or replaced

On 29/06/2015 08:55, Weijun Wang wrote: 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,

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

On 07/10/2015 20:57, Chris Hegarty wrote: : I updated Connection with a readFully that has the same semantics as IOUtils. http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ I agree with Roger. Couldn't this be changed to use create an array of length seqlen and use readNBytes?

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

On 07/10/2015 19:19, Chris Hegarty wrote: This primary motivation behind this bug [1] is the clearing out of sun.misc, in preparation for JEP 260 [2]. It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use sun.security.util.IOUtils, could that one be fixed? The rest look

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

On 02/12/2015 15:26, Chris Hegarty wrote: Thanks Max, I'm ok with this version, if you are. I'll include it in the final push. This version looks okay to me too. -Alan.

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

On 02/12/2015 12:08, Chris Hegarty wrote: The regression tests in the jdk should be updated, where possible, to use java.util.Base64. http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ Should S11N be updated to serialize with JDK 8 so that the core reflection code isn't needed?

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

On 04/01/2016 14:02, 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: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

On 31/12/2015 14:30, Mark Sheppard wrote: Hi please oblige and review the current version of the fix for https://bugs.openjdk.java.net/browse/JDK-8134577 at http://cr.openjdk.java.net/~msheppar/8134577/webrev.05/ which is based on feedback from the second review. I looked through the

Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

On 30/11/2015 11:13, Sibabrata Sahoo wrote: Here is the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ I have one question: What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*" &

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

On 12/06/2016 13:44, Wang Weijun wrote: I was about to send out a new webrev (CCC just approved) but noticed a behavior change. Although "-addprovider SUN" is useless it still worked when I posted webrev.03, but now it failed, because ServiceLoader.load(Provider.class) does not contain

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

On 14/06/2016 04:28, Wang Weijun wrote: OK, please take a review at the new version at http://cr.openjdk.java.net/~weijun/8130302/webrev.04/ Changes from webrev.03: 1. The new option name -addprovider is used, along with the changes in Resources.java. 2. In

Re: RFR [9] 7067728: Remove stopThread default java.policy

On 14/01/2016 10:05, Chris Hegarty wrote: The "stopThread” RuntimePermission is granted by default. The Thread.stop methods have been deprecated for more than 15 years. It seems reasonable, in a major release, to remove the default grant of stopThread. This looks okay to me, we should have

Re: [9] RFR 8134487：updated sun/security/ssl/StatusStapling/* to work with modules

On 16/02/2016 03:31, Tim Du wrote: Hi All: Please help to review the fix for Jigsaw test bug.Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8134487 Webrev: http://cr.openjdk.java.net/~tidu/8134487/webrev.01/ The test to access non-public class.To workaround the issue , I create the

Re: [9] RFR 8134487：updated sun/security/ssl/StatusStapling/* to work with modules

On 16/02/2016 11:05, Tim Du wrote: Hi Alan： I tried @compile/module to fix this issue before, but it does not work ,Use CertStatusReqExtensionTests.java as example, the process as below: 1. Create java.base/sun/security/ssl folder in test/sun/security/ssl/StatusStapling. 2. Move the

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

On 16/02/2016 14:44, Weijun Wang wrote: Please review the code change at http://cr.openjdk.java.net/~weijun/8130302/webrev.00/ I didn't abandon -providerClass and go all the way to -provideName because -providerClass has a sub-option -providerArg that can be used to further configure the

Re: [9] RFR 8134487：updated sun/security/ssl/StatusStapling/* to work with modules

On 17/02/2016 08:19, Tim Du wrote: Follow you suggestion, I updated the code as below: 1.Create java.base/sun/security/ssl under test/sun/security/ssl/StatusStapling/, move all test files and dependency class into java.base/sun/security/ssl ,removed the jtreg label from test java files.

Re: [9] RFR 8134487：updated sun/security/ssl/StatusStapling/* to work with modules

On 17/02/2016 09:57, Tim Du wrote: Sure. I am aslo updated java.base/sun/security/testlibrary to test/java/security/testlibrary/ , so that keep the testlibrary files could be reused by other tests. Re-generate the latest webrev is http://cr.openjdk.java.net/~tidu/8134487/webrev.03/ ,

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

On 17/02/2016 01:20, Weijun Wang wrote: : Technically they are independent. With -providerClass/-providerArg, the provider is added into system and getInstance() calls (of keyStore, KeyPairGenerator, etc) can use it. On the other hand, -providerName can be used to specifically tell

Re: [9] RFR 8134487：updated sun/security/ssl/StatusStapling/* to work with modules

On 17/02/2016 09:57, Tim Du wrote: Sure. I am aslo updated java.base/sun/security/testlibrary to test/java/security/testlibrary/ , so that keep the testlibrary files could be reused by other tests. Re-generate the latest webrev is http://cr.openjdk.java.net/~tidu/8134487/webrev.03/ , Thanks.

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

On 18/02/2016 08:10, Weijun Wang wrote: : Today, we tell users to load their own PKCS11 provider with -providerClass sun.security.pkcs11.SunPKCS11 -providerArg some.cfg and seems the new options should be -provider SunPKCS11 -providerArg some.cfg Why not just support all these formats?

Re: [9] RFR 8134487：updated sun/security/ssl/StatusStapling/* to work with modules

On 18/02/2016 02:44, Tim Du wrote: I grep the files which are using CertificateBuilder and SimpleOCSPServer from jake/jdk/test, the result as below: - javax/net/ssl/Stapling/HttpsUrlConnClient.java - javax/net/ssl/Stapling/SSLEngineWithStapling.java -

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

On 18/02/2016 09:08, Weijun Wang wrote: OK, but with -providerClass I'd like to support a class name even if it is already defined in a module as a service and has its own name. This makes sure old commands still work. I think it should work fine but I assume we would want to discourage this.

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

On 19/02/2016 08:22, Wang Weijun wrote: A new webrev at http://cr.openjdk.java.net/~weijun/8130302/webrev.01/ The options for keytool have -provider [-providerArg ]add a provider by name -providerclass [-providerArg ] add a provider by classname (omit some words because

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

On 19/02/2016 09:07, Wang Weijun wrote: : I don't want the line to be too long. Is the preferred terminal width still 80 now? I noticed the java help output still fits with 80 chars but javac is already not. It could fit on a second line, the java launcher usage output does this. I see

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

On 19/02/2016 10:47, Wang Weijun wrote: Updated at the same URL http://cr.openjdk.java.net/~weijun/8130302/webrev.01 The help looks like this now: -provider add security provider by name (e.g. SunPKCS11) [-providerArg ] configure argument for -provider

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

On 19/02/2016 11:17, Wang Weijun wrote: : When and which repo should this change go into? Certainly this is all about jake but there are a lot of other changes, esp, the option list. Good question. Ideally jdk9/dev as we are trying to minimize the changes in the jake forest. If you do that

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

On 23/03/2016 08:12, Wang Weijun wrote: Now that jake/m3 is in jdk9/dev I assume I will just include the jake-related codes and directly push a single changeset to jdk9/dev. Right? Yes, changes like this this can be pushed via jdk9/dev. In the mean-time, we will continue to work in

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

On 10/05/2016 19:57, Xueming Shen wrote: webrev has been updated as suggested, now the lazily-init-class-holder is used to delay the Debug initialization. Tests all passed locally. A jprt job is out to confirm. Here is the updated webrev

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

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 sun.security.util.Debug is being initialized even before the

Re: Questions on deprivileging a module

On 05/07/2016 09:03, Remi Forax wrote: The other solution is to use a VarHandle instead of Unsafe for setting the final field, i don't think that letting unprivileged module to access to Unsafe is a good idea. Very true, I wasn't paying attending to why it is using Unsafe in the first

Re: Questions on deprivileging a module

On 04/07/2016 07:03, Wang Weijun wrote: I am working on JDK-8159528 Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.auth https://bugs.openjdk.java.net/browse/JDK-8159528 Several questions: 1. How does updating /make/common/Modules.gmk affect an exploded build? The

Re: Questions on deprivileging a module

On 05/07/2016 08:15, Wang Weijun wrote: : It's a runtime error. @CallerSensitive public static Unsafe getUnsafe() { Class caller = Reflection.getCallerClass(); if (!VM.isSystemDomainLoader(caller.getClassLoader())) throw new SecurityException("Unsafe"); << The exception

Re: Strange test failure when referencing a class in a deprivileged module

On 07/07/2016 09:27, Wang Weijun wrote: Like this? https://gist.github.com/wangweij/6992aaf9617b9e2f242ddf9e391ea5f6 The horizontal line is printed on line 706 of the gist. I assume the suggestion was to reference SQLPermission before setting the security manager. As regards module loading

Re: RFR 8161102: Regression test for JDK-8161101 (Recursive update error when a SecurityManager references a permission defined in a non-privileged module)

On 11/07/2016 02:14, Wang Weijun wrote: Hi All I filed a bug [1] on my recent finding [2] of a bug in SecurityManager. While I cannot find a fix, I'm able to provide a regression test, Therefore I created a sub-task [2] for the test. Please take a review at

Re: Strange test failure when referencing a class in a deprivileged module

On 05/07/2016 09:22, Wang Weijun wrote: On Jul 5, 2016, at 11:53 AM, Wang Weijun wrote: The exception is at the end of this mail. The test passes if I change X.go() to calling a method inside this class Update: any call that triggers a permission check will do. For

Re: Strange test failure when referencing a class in a deprivileged module

On 06/07/2016 05:32, Weijun Wang wrote: On 7/5/2016 23:50, Mandy Chung wrote: Max - are you running the test with exploded image (see JDK-8155858 [1])? No. The test also fails with recent promoted builds (ever since java.sql is de-priveleged). I assume this is a general issue with security

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

On 02/02/2017 02:12, Mandy Chung wrote: On Feb 1, 2017, at 3:07 AM, Doug Simon wrote: I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy:

Re: RFR 8172422: jarsigner needs to understand -?

On 16/01/2017 01:41, Weijun Wang wrote: Please review the code change at http://cr.openjdk.java.net/~weijun/8172529/webrev.02 The validator is updated to be a PKIXValidator of the Validator.VAR_CODE_SIGNING variant. In order to have the same output message and exit code as before, the

Re: RFR: 8163126 Wrong @modules in some of jdk/* tests

On 17/08/2016 17:40, Alexandre (Shura) Iline wrote: Thank you! Fixed in place: http://cr.openjdk.java.net/~shurailine/8163126/webrev.00/test/jdk/security/jarsigner/Spec.java.sdiff.html Shura The updated patch looks good to me. Slightly off-topic but how close do you think we are to

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

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 leads

Re: RFR 8170364: FilePermission path modified during merge

On 28/11/2016 08:40, Wang Weijun wrote: Hi Alan Updated webrev at http://cr.openjdk.java.net/~weijun/8170364/webrev.01 Changes since webrev.00: - a private constructor that can clones 4 fields and modifies 5 others - using lambda - test enhancement This looks much better. A minor

Re: RFR 8170364: FilePermission path modified during merge

On 26/11/2016 08:54, Wang Weijun wrote: Please take a review at http://cr.openjdk.java.net/~weijun/8170364/webrev.00/ The compatibility layer introduced in the new FilePermission implementation requires one FilePermission to imply another with either a relative path or an absolute path.

Re: RFR: 8170602: Startup regression due to introduction of lambda in java.io.FilePermissionCollection

On 01/12/2016 15:33, Claes Redestad wrote: Hi, recent changes to FilePermissionCollection to use a lambda in place of an explicit BiFunction cause a quite noticeable startup and footprint regression on small applications due to a bootstrap dependency. Therefore I'd like to revert this

Re: 9 RFR of JDK-8176337: Mark several tests as intermittently failing

On 08/03/2017 03:36, Hamlin Li wrote: Would you please review below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8176337 webrev: http://cr.openjdk.java.net/~mli/8176337/webrev.00/ These tests are failing intermittently, they should be marked accordingly with @key intermittent

8184916: DisabledAlgorithmConstraints loading should be delayed until needed

I'm looking at the performance of an app that initializes a lot more security classes than I expected. One part to this is the initial opening of a JAR file which ends up loading a lot of machinery that should only be needed with signed JARs. Any objection if I change SignatureFileVerifier to

Re: RFR: 8179370: Replace use of , and tags in java.base

On 27/04/2017 02:49, Jonathan Gibbons wrote: Updated webrev to address Joe's suggestion to try harder to use {@code} as a substitute for . http://cr.openjdk.java.net/~jjg/8179370/webrev.01 The updated version using {@code ... } looks better and also keeps the lines from growing too long.

Re: some config files out of conf directory

On 04/08/2017 07:59, Jiri Vanek wrote: Hello! I'm packaging openjdk9 for Fedora, and following files: jdk/lib/security/blacklisted.certs jdk/lib/security/default.policy Seems to be config files. Still, they are in lib/security, whether all other config files were (finally! Thank you!)

Re: JPMS Access Checks, Verification and the Security Manager

Volker - one suggestion for your experiments is to change your JDK 8 security properties file (java.security) to add "com.sun.crypto.provider." to the value of the "package.access" property. That should mean you will get the same AccessControlException with JDK 8 as you do with JDK 9. It may

Re: RFR 8148371: Remove policytool

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.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

Re: New JEP Draft: "Open-Source the Root Certificates"

On 22/11/2017 13:23, Sean Mullan wrote: Please review a new JEP Draft titled "Open-Source the Root Certificates". The JDK source code currently contains an empty cacerts keystore, which prevents security components such as TLS from working out-of-the-box on OpenJDK builds. The goal of this

Re: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields

On 22/11/2017 14:37, Sean Mullan wrote: Please review this change to remove the pre-JDK 1.2 SecurityManager methods that have been deprecated since JDK 1.2 and marked for removal in JDK 9. These methods are fragile, error-prone and have been obsolete since the SecurityManager was revamped in

Re: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields

On 22/11/2017 15:49, Sean Mullan wrote: Hmm. Where do you see it being called inside doPrivileged? StackWalker.getInstance does a permission check when you want class refs. : Sure, the test already had everything I need so it was easier to leverage it rather than just duplicating. I had

Re: Dropping the security manager (was Re: Eliminating the security overhead when not running with a security manager)

On 23/11/2017 19:21, Jason Tedor wrote: > Long term then it would be interesting to explore degrading and eventually dropping the security manager but that is beyond the scope of what I would like to discuss here. That is a bold topic to immediately declare out of scope. I am looking for

Re: Need help with porting stuff out of classDepth

On 18/12/2017 16:28, Fridrich Strba wrote: Hello, good people, After removing some deprecated SecurityManager methods in jdk10, I am trying to build libbluray, but there is this snippet that obviously is broken with jdk10: classDepth has been deprecated since 1.2 (1998) so it's surprising to

Re: Eliminating the security overhead when not running with a security manager

On 21/11/2017 00:48, David Lloyd wrote: One thing that springs to mind. Some allowance would have to be made for domain combiners and JAAS Subject propagation: this mechanism also uses access control contexts, to its own great detriment. Are you thinking about usages where there is no security

Eliminating the security overhead when not running with a security manager

One of the long standing issues with the security manager support is that the overhead when there is no security manager is non-zero. Two specific examples are (i) the overhead of defineClass (assuming the defining loader is a SecureClassLoader) as it involves a callback to get the

Re: Permissions in default.policy and --patch-module

On 11/12/2017 01:12, Weijun Wang wrote: I modified a class inside the jdk.crypto.cryptoki module, compiled it with "javac -d /tmp", and then ran a small program with java --patch-module jdk.crypto.cryptoki=/tmp -Djava.security.manager MyProg and it fails with TEST RESULT: Failed.

Re: Permissions in default.policy and --patch-module

On 11/12/2017 07:50, Weijun Wang wrote: I was just trying to run a jtreg test on a new Windows VirtualBox VM. A small code change is needed but I don't want to do a full build (it also does not have enough memory). I just copied an existing image, and the modified class was compiled on the

Re: RFR 8189131: Open-source the Oracle JDK Root Certificates

On 01/12/2017 18:05, Volker Simonis wrote: : Yes, but as far as I know @key tags are implemented by querying VM properties. In this case however there's no VM property which indicates how the VM has been configured. jtreg -k allows keyword expressions to be specified. It's one way of

Re: RFR 8189131: Open-source the Oracle JDK Root Certificates

On 01/12/2017 17:16, Volker Simonis wrote: Hi Rajan, great to see this finally happen! I have just a quick question related to the tests. As far as I can see, the tests will only succeed if the OpenJDK will be build with the new open sourced, Oracle root certificates. But what if somebody is

Re: RFR: 8202419: Avoid creating Permission constants early

On 30/04/2018 13:25, Claes Redestad wrote: Hi, moving a couple of local permission constants to sun.security.util.SecurityConstants ensures we delay and avoid loading permission classes very early during bootstrap. Delaying load is profitable since it's happening early enough (before

Re: [10] RFR 8194959: Correct test tag to move bugid from @test to @bug

On 12/01/2018 04:51, Amy Lu wrote: Please review this minor test-tag-only change to move bugid from @test to @bug bug: https://bugs.openjdk.java.net/browse/JDK-8194959 webrev: http://cr.openjdk.java.net/~amlu/8194959/webrev.00/ Looks good.

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

On 06/08/2018 20:11, 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 checks (JDK-8202056).

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

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 to the description of the property alerting

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

On 07/08/2018 16:00, Baesken, Matthias wrote: Ping  , any reviews / comments ? Did we get to a conclusion on whether to have central infrastructure to read/parse the security property? As I recall, this one was originally proposed before the generalization of the networking solution.

Re: RFR 8209416: Refactoring GetPropertyAction calls in JGSS

On 13/08/2018 20:11, Sean Mullan wrote: : Also, this change puts more of a dependency on sun.security.action which I think we want to avoid, as it would be nice to eventually stop exporting sun.security.action so as to minimize the exports from java.base to the java.security.jgss module. You

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

On 24/08/2018 15:52, Baesken, Matthias wrote: Hello, I created another webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.5/ - use now jarPath instead of jarpath in the java security file - moved the parsing of the property to a more general location (separate class

Re: RFR 8209995: java.base does not need to export sun.security.ssl to java.security.jgss

On 27/08/2018 16:09, Weijun Wang wrote: Since we've removed all krb5-based ciphersuites from JSSE, this qualified export is useless anymore. Please review the patch below: diff --git a/src/java.base/share/classes/module-info.java b/src/java.base/share/classes/module-info.java ---

Re: RFR 8209416: Refactoring GetPropertyAction calls in JGSS

On 27/08/2018 12:25, Weijun Wang wrote: Would it be possible (in the future) for 2 modules to use the same name for a private package? If yes, we can dup the sun.security.action classes into java.security.jgss without having to modify all calls. Not if both modules are mapped to the same class

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

On 20/07/2018 12:38, Chris Hegarty wrote: JDK-8204233 added a new security property, `jdk.net.includeInExceptions`, to include additional, potentially security sensitive, information in exception detail messages in the networking area. The property accepts a comma separated list of values that

Re: Release note review, JDK-8210070, Release Note: The "supported_groups" extension should not present in the ServerHellos handshake message

On 28/08/2018 15:17, Xuelei Fan wrote: Hi, Please review this release note:    https://bugs.openjdk.java.net/browse/JDK-8210070 Per the "supported_groups" extension specification, the supported_groups extension should not present in the ServerHello handshake message. JDK 11 cannot work

Re: RFR: JDK-8210274: Source Launcher should work with a security manager

On 10/09/2018 21:37, Jonathan Gibbons wrote: Please review a patch to have the Source Launcher be able to work when a security manager is enabled. It's not clear to me that this is an interesting use-case but in any case I think you've got two scenarios to test. One is setting

Re: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later)

Forwarding to security-dev. On 10/07/2018 17:47, Norman Maurer wrote: Hi all, I just tried to run netty[1] testsuite with the latest jdk11 EA release (21) and saw some class-cast-exception with our custom SSLEngine implementation Caused by: java.lang.ClassCastException: class

Re: -Djava.security.manager=problems for service providers

Moving this to security-dev. From the stack trace, it looks like you are using JDK 8 or older. There are several changes in JDK 9 and newer in the PolicyFile code to how it loads its resources that may help with the issues you are seeing. -Alan On 27/03/2018 13:56, Peter Firmstone wrote:

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

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, and checkMemberAccess. These methods no longer have any

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

On 23/03/2018 13:56, Magnus Ihse Bursie wrote: With modern compilers, we can use compiler directives (such as _attribute__((visibility("default"))), or __declspec(dllexport)) to control symbol visibility, directly in the source code. This has historically not been present on all compilers, so

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

On 23/03/2018 15:15, Magnus Ihse Bursie wrote: : Very much so, yes. I've found a lot of dubious exports, everything from global variables (yuck!) to functions that does not seem to be used anymore, to lots of strange exports. The changes looks good to me and I think we should follow this up

Re: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure

On 29/06/2018 09:22, Sibabrata Sahoo wrote: May I get the approval from serviceability-...@openjdk.java.net. This a test only change to update the keystores and the list of ciphers/protocols that the test uses. There's nothing serviceability specific here so having a Reviewer from the

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

On 05/10/2018 18:52, dean.l...@oracle.com wrote: Isn't this an implementation detail that could change?  Could it say instead "system class loader or one of its ancestors" or something equally flexible? I don't think there is much flexibility here. If the custom security manager class

Re: Jar's CodeSigner null on Java 10, non-null on Java 8

On 06/10/2018 06:21, Scott Palmer wrote: As is too often the case I discovered the difference while trying to isolate a test case. With Java 10 I had extra JVM args to deal with module path and that appeared to cause the problem. There is very limited support for signing of modules and signed

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

On 08/10/2018 16:24, 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 read in the property

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

On 12/10/2018 09:12, Baesken, Matthias wrote: Ping …  any reviews / comments ? Should I add  a category  , for example    “ioExceptionsWithPath” to the java.security – file  to control  the enabling/disabling of the  enhanced exception ?   java.security # # Enhanced exception message

Re: RFR 8212165: JGSS: Fix cut/paste error in NativeUtil.c

On 15/10/2018 03:32, Weijun Wang wrote: Hi All Please take a review on a change in DEF_JNI_OnLoad of NativeUtil.c: *diff --git a/src/java.security.jgss/share/native/libj2gss/NativeUtil.c b/src/java.security.jgss/share/native/libj2gss/NativeUtil.c* *---

Re: [RFR] JDK-8213154: Update copyright headers of files in src tree that are missing Classpath exception

On 30/10/2018 17:44, Martin Balao wrote: Hi, Can I have a review for JDK-8213154 [1]?  * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.00/  *

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

On 03/11/2018 20:00, 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: I looked through the updated webrev.4, mostly studying the changes in AccessController.java and jvm.cpp and the

Re: RFR 8213031: (zipfs) Add support for POSIX file permissions

On 05/11/2018 07:32, Langer, Christoph wrote: Hi, Ping. May I get reviews/substantial feedback on this zipfs enhancement? It might be bit early to be asking for a code review on just one piece of this. I think the first step on this feature has to be to put all the issues on the table.

Re: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions)

On 29/10/2018 09:26, Langer, Christoph wrote: : As per request from Alan, I’m adding security-dev to get a review from security perspective. For security-dev then I think it would be better to write-up a summary of the overall proposal and the implications for applications/libraries that

Re: RFR 8213031: (zipfs) Add support for POSIX file permissions

On 05/11/2018 13:05, Langer, Christoph wrote: Hi Alan, all, I’d welcome a discussion, for sure. Unfortunately there hasn’t been so much participation in this yet. I think this is an item where it’s hard to have a clear opinion and where it’s difficult to oversee all implications it might

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

On 04/10/2018 22:04, Sean Mullan wrote: Excellent comments, Stuart. Thanks for taking the time to review this. I have posted another review that should address most of your comments, but also responded inline with replies below. http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.02/

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

On 05/10/2018 13:59, Sean Mullan wrote: On 10/5/18 6:40 AM, Alan Bateman wrote: The only issue I see is the statement "The class is loaded by the system class loader ..." as it's actually the built-in application class loader. Is the "built-in application class lo

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

On 02/10/2018 16:34, Sean Mullan wrote: Hello, Thanks for all the comments so far, and the interesting discussions about the future of the SecurityManager. We will definitely return to those discussions in the near future, but for now I have a second webrev ready for review for this

Re: JGSS Enhancements (contribution by Two Sigma Open Source)

On 03/10/2018 00:04, Nico Williams wrote: Hello, We at Two Sigma Open Source, LLC, would like to make a contribution, to the OpenJDK, of various enhancements to the the OpenJDK's JGSS stack, specifically for better interoperability with native C GSS-API implementations. As I understand it, Two

Re: JGSS Enhancements (contribution by Two Sigma Open Source)

On 09/10/2018 21:55, Nico Williams wrote: On Tue, Oct 09, 2018 at 04:31:07PM -0400, Sean Mullan wrote: On 10/9/18 4:04 PM, Nico Williams wrote: In order to file a bug or post a patch, you need to be an author first. Read here:http://openjdk.java.net/projects/#project-author. So it seems I

Re: JGSS Enhancements (contribution by Two Sigma Open Source)

On 03/10/2018 21:49, Nico Williams wrote: : A lot of these changes are interrelated. Reviewing them in order of size might require rebasing our stack of commits, and may not be entirely possible. We're extremely familiar with this code as we have been patching the JGSS stack this way for years

Re: Jar's CodeSigner null on Java 10, non-null on Java 8

On 07/10/2018 18:08, Scott Palmer wrote: Thanks Alan. I think this is exactly the issue I was hitting. Is it currently not possible to ensure modules have not been tampered with? The signature checking for signed JARs on the module path is the same as that done for signed JARs on the class

<    1   2   3   4   5   6   7   8   >