On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken wrote:
> When trying to construct an LdapURL object with a bad input string (in this
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run
> into the
On Wed, 11 May 2022 15:32:38 GMT, Christoph Langer wrote:
> This augments the ZipException upon rejecting a Zip File containing entry
> names with "." or ".." elements.
>
> It furthermore tries to clean up & compact the logic for detecting "." and
> ".." and it adds a method
On Wed, 11 May 2022 05:39:42 GMT, Alan Bateman wrote:
> > > It's probably ok, but the bug report is either incomplete or I am missing
> > > something. It says "This can be improved to something like: ..." but the
> > > same text as is emitted now is used. Can you fix this so I have a better
>
On Tue, 10 May 2022 21:26:42 GMT, Sean Mullan wrote:
> It's probably ok, but the bug report is either incomplete or I am missing
> something. It says "This can be improved to something like: ..." but the same
> text as is emitted now is used. Can you fix this so I ha
On Tue, 10 May 2022 16:59:41 GMT, Lance Andersen wrote:
> > > > > @LanceAndersen @AlanBateman do you think adding the entry name in the
> > > > > exception in ZipFileSystem is ok? If so, should it maybe go into a
> > > > > different patch?
> > > >
> > > >
> > > > It should be okay as this is
On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo wrote:
> * Syntactically improves a few cases from 8285676
> (https://github.com/openjdk/jdk/pull/8410)
> * Fixes a few misspelled `@param` tags for elements that, although are not
> included in the API Documentation, are visible in and processed
On Thu, 28 Apr 2022 20:54:29 GMT, Joe Darcy wrote:
>> Add a new system property, java.specification.maintenance.version, to return
>> the maintenance release number of the Java SE specification being
>> implemented. The property is unset, optional in the terminology of
>>
On Thu, 28 Apr 2022 20:07:41 GMT, Joe Darcy wrote:
>> src/java.base/share/conf/security/java.policy line 34:
>>
>>> 32:"java.specification.version", "read";
>>> 33: permission java.util.PropertyPermission
>>> 34:
On Thu, 28 Apr 2022 17:36:32 GMT, Joe Darcy wrote:
>> Add a new system property, java.specification.maintenance.version, to return
>> the maintenance release number of the Java SE specification being
>> implemented. The property is unset, optional in the terminology of
>>
On Wed, 27 Apr 2022 22:27:34 GMT, Joe Darcy wrote:
> Add a new system property, java.specification.maintenance.version, to return
> the maintenance release number of the Java SE specification being
> implemented. The property is unset, optional in the terminology of
> System.getProperties,
On Tue, 19 Apr 2022 16:50:12 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on the `src/java.base` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> (Due to false positives this can unfortunately not be run automatically)
>>
>> The majority of fixes
On Thu, 14 Apr 2022 20:16:38 GMT, Sean Mullan wrote:
>>> Are the changes necessary for this part?
>>
>> @seanjmullan no, they are just performance refinement.
>>
>> If you really that wanna 100% sync ,
>>
>> I can use the old 1.8 api to migrate tha
On Thu, 14 Apr 2022 20:16:21 GMT, Bradford Wetmore wrote:
>> I ran `codespell` on the `src/java.base` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> (Due to false positives this can unfortunately not be run automatically)
>>
>> The majority of fixes are
On Thu, 14 Apr 2022 20:11:37 GMT, XenoAmess wrote:
> > Are the changes necessary for this part?
>
> @seanjmullan no, they are just performance refinement.
>
> If you really that wanna 100% sync ,
>
> I can use the old 1.8 api to migrate that part, and make a mirror pr to that
> part of
On Thu, 14 Apr 2022 18:10:28 GMT, XenoAmess wrote:
>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add `@LastModified: Apr 2022` to DocumentCache
Right, we generally try to
On Fri, 18 Mar 2022 08:39:46 GMT, Alan Bateman wrote:
>> This change removes support for
>> `-Dsun.misc.URLClassPath.disableJarChecking`. As discussed in the bug the
>> feature doesn't current work, and only ever supported scenarios where a
>> security manager is installed, so it seems safe
On 3/1/22 8:01 AM, Andrew Haley wrote:
On 3/1/22 11:45, Andrew Haley wrote:
Sure, you wouldn't
be able to use the default thread pool, but that's no big deal, I would have
thought.
I'm sorry, I'll say that again. :-)
I meant to say "you wouldn't be able to use the default thread pool if
On 2/27/22 1:47 PM, Andrew Haley wrote:
I'd like to explore the use of scope locals as a lightweight means to
implement a system of permissions and capabilities for things such as
this.
Now you have piqued my curiosity, as I have explored a capability based
model for intercepting
On Thu, 10 Feb 2022 20:35:19 GMT, Sean Mullan wrote:
>> So a bit more on this. If the ZipEntry passed to `ZipFile::getInputStream`
>> does not represent an entry within the current Zip/Jar,
>> `ZipFile::getInputStream` will return a null for the InputStream:
&g
On Wed, 9 Feb 2022 21:16:08 GMT, Lance Andersen wrote:
>>> Nit, add space after "if"
>>
>> will fix
>
> So a bit more on this. If the ZipEntry passed to `ZipFile::getInputStream`
> does not represent an entry within the current Zip/Jar,
> `ZipFile::getInputStream` will return a null for the
On Tue, 8 Feb 2022 15:57:00 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/util/jar/JarFile.java line 871:
>>
>>> 869: }
>>> 870: // ZipEntry::getName should not return null
>>> 871: if(ze.getName() != null) {
>>
>> Nit, add space after "if"
>
> if
On Mon, 7 Feb 2022 23:02:54 GMT, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the attached patch to address
>>
>> - That JarFile::getInputStream did not check for a null ZipEntry passed as a
>> parameter
>> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an
On Mon, 7 Feb 2022 16:52:07 GMT, Lance Andersen wrote:
>> `JarException` is a subclass of `ZipException` though, so I think this would
>> be ok to throw and still be compliant with the specification.
>
> Looking at this a bit more, it looks like `JariFile::initializeVerifier` is
> the only
On Fri, 4 Feb 2022 15:19:11 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/util/jar/JarFile.java line 866:
>>
>>> 864: } catch (Exception e2) {
>>> 865: // Any other Exception should be a ZipException
>>> 866: throw (ZipException) new
On Fri, 4 Feb 2022 12:42:39 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review the attached patch to address
>
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a
> parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an
>
I only took a quick look, but it looks like a bug. The jdk.compiler
module needs to be granted that permission in the default.policy file.
Please file a bug, or if you like I can file one on your behalf.
Thanks,
Sean
On 2/3/22 8:01 AM, Jaikiran Pai wrote:
I'm unsure if core-libs is the right
On Wed, 12 Jan 2022 21:57:22 GMT, Sean Mullan wrote:
> If a JAR is signed with multiple digest algorithms and one of the digest
> algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly
> returning null indicating that the jar entry has no signers.
>
> This
On Thu, 13 Jan 2022 21:57:57 GMT, Sean Mullan wrote:
>> If a JAR is signed with multiple digest algorithms and one of the digest
>> algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly
>> returning null indicating that the jar entry has no signers.
On Thu, 13 Jan 2022 21:54:17 GMT, Weijun Wang wrote:
>> The algorithm constraints check will be skipped (because `permittedAlgs`
>> will be `null`) but the hash check will not be skipped.
>>
>> I don't think `null` would be returned in a normal case. The only case I can
>> think of is if
than once for entries signed by the same set of
> signers.
Sean Mullan has updated the pull request incrementally with one additional
commit since the last revision:
Change permittedAlgs variable name.
Move put methods out of checkConstraints().
-
Changes:
- all: https://
On Thu, 13 Jan 2022 16:55:08 GMT, Weijun Wang wrote:
>> If a JAR is signed with multiple digest algorithms and one of the digest
>> algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly
>> returning null indicating that the jar entry has no signers.
>>
>> This fixes the
On Thu, 13 Jan 2022 12:33:53 GMT, Sean Coffey wrote:
>> If a JAR is signed with multiple digest algorithms and one of the digest
>> algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly
>> returning null indicating that the jar entry has no signers.
>>
>> This fixes the
On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote:
> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead,
> please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in
If a JAR is signed with multiple digest algorithms and one of the digest
algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly
returning null indicating that the jar entry has no signers.
This fixes the issue such that an entry is considered signed if at least one of
the
On Thu, 2 Dec 2021 12:13:03 GMT, Andrew Leonard wrote:
>> Addition of a configure option --with-cacerts-src='user cacerts folder' to
>> allow developers to specify their own cacerts PEM folder for generation of
>> the cacerts store using the deterministic openjdk GenerateCacerts tool.
>>
>>
On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov
wrote:
> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't
> touch primitive types casts.
The security related files look fine.
On Sun, 26 Sep 2021 15:10:52 GMT, Andrey Turbanov
wrote:
> In couple of classes, result part of arrays of Pattern.split is compared with
> `null`. Pattern.split (and hence String.split) never returns `null` in array
> elements. Such comparisons are redundant.
The AlgorithmDecomposer change
On Tue, 7 Sep 2021 07:12:29 GMT, Alan Bateman wrote:
>> There is a bug for URLClassPath.findResources with JarIndex.
>> With some discussions about the bug, the current priority is to remove the
>> JAR index support in URLClassPath,
>> and don’t need to do anything to the jar tool in the short
On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov
wrote:
> There are few places in code where manual while loop is used with Iterator to
> iterate over Collection.
> Instead of manual while cycles it's preferred to use enhanced-for cycle
> instead: it's less verbose, makes code easier to read
This change will disable JARs signed with algorithms using SHA-1 by default,
and treat them as unsigned. This applies to the algorithms used to digest,
sign, and optionally timestamp the JAR. It also applies to the signature and
digest algorithms of the certificates in the certificate chain of
On Tue, 31 Aug 2021 02:08:48 GMT, Weijun Wang wrote:
>> This change modifies the default value of the `java.security.manager` system
>> property from "allow" to "disallow". This means unless it's explicitly set
>> to "allow", any call to `System.setSecurityManager()` would throw an UOE.
>>
>>
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote:
> This change modifies the default value of the `java.security.manager` system
> property from "allow" to "disallow". This means unless it's explicitly set to
> "allow", any call to `System.setSecurityManager()` would throw an UOE.
>
> The
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov
wrote:
> I found few places, where code initially perform `Object[]
> Colleciton.toArray()` call and then manually copy array into another array
> with required type.
> This PR cleanups such places to more shorter call `T[]
>
On Fri, 18 Jun 2021 18:28:26 GMT, Sean Mullan wrote:
>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
>> use `ArrayList` if a thread-safe implementation is not needed. In
>> post-BiasedLocking times, this is gets worse, as every access is
>
On Mon, 14 Jun 2021 11:34:50 GMT, Andrey Turbanov
wrote:
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
> use `ArrayList` if a thread-safe implementation is not needed.
> I checked only places where `Vector` was used as local variable.
The change to
On 6/14/21 7:34 AM, Rafael Winterhalter wrote:
Why not add the property once this is the case, though? As it is now, I
read the 'forRemoval' property to indicate a problem that should be
instantly addressed. With Java 8 being a common baseline for libraries and
the version being supported
On Fri, 21 May 2021 15:27:39 GMT, Daniel Fuchs wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
>
On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang wrote:
>> Please review the test changes for [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> With JEP 411 and the default value of `-Djava.security.manager` becoming
>> `disallow`, tests calling `System.setSecurityManager()` need
>>
On Tue, 18 May 2021 15:19:21 GMT, Alan Bateman wrote:
>> It includes both:
>> 
>
> Thanks for checking, I assumed that was the case so wondering if it
On Tue, 18 May 2021 06:31:06 GMT, Alan Bateman wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Tue, 9 Mar 2021 22:19:28 GMT, Bradford Wetmore wrote:
>> Fix various things pointed out by the most recent doclint run in the
>> security-libs area.
>>
>> This is docs only: I will be checking doccheck/doclint, and will be running
>> tier1/tier2 tests. Minor spot checks on generated
On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore wrote:
>> Fix various things pointed out by the most recent doclint run in the
>> security-libs area.
>>
>> This is docs only: I will be checking doccheck/doclint, and will be running
>> tier1/tier2 tests. Minor spot checks on generated
On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore wrote:
>> Fix various things pointed out by the most recent doclint run in the
>> security-libs area.
>>
>> This is docs only: I will be checking doccheck/doclint, and will be running
>> tier1/tier2 tests. Minor spot checks on generated
On Fri, 19 Feb 2021 08:05:06 GMT, Andrey Turbanov
wrote:
>> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java
>> line 228:
>>
>>> 226: try {
>>> 227: if (is.markSupported() == false) {
>>> 228: // Copy the entire input stream into
On Mon, 15 Feb 2021 19:47:00 GMT, Andrey Turbanov
wrote:
>> 8080272 Refactor I/O stream copying to use
>> InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8080272:
On Thu, 14 Jan 2021 19:28:27 GMT, Alexey Bakhtin wrote:
> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
> Extension.
> Test from the bug report and jtreg javax/naming tests are passed.
Marked as reviewed by mullan (Reviewer).
-
PR:
On Wed, 20 Jan 2021 07:21:22 GMT, Alexey Bakhtin wrote:
> Unfortunately, I can not find any LDAP StartTLS Extended Operation regression
> tests. security/infra area contains RevocationChecker tests. They can not be
> used for this scenario.
Ok, please add a noreg-hard label to the bug.
On Thu, 14 Jan 2021 19:28:27 GMT, Alexey Bakhtin wrote:
> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
> Extension.
> Test from the bug report and jtreg javax/naming tests are passed.
Can you add a test for this or is it too hard? There are existing tests for
On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote:
> This is the security libs portion of the effort to replace
> archaic/non-inclusive words with more neutral terms (see JDK-8253315 for
> details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as
On Fri, 8 Jan 2021 21:30:14 GMT, Martin Balao wrote:
>> As described in JDK-8259319 [1], this fix proposal is to set proper access
>> permissions so the SunPKCS11 provider can create instances of SunJCE classes
>> when a Security Manager is installed and the fallback scheme is used.
>>
>> No
On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote:
> As described in JDK-8259319 [1], this fix proposal is to set proper access
> permissions so the SunPKCS11 provider can create instances of SunJCE classes
> when a Security Manager is installed and the fallback scheme is used.
>
> No
On Fri, 18 Dec 2020 14:42:38 GMT, PROgrm_JARvis
wrote:
> > MD5 and DES were removed as SE requirements in JDK 14. See
> > https://bugs.openjdk.java.net/browse/JDK-8214483 for more information.
> > However, there are no plans to remove the implementations from the JDK at
> > this time.
>
>
On Fri, 18 Dec 2020 14:29:00 GMT, PROgrm_JARvis
wrote:
>> There are pre-existing microbenchmarks for java.security under
>> test/micro/org/openjdk/bench/java/security
>>
>> You can build and run these using `make test TEST=micro:YourBenchmark`.
>> Refer to
>>
On Wed, 2 Dec 2020 20:45:11 GMT, Ivan Šipka wrote:
> Refactor
> `test/jdk/java/lang/SecurityManager/modules/CustomSecurityManager.sh` as java
> test.
Marked as reviewed by mullan (Reviewer).
test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java line
2:
> 1: /*
> 2: *
On Fri, 20 Nov 2020 15:50:11 GMT, Alan Bateman wrote:
> > Ok, but then how about putting a similar note in the javadoc for the
> > RuntimePermission "modifyThreadGroup" target?
>
> The "modifyThread" and "modifyThreadGroup" permission targets list methods
> that have been terminally
On Fri, 20 Nov 2020 14:49:16 GMT, Alan Bateman wrote:
> > I think it would be useful in the javadoc of the RuntimePermission targets
> > (stopThread, etc) to add a note/link that the corresponding method that the
> > permission applies to is terminally deprecated. Something as simple as
> >
On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman wrote:
> This change terminally deprecates the following methods defined by
> java.lang.ThreadGroup
>
> - stop
> - destroy
> - isDestroyed
> - setDaemon
> - isDaemon
>
> The stop method has been deprecated since=1.2 because it is inherently
On Thu, 17 Sep 2020 08:09:31 GMT, Сергей Цыпанов
wrote:
> Hello,
>
> is it possible to have a code review for the changes proposed in JDK-8251548
> (originally contributed via
> https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html)?
> Sean Mullan ha
Since this change affects security code, please make sure you add
security-...@openjdk.java.net on any followup code reviews.
Thanks,
Sean
On 9/1/20 10:44 AM, Andrew Haley wrote:
On 01/09/2020 11:53, Yangfei (Felix) wrote:
Sure, I am happy if the original author of the assembly code or
/2020 14:18, Sean Mullan wrote:
On 8/14/20 8:41 AM, Alexey Bakhtin wrote:
Hello Sean,
Thank you for review.
I’ve changed wording and replaced @code with @systemProperty (tested,
it works for module-info.java)
Thanks. Now that you know it works, I think you should change the
other properties
to @systemProperty to be consistent.
I think it is fine to do that as part of this fix.
--Sean
Updated webrev at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v15/
Regards
Alexey
On 14 Aug 2020, at 14:50, Sean Mullan wrote:
On the property wording, change "for LDAP conne
On the property wording, change "for LDAP connection" to "for an LDAP
connection".
Also, for the definition of the property, can you use the
"@systemProperty" annotation instead of "@code"? Does that work inside
the module-info.java file?
I added my name as Reviewer.
--Sean
On 7/30/20
On 8/13/20 1:21 PM, Jonathan Gibbons wrote:
---
old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java
2020-07-25 23:46:21.233726447 +0530
+++
new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java
2020-07-25 23:46:20.721720857 +0530
@@ -96,8 +96,6 @@
On 8/13/20 11:05 AM, Julia Boes wrote:
Hi Vipin,
Thanks for providing this fix, I'm happy to sponsor your change. To
complete the review, we still need someone to green light the remaining
changes below. I'm looping in net-dev and security-dev to have a look.
Bug:
e same comment applies to the comment block on
lines 207-210 in src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
--Sean
[1] https://mail.openjdk.java.net/pipermail/net-dev/2020-July/014148.html
Regards
Alexey
On 7 Jul 2020, at 02:30, Sean Mullan wrote:
Thanks for that extra info.
I
full context of LDAP Connection code that initiates the SSL
handshake could be viewed here:
https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L345
-- Aleksei
On 06/07/2020 21:11, Sean Mullan wrote:
Hi Alexey,
This may have been discussed alr
Hi Alexey,
This may have been discussed already, but can you explain why the
"com.sun.jndi.ldap.connect.timeout" property needs to be set in order to
use this feature? That property is mostly used in tests to avoid long
socket timeouts, etc.
Why does that need to be set? What problem are
On 6/24/20 2:56 PM, Daniel Fuchs wrote:
The JNDI/LDAP part looks mostly good. You will need someone
from the security libs to review the security lib part of the
changes.
I have previously reviewed it but I would like to give it another once
over. Max should also review the final version as
Adding core-libs-dev ...
--Sean
On 6/9/20 5:15 PM, Mkrtchyan, Tigran wrote:
Hi all,
with Java-11 we have notice a thread leak with ldap module.
We use LDAP to authenticate users with username+pasword by
directly calling LdapLoginModule. This was ok with java 7 and
java 8. With java 11 we see
-for-authentication
So, it is hard to say - is it a standard or Microsoft implementation
specific
Regards
Alexey
On 9 Jun 2020, at 18:35, Sean Mullan wrote:
On 6/8/20 5:33 PM, Alexey Bakhtin wrote:
Hello Sean,
Yes, I think we'll need CSR and release notes as soon as this patch
adds new property.
I
y where
this format is defined, so I am wondering if this is a standard encoding
or not.
Thanks,
Sean
[1] -
https://support.microsoft.com/en-au/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry
Regards
Alexey
On 8 Jun 2020, at 22:03, Sean Mullan wrote:
(resending to all
(resending to all lists on the review)
I'm just catching up a bit on this review.
Sorry if this has mentioned before, but are you planning to write a CSR
and release note? I think this is needed for the
com.sun.jndi.ldap.tls.cbtype property. I'm also wondering if this
property should be
The security changes look fine to me.
--Sean
On 4/8/20 7:50 AM, Pavel Rappo wrote:
Vipin, here you go:
https://bugs.openjdk.java.net/browse/JDK-8242366
http://cr.openjdk.java.net/~prappo/8242366/webrev.00/
I took the liberty of additionally fixing a couple of parameters' names,
a
I think you forgot to attach the patch.
--Sean
On 2/28/20 2:28 AM, Adam Sotona wrote:
Hi,
I would like to ask for review of the attached patch removing dead code from
jar tool
Class files sun.tools.jar.Manifest and sun.tools.jar.SignatureFile appear to be
dead code and should be removed.
Hi Roger,
Does setting jdk.serialFilter with Security.setProperty() work, or must
it only be pre-configured in the java.security file?
--Sean
On 1/24/20 2:51 PM, Roger Riggs wrote:
Please review a doc change in the description of the initialization of
the jdk.serialFilter from
a system
Hi Ivan,
The fix looks good. Good catch.
--Sean
On 8/30/19 7:32 PM, Ivan Gerasimov wrote:
Hello!
In the two implementations of PermissionCollection.implies(Permission),
all the permissions are traversed, and their corresponding bit mask are
checked.
For example, here's a snippet from
This is in the security-libs area, not core-libs. Cross-posting to
security-dev and bcc-ing core-libs-dev.
--Sean
On 9/12/19 6:40 AM, Thomas Stüfe wrote:
Hi all,
may I please have reviews for the following trivial build fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8230910
webrev:
+1 from me as well.
--Sean
On 8/16/19 12:38 PM, Alan Bateman wrote:
On 16/08/2019 13:30, Claes Redestad wrote:
How about this:
http://cr.openjdk.java.net/~redestad/8229773/webrev.03/
Also simplified BuiltinClassLoader#getPermissions since the jrt-specific
optimization is now redundant.
Hi Claes,
I already reviewed an earlier version of this and this is pretty
similar. I did have a question about whether the default serialization
was ok - did you look into that more?
--Sean
On 8/15/19 6:03 AM, Claes Redestad wrote:
Hi,
by resolving permissions for code source URLs
On 7/9/19 7:40 PM, Brian Burkhalter wrote:
I don’t know. On the one hand this does not take an action like reading,
writing, or deleting, but on the other it could end up causing files to be left
lying around after VM termination which were expected to be deleted. I suppose
that could be
On 6/20/19 9:02 PM, Mandy Chung wrote:
On 6/20/19 1:40 PM, Sean Mullan wrote:
Sorry, I'm just catching up and looking at this now.
The one thing I don't like about these tests that use their own Policy
implementation is that the permissions that are granted inside the
test are granted to all
On 6/21/19 7:15 AM, Daniel Fuchs wrote:
Hi Sean,
On 20/06/2019 21:40, Sean Mullan wrote:
This could also be fixed in these tests by inspecting the CodeSource of
the ProtectionDomain. Or better yet, they should just use the jtreg
java.security.policy option and a policy file and avoid
Sorry, I'm just catching up and looking at this now.
The one thing I don't like about these tests that use their own Policy
implementation is that the permissions that are granted inside the test
are granted to all code, and not just the test, which may lead to cases
where permissions that
can always call url.openStream() now. I've
added core-libs-dev@o.j.n, maybe someone there can give a clear answer.
Thanks,
Max
On Mar 6, 2019, at 3:53 AM, Sean Mullan wrote:
Please review this fix to a regression introduced in JDK 9. An application run
with a SecurityManager and usi
Hi Andi,
TLS/JSSE topics are best discussed on the security-dev alias, so I am
copying that list for more discussion and -bcc-ing core-libs-dev.
--Sean
On 2/11/19 3:29 PM, Andi Mullaraj wrote:
Hi java-core community,
I have been directed to this channel to discuss matters related to Java
On 1/24/19 8:25 AM, Robert Marcano wrote:
On 1/23/19 8:59 AM, Sean Mullan wrote:
On 1/22/19 8:50 PM, Bernd Eckenfels wrote:
I don’t think the launcher is doing this, it is the class loader,
that’s nothing new. You can turn on verbose security debug to see it
in all versions.
Yes
On 1/22/19 8:50 PM, Bernd Eckenfels wrote:
I don’t think the launcher is doing this, it is the class loader, that’s
nothing new. You can turn on verbose security debug to see it in all versions.
Yes, and it only verifies the signature(s) on the JAR. It doesn't
validate the certificate chain.
Looks good.
--Sean
On 1/9/19 3:42 PM, Lance Andersen wrote:
Here is the webrev for the changes:
http://cr.openjdk.java.net/~lancea/8216362/webrev.00/index.html
Best
Lance
On Jan 9, 2019, at 12:13 PM, Sean Mullan <mailto:sean.mul...@oracle.com>> wrote:
On 1/8/19 7:17 PM, Philipp K
to be
overlapping with issue JDK-8216362 but then JDK-8216362 is about the jar
file name missing in an error message when it should be present and not
the other way round. Attached is a patch for JDK-8216362 as it is
described at the moment.
Philipp
On Tue, 2019-01-08 at 13:07 -0500, Sean Mullan wrote
In this case, the caller is passing in the filename through the public
JarFile API so as long as it is not modified it should be ok. The
concerns I raised previously are situations where the caller did not
pass in the file or the JDK converts a relative path to an absolute
path, which could
1 - 100 of 288 matches
Mail list logo
