JEP 411, removal of finalizers, a path forward.
The current JEP 411 plan of action, if left unchanged, will leave developers who adopted the SM architecture as an authorization layer unable to upgrade to later versions of Java, until finalizers and the finalizer attack defensive methods in constructors are removed. JEP 411 has the potential to cause significant disruption for a small proportion of Java developers, but doesn't have to if managed appropriately. The blocker is the ability to implement guard checks using Agents on public API, due to finalizer attack defensive private static methods in constructors. Allan has advised when finalizers are removed, it will be practical to use Agents to instrument public API to implement an authorization layer, this is try, so can it be coordinated with JEP 411 et al? Furthermore, as developers must support multiple Java releases, I propose the following amendments, to ease difficulties of multiple release support (with multi release jars): * AccessController, AccessControlContext, DomainCombiner and related Subject and Executors methods, remain until Java 8 is EOL in 2030. Also consider un-deprecation of these methods, as their removal causes shotgun surgery (used in 1000's of locations in my software alone) and they are required for preservation of Subject, used for obtaining TLS and Kerberos connection credentials on all existing versions of Java. * AccessControlContext - remove inherited thread context, replace it with an unprivileged ProtectionDomain, such that doPrivileged methods are required for authorization checks and only the current thread stack needs to be walked when checks occur, and stack walks aren't unnecessarily performed when creating new threads. This is compatible with Loom, update loom to allow the use of AccessControlContext to be used, to establish TLS and Kerberos connections. Loom will be very useful for network connections, especially long latency connections over the internet, which are typically secured using TLS. This removes the problem of viral checks, and Executor task privilege escalation. * Modules that are mapped to the boot loader should get a unique PD that includes a useful code source rather than using a "shared" PD, this allows us to reduce the privileged footprint of the Java platform libraries, to allow privileges to be granted to users, not code, or users and code. This is useful to limit data parsing privileges to authenticated users on servers (a practise that should be more widely encouraged). * Remove finalizers, and defensive methods in constructors where permissions check points occur as these cause problems for Agents, prior to removal of SecurityManager. * Deprecate for removal Permission implementations, then remove them in a following release. * Remove SecurityManager. This allows a forward migration path for poor sod's like myself who are currently using SM infrastructure as an authorization layer, and to establish TLS conenctions, this or at least some sort of compromise is far preferable to the thermonuclear option currently planned. What I would like OpenJDK to consider, is to allow developers like myself to continue to stay current with Java, by coordinating the removal of finalizers and defensive methods in constructors, with JEP 411, so we have a workable future migration path. Without these considerations, options are; go back to Java 8, and plan to redevelop existing software, if forced to do so, Java is unlikely to be on the list for redevelopment, simply because development costs are lower in newer languages, such as automated unit tests, https://hackage.haskell.org/package/QuickCheck, no need to worry about null pointers and less boilerplate. Don't get me wrong, I like Java and have many years experience with it, but I have to be pragmatic, it won't just be me, many other developers, when Java 8 is EOL, will work for companies stuck on that platform, simply due to the number of changes required, because they haven't kept up (eg budgets) with the current release cadence and pace of development, will be looking at redevelopment and replacement instead of migration. Clearly the current pace of development is a good thing for Java, but the overall strategy could be tweaked a little, to ensure migration doesn't become insurmountable. A healthy and vibrant Java community is essential for the survival of Java, Java has already shed phone and client markets, lets not shed too many more. Thanks, Peter
Re: Incorrect encoding of PKCS12 bag attributes
Am 2021-07-29 um 16:05 schrieb Sean Mullan:
Are you calling the PKCS12Attribute(String, String) constructor from
your code? That API currently specifies that String values are encoded
as UTF-8, so we could not change the behavior without a specification
change. Can you use the PKCS12Attribute(byte[]) constructor instead
which takes a DER-encoded value?
Hi Sean,
I don't use this API. I interact with
KeyStore javaTrustStore = KeyStore.getInstance("PKCS12");
javaTrustStore.load(null, null);
for (Rdn rdn : ldapName.getRdns()) {
if (rdn.getType().equalsIgnoreCase("CN"))
alias = (String) rdn.getValue();
}
javaTrustStore .setCertificateEntry(alias, cert);
only. So I am using a high level API. But even if I'd use this API and
pass the UCS-2 encoded byte array of that cert
CN=NetLock Arany (Class Gold) Főtanúsítvány,OU=Tanúsítványkiadók (Certification
Services),O=NetLock Kft.,L=Budapest,C=HU
The ASN.1 tag would still be incorrect for friendlyName
(1.2.840.113549.1.9.20) because it would OctetString and not BMPString.
It seems to be that the API, or ObjectIdentifier and KnownOIDs classes
miss to carry the ASN.1 tag for the actual value. Don't they?
Michael
PS: This CA
CN=E-Tugra Certification Authority,OU=E-Tugra Sertifikasyon Merkezi,O=E-Tuğra
EBG Bilişim Teknolojileri ve Hizmetleri A.Ş.,L=Ankara,C=TR
was smart enough to stick with US-ASCII only in the CN, but still
single-byte != two-byte UCS-2
On 6/14/21 3:21 PM, Osipov, Michael (LDA IT PLM) wrote:
Folks,
can someone confirm the following bug or tell me I am too stupid to read
the RFCs:
I have recently created a PKCS12-based trust store and had one CA from
Hungary with non-ASCII chars in the subject's CN RDN.
RFC 7292 for friendlyName refers to RFC 2985, section 5.5.1:
friendlyName ATTRIBUTE ::= {
WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
EQUALITY MATCHING RULE caseIgnoreMatch
SINGLE VALUE TRUE
ID pkcs-9-at-friendlyName
}
So a BMPString -- which is UCS-2 encoding. Looking at [1] shows that
Java ignores the RFC and always creates an UTF8String regardless of the
attribute OID, thus breaking the semantics of friendlyName.
Who's wrong here?
For some strange reason OpenSSL does it in a similar fashion:
In pkcs12.h.in:
> # define PKCS12_add_friendlyname PKCS12_add_friendlyname_utf8
where the function contains:
if (X509at_add1_attr_by_NID(>attrib, NID_friendlyName,
MBSTRING_UTF8, (unsigned char
*)name, namelen) != NULL)
[1]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F739769c8fc4b496f08a92225a12d07414537b6c0%2Fsrc%2Fjava.base%2Fshare%2Fclasses%2Fjava%2Fsecurity%2FPKCS12Attribute.java%23L230-L245data=04%7C01%7C9d76b566-97f1-4355-9dbf-6dcc0e8868d3%40ad011.siemens.com%7Cc475c3e0ca4b4dffe9e308d9529a0987%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637631643594135158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Yi0n7ZEXPHxas%2Fe17phd7ahX%2BXwlFXnCTJsYMqhLyZM%3Dreserved=0
Regards,
Michael
Integrated: 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert
On Tue, 20 Jul 2021 23:10:33 GMT, Rajan Halade wrote: > Update the test certificates. This pull request has now been integrated. Changeset: 4bc9b049 Author:Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/4bc9b049846bd59f5c41bd62a59b567b52c9efc5 Stats: 440 lines in 2 files changed: 141 ins; 233 del; 66 mod 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/4847
Re: RFR: 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert [v2]
> Update the test certificates. Rajan Halade has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8263059 - 8263059: update ProblemList.txt - 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert - Changes: https://git.openjdk.java.net/jdk/pull/4847/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4847=01 Stats: 440 lines in 2 files changed: 141 ins; 233 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/4847.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4847/head:pull/4847 PR: https://git.openjdk.java.net/jdk/pull/4847
Integrated: 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked
On Tue, 20 Jul 2021 23:50:44 GMT, Rajan Halade wrote: > Test certificates are updated. This pull request has now been integrated. Changeset: d6bb8461 Author:Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/d6bb846159be7e46fba0c3ca2915617f945e0b42 Stats: 380 lines in 2 files changed: 34 ins; 32 del; 314 mod 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/4849
Re: RFR: 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked [v2]
> Test certificates are updated. Rajan Halade has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8248899 - 8248899: update ProblemList.txt - 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked - Changes: https://git.openjdk.java.net/jdk/pull/4849/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4849=01 Stats: 380 lines in 2 files changed: 34 ins; 32 del; 314 mod Patch: https://git.openjdk.java.net/jdk/pull/4849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4849/head:pull/4849 PR: https://git.openjdk.java.net/jdk/pull/4849
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Thu, 22 Jul 2021 22:52:14 GMT, Anthony Scarpino wrote: >> Yes, I know. Basically, we are trying to optimize performance by trying to >> write into the supplied buffers (out) as much as we can. But then when tag >> verification failed, the "written" bytes are erased w/ 0. Ideal case would >> be not to touch the output buffer until after the tag verification succeeds. >> Isn't this the previous approach? Verify the tag first and then write out >> the plain text afterwards. > > With this new intrinsic doing both ghash and gctr at the same time, I cannot > do the that ghash check first before the gctr op. I wish I could Oh-well, ok. - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Fri, 30 Jul 2021 18:40:14 GMT, Smita Kamath wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java >> line 717: >> >>> 715: in = new byte[Math.min(PARALLEL_LEN, srcLen)]; >>> 716: out = new byte[Math.min(PARALLEL_LEN, srcLen)]; >>> 717: } >> >> Move this down to else-block below just like the 'ct' variable. > > I've kept this code as is and not moved as recommended. If we move this line > to the else part, the case where srcLen is less than PARALLEL_LEN but greater > than BlockSize, in[] is null. As a result, three tests in > test/jdk/../Cipher/AEAD were failing on src.get(in, 0, rlen) line. Do let me > know if that's okay. Thanks. Hmm, I see. Sure, fine to keep it as is then. - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Thu, 22 Jul 2021 17:57:13 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java >> line 761: >> >>> 759: } >>> 760: >>> 761: dst.put(out, 0, rlen); >> >> This looks belong to the above if-block? I wonder how this have not affected >> the operation to fail. Perhaps the existing regression tests did not cover >> the 'rlen < blockSize' case. If the code in the above if-block is not run, >> this outsize dst.put(...) call would put extra output bytes into the output >> buffer. > > Yes... this one and the ct offset problem earlier I would have expected the > regression test it pick the mistake. There should be tests that catch this.. > I'm not sure what's up. This shall be addressed in next update I assume? - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert
On Tue, 20 Jul 2021 23:10:33 GMT, Rajan Halade wrote: > Update the test certificates. Marked as reviewed by mullan (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4847
Re: RFR: 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked
On Tue, 20 Jul 2021 23:50:44 GMT, Rajan Halade wrote: > Test certificates are updated. Marked as reviewed by mullan (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4849
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Fri, 30 Jul 2021 18:23:18 GMT, Valerie Peng wrote: >> Ok.. Moving it into GCMEncrypt makes sense. Now that I look at the code >> GCMDecrypt only uses it when passed to a method. GCMEncrypt uses it > > This is still present in the latest update. Is there another update coming? Yes. - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v6]
> I would like to submit AES-GCM optimization for x86_64 architectures > supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES > and GHASH operations. > Performance gain of ~1.5x - 2x for message sizes 8k and above. Smita Kamath has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - changed file property of GaloisCounterMode.java - Merge branch 'master' of https://git.openjdk.java.net/jdk into aes-gcm - Extended jtreg test case, made changes to .cpp and .java files - Updated AES-GCM intrinsic to match latest Java Code - merge master - 8267125:Updated intrinsic signature to remove copies of counter, state and subkeyHtbl - Merge master - JDK-8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions - Changes: https://git.openjdk.java.net/jdk/pull/4019/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4019=05 Stats: 1320 lines in 21 files changed: 1148 ins; 100 del; 72 mod Patch: https://git.openjdk.java.net/jdk/pull/4019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019 PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Mon, 19 Jul 2021 19:18:54 GMT, Valerie Peng wrote: >> Smita Kamath has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Updated AES-GCM intrinsic to match latest Java Code > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java > line 717: > >> 715: in = new byte[Math.min(PARALLEL_LEN, srcLen)]; >> 716: out = new byte[Math.min(PARALLEL_LEN, srcLen)]; >> 717: } > > Move this down to else-block below just like the 'ct' variable. I've kept this code as is and not moved as recommended. If we move this line to the else part, the case where srcLen is less than PARALLEL_LEN but greater than BlockSize, in[] is null. As a result, three tests in test/jdk/../Cipher/AEAD were failing on src.get(in, 0, rlen) line. Do let me know if that's okay. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Fri, 30 Jul 2021 18:23:44 GMT, Valerie Peng wrote: >> ok > > This is still present in the latest update. Is there another update coming? Yes. There will be another update. - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Thu, 22 Jul 2021 17:16:45 GMT, Anthony Scarpino wrote: >> Seems strange to have GCMOperation op defined in GCMEngine but not >> initialized, nor used. The methods in GCMEngine which use op has an argument >> named op anyway. Either you just use the "op" field (remove the "op" >> argument) or the "op" argument (move the op field to GCMEncrypt/GCMDecrypt >> class). Having both looks confusing. > > Ok.. Moving it into GCMEncrypt makes sense. Now that I look at the code > GCMDecrypt only uses it when passed to a method. GCMEncrypt uses it This is still present in the latest update. Is there another update coming? - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
On Thu, 22 Jul 2021 17:19:20 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java >> line 650: >> >>> 648: int originalOutOfs = 0; >>> 649: byte[] in; >>> 650: byte[] out; >> >> The name "in", "out" are almost used in all calls, it's hard to tell when >> these two are actually used. Can we rename them to make them more unique? > > ok This is still present in the latest update. Is there another update coming? - PR: https://git.openjdk.java.net/jdk/pull/4019
Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package
On Thu, 29 Jul 2021 01:30:37 GMT, Vladimir Kozlov wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves >> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >> - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` >> - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` >> - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` >> - `s/sun.hotspot.code/jdk.test.whitebox.code/g` >> - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` >> - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` >> >> testing: tier1-4 >> >> Thanks, >> -- Igor > > I know that tests fixes could be pushed during RDP2 without approval. > But these one is very big and it is not a fix - it is enhancement. > > What is the reason you want to push it into JDK 17 just few days before first > Release Candidate? Instead of pushing it into JDK 18. > > And I can't even review it because GutHub UI hangs on these big changes. @vnkozlov, @dholmes-ora, Thank you for looking at this! I want this to be integrated into JDK 17 b/c some "external" libraries use (used to use) WhiteBox API, e.g. jcstress[[2]] used WhiteBox API to deoptimize compiled methods[[3]], and it would be easier for maintainers of such libraries to condition package name based on JDK major version. Also, given JDK 17 is an LTS, it would be beneficial for everyone not to have big differences in test bases b/w it and the mainline. according to JEP 3, test RFEs are allowed until the very end and don't require late enhancement approval: "Enhancements to tests and documentation during RDP 1 and RDP 2 do not require approval, as long as the relevant issues are identified with a noreg-self or noreg-doc label, as appropriate"[[1]]. So, process-wise, I don't see any issues w/ integrating this RFE, yet, I fully agree that due to its size, this patch can be disruptive and can cause massive failures, which is something we obviously don't want at the current stage of JDK 17. I like David's idea about phasing this clean-up, and, due to the reasons described above, I would like to integrate the first part, copying WhiteBox classes to the new package structure and associated changes w/o updating all the tests, into JDK 17 and update the tests on the mainline (w/ backporting into jdk17u). WDYT? Cheers, -- Igor [1]: https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process [2]: https://github.com/openjdk/jcstress [3]: https://github.com/openjdk/jcstress/blob/df83b446f187ae0b0fa31fa54decb59db9e955da/jcstress-core/src/main/java/org/openjdk/jcstress/vm/WhiteBoxSupport.java - PR: https://git.openjdk.java.net/jdk17/pull/290
Integrated: 8232066: Remove outdated code/methods from PKIX implementation
On Thu, 29 Jul 2021 14:24:52 GMT, Sean Mullan wrote: > Please review this fix to remove the Validator.VAR_PLUGIN_CODE_SIGNING > variant and related code that is no longer needed in the PKIX implementation. This pull request has now been integrated. Changeset: 89f5c96d Author:Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/89f5c96d63a7a08e0b4145eee83a946fc99141e4 Stats: 196 lines in 8 files changed: 0 ins; 182 del; 14 mod 8232066: Remove outdated code/methods from PKIX implementation Reviewed-by: weijun - PR: https://git.openjdk.java.net/jdk/pull/4934
