RFR: 8229773: Resolve permissions for code source URLs lazily

Hi, by resolving permissions for code source URLs lazily, we can reduce early class loading during bootstrap, which improves footprint, startup and reduces the typical bootstrap dependency graph. Bug:https://bugs.openjdk.java.net/browse/JDK-8229773 Webrev: http://cr.openjdk.java.net/~redesta

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

On 15/08/2019 11:03, Claes Redestad wrote: Hi, by resolving permissions for code source URLs lazily, we can reduce early class loading during bootstrap, which improves footprint, startup and reduces the typical bootstrap dependency graph. Bug:    https://bugs.openjdk.java.net/browse/JDK-8229773

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Hi, On 2019-08-15 12:56, Alan Bateman wrote: On 15/08/2019 11:03, Claes Redestad wrote: Hi, by resolving permissions for code source URLs lazily, we can reduce early class loading during bootstrap, which improves footprint, startup and reduces the typical bootstrap dependency graph. Bug:    h

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

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 lazily,

[14] RFR 8229775: Incorrect warning when jar was signed with -sectionsonly

Please take a review at http://cr.openjdk.java.net/~weijun/8229775/webrev.00/ The updated code checks both SHA-256-Digest-Manifest and SHA-256-Digest-Manifest-Main-Attributes. The latter should always appear in a SF file generated by our own jarsigner but theoretically it could be missing if

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Hi Sean, On 2019-08-15 15:07, Sean Mullan wrote: 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? ah, yes.. all the constituents are serializable (whether w

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Hi Claes, I would recommend using writeReplace to serialize the PermissionCollection so the serialized form does not change. Though these are unlikely to be serialized, it will be less likely to trigger some interoperability issue between different version. It may need to be documented that se

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Hi Claes, I wonder if initialize() should check the state of the readOnly() flag - and if that's true, call perms.setReadOnly() ? see SecureClassLoader::getProtectionDomain(..) best regards, -- daniel On 15/08/2019 13:44, Claes Redestad wrote: Hi, On 2019-08-15 12:56, Alan Bateman wrote: O

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Hi Daniel, seems prudent, especially if we are to writeReplace the underlying collection on serialization. /Claes On 2019-08-15 17:10, Daniel Fuchs wrote: Hi Claes, I wonder if initialize() should check the state of the readOnly() flag - and if that's true, call perms.setReadOnly() ? see Sec

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

(adding back core-libs-dev) Hi Roger, seems easy enough to add a writeReplace: http://cr.openjdk.java.net/~redestad/8229773/webrev.02 /Claes On 2019-08-15 16:54, Roger Riggs wrote: Hi Claes, I would recommend using writeReplace to serialize the PermissionCollection so the serialized form d

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Looks good, Thanks, Roger On 8/15/19 11:22 AM, Claes Redestad wrote: (adding back core-libs-dev) Hi Roger, seems easy enough to add a writeReplace: http://cr.openjdk.java.net/~redestad/8229773/webrev.02 /Claes On 2019-08-15 16:54, Roger Riggs wrote: Hi Claes, I would recommend using wri

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Thanks Claes, Looks good to me too. best regards, -- daniel On 15/08/2019 16:27, Roger Riggs wrote: Looks good, Thanks, Roger On 8/15/19 11:22 AM, Claes Redestad wrote: (adding back core-libs-dev) Hi Roger, seems easy enough to add a writeReplace: http://cr.openjdk.java.net/~redestad/8

Re: [14] RFR 8229775: Incorrect warning when jar was signed with -sectionsonly

Looks fine to me. --Sean On 8/15/19 9:34 AM, Weijun Wang wrote: Please take a review at http://cr.openjdk.java.net/~weijun/8229775/webrev.00/ The updated code checks both SHA-256-Digest-Manifest and SHA-256-Digest-Manifest-Main-Attributes. The latter should always appear in a SF file ge

Re Re: [14] RFR 8162628: Migrate cacerts keystore from JKS

> > On Aug 14, 2019, at 3:23 AM, Michael Osipov <[email protected]> wrote: > > > > Am 2019-08-13 um 18:23 schrieb Weijun Wang: > >> Please take a preliminary review at > >> > >>https://cr.openjdk.java.net/~weijun/8162628/webrev.00 > >> > >> There is no test yet. I mainly want you to see if thi

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

On 15/08/2019 16:22, Claes Redestad wrote: (adding back core-libs-dev) Hi Roger, seems easy enough to add a writeReplace: http://cr.openjdk.java.net/~redestad/8229773/webrev.02 This mostly looks good. In LazyCodeSourcePermissionCollection it think "initialize" should be renamed to "ensureAdde

RFR 8005819: Support cross-realm MSSFU

Hi, I'd like to propose Webrev.00 for JDK-8005819 [1]: * http://cr.openjdk.java.net/~mbalao/webrevs/8005819/8005819.webrev.00/ Implementation is based in the MS-SFU document [2]. Testing * ReferralsTest extended to support S4U2Self and S4U2Proxy referrals * No regressions found in jdk/sun/

[14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4"

Anyone has time to help review this fix? PKCS#11 v2.40 has inconsistent definition for CK_GCM_PARAMS struct. The mechanism spec (sec 2..12.3) has: typedef struct CK_GCM_PARAMS {     CK_BYTE_PTR   pIv;     CK_ULONG  ulIvLen;     CK_BYTE_PTR   pAAD;     CK_ULONG 

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Hi Roger, +1 for writeReplace Personally I'd like to see some security classes break backward compatibility and remove support for serialization as it allows someone to get references to internal objects, especially since these classes are cached by the JVM. Which makes PermissionCollection.

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Hello Claes, The following code is included in the constructor of our SecurityManager implementation, I suspect we may need to add some classes to this list, perhaps this is something that needs documenting? Regards, Peter. /* The following ensures the classes we need are loaded early to av

RE: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions.

Hi Vladimir Can I sponsor and push the patch since you and Valerie have reviewed the patch? Regards, Vivek From: Valerie Peng [mailto:[email protected]] Sent: Friday, August 2, 2019 5:09 PM To: Vladimir Kozlov ; Rukmannagari, Shravya ; Kamath, Smita ; 'Anthony Scarpino' Cc: OpenJDK Sec

RE: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions.

Hi Vladimir, Thanks a lot for the review. I have responded to the JBS bug with the use cases for ECB. Please find the updated webrev with no changes to the config file. http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.02/ Thanks, Shravya. -Original Message- From: Vladimir Kozlov [ma

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Hello Alan, This is related to URL and CodeSource and might be worth making a note of for future reference. Our software uses delayed dynamically assigned permissions via a policy provider, but for privileged domains that have AllPermission we make sure to assign this up front (We also utili

Re: RFR 8005819: Support cross-realm MSSFU

> On Aug 16, 2019, at 6:31 AM, Martin Balao wrote: > > Hi, > > I'd like to propose Webrev.00 for JDK-8005819 [1]: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8005819/8005819.webrev.00/ > > Implementation is based in the MS-SFU document [2]. > > Testing > > * ReferralsTest extended to

Re: Re Re: [14] RFR 8162628: Migrate cacerts keystore from JKS

> On Aug 16, 2019, at 2:49 AM, Michael Osipov <[email protected]> wrote: > https://cr.openjdk.java.net/~weijun/8162628/webrev.00 >>> KeyStoreDelegator: >>> * Please avoid iterating a list like an array and using List#get(int). >> >> But I have 2 lists. It is a Pair but Java does