Re: RFR: 8248268: Support KWP in addition to KW [v7]

2021-05-22 Thread Michael StJohns
On 5/22/2021 1:57 PM, Xue-Lei Andrew Fan wrote: On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng wrote: This change updates SunJCE provider as below: - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding. Ex

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-22 Thread Alan Bateman
On 22/05/2021 11:58, Bernd Eckenfels wrote: : This whole discussion about using only secure libraries really makes me wonder if you know the realities of modern applications with hundreds of dependencies and the state of those, like there is still no easy way to limit XXE in upstream xerces.

Re: RFR: 8248268: Support KWP in addition to KW [v7]

2021-05-22 Thread Xue-Lei Andrew Fan
On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng wrote: >> This change updates SunJCE provider as below: >> - updated existing AESWrap support with AES/KW/NoPadding cipher >> transformation. >> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding. >> >> Existing AESWrap impl, i.e. AESWr

Re: RFR: 8248268: Support KWP in addition to KW [v7]

2021-05-22 Thread Michael StJohns
In line On 5/21/2021 5:01 PM, Xue-Lei Andrew Fan wrote: On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng wrote: This change updates SunJCE provider as below: - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. - added support for AES/KWP/NoPadding and AES/KW/PKCS5Pad

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-22 Thread Ron Pressler
It is precisely because security is more important now than ever and both the threat environment and security measure landscape are changing that this proposal is important. There have been several good suggestions brought up —- like platform-independent access to platform-specific defences —- a

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-22 Thread Bernd Eckenfels
Hello, I have to agree with Peter here, we do remove a very valuable asset of the JVM platform. It might not easy to be used and not the most popular technology, but after all it was in the DNA of Java. In this JEP/Discussion there is not a single hesitation to remove it. Please tell me you tr

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

2021-05-22 Thread Peter Tribble
On Sat, May 22, 2021 at 2:12 AM Ron Pressler wrote: > Let me be very clear: the proposers of this JEP, some of whom have worked > on the Security Manager for the > last twenty years, strongly believe that not only will its removal not > harm Java’s security, but considerably > improve it, as do t

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

2021-05-22 Thread Alan Bateman
On Fri, 21 May 2021 18:00:13 GMT, Phil Race wrote: > Are you suggesting that the patch doesn't need testing as it is ? It should > be the same either way. > It is very straight forward to run the automated tests across all platforms > these days. > I get the impression that no one is guaranteei