Re: RFR: 8248268: Support KWP in addition to KW [v7]
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.
Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to
KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class.
The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes
which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data
copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the
same input buffer which is allocated and managed by KeyWrapCipher class.
Also note that existing AESWrap impl does not take IV. However, the
corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to
both KW and KWP.
Thanks,
Valerie
Valerie Peng has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains seven commits:
- Merge master into JDK-8248268
- Minor update to address review comments.
- Changed AESParameters to allow 4-byte, 8-byte IVs and removed
KWParameters and KWPParameters.
- Refactor code to reduce code duplication
Address review comments
Add more test vectors
- Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
AES/KWP/NoPadding
- Restored Iv algorithm parameters impl.
- 8248268: Support KWP in addition to KW
Updated existing AESWrap support with AES/KW/NoPadding cipher
transformation. Added support for AES/KWP/NoPadding and
AES/KW/PKCS5Padding support to SunJCE provider.
Good points, Mike! Thank you!
_Mailing list message from [Michael StJohns](mailto:mstjo...@comcast.net) on
[security-dev](mailto:security-...@mail.openjdk.java.net):_
src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java line 50:
48:
49: public AESParameters() {
50: core = new BlockCipherParamsCore(AESConstants.AES_BLOCK_SIZE, 4, 8);
A cipher object may not take different IV sizes at the same time. I was just
wondering how it could be used in practice. Maybe something like:
The mode is KW - it has a fixed length 8 byte non-iv integrity tag.???
KWP is a special case of KW where there's still an 8 byte tag, but part
of it is interpreted by KWP to figure out how much padding was
included.?? KW (AKA RFC3394) permits user (actually specification
specified) IV values.? KWP (aka RFC5649) does not.
Hm, I missed this point. KW (RFC 3394) supports Alternative IV (AIV), while
KWP is just a case about how to construct the alternative IV for KWP operations.
Yes. Sorry if I wasn't clearer in earlier emails.
I'd treat KWP as a final (in the Java final sense) extension to KW with
a fixed AIV flag value and a defined interpretation for the 8 byte AIV
tag.? E.g. if you try to specify an IV for KWP, it should fail.?? If
someone else wants to do something like KWP or even twiddle with the 4
byte AIV, let them do their own KW wrap around - which they should be
able to do that via the KW/NoPadding model by specifying their own AIV.?
That should improve interoperability by preventing some monkey see
monkey do errors.
I agreed. Maybe, we could do:
1. Support Alternative IV for KW, for the flexibility as described in section
2.2.3.2 of RFC 3394.
I think that's acceptable. Hmm... is it possible to make the set ICV
call protected rather than public? Generally, the defined ICVs match
up with specific algorithm OIDS. You shouldn't see a third one unless
someone defines a brand new variant. But you want to make it possible
for someone to do an extension.
2. Use default IV if no AIV specified for KW, as described in section 2.2.3.1
of RFC 3394.
Works. Or see the above.
3. Use a fixed IV for KWP, as described in section 3of RFC 5649.
Yes.
This is sort of one reason I was arguing for AES/KW/KWPPadding rather
than AES/KWP/NoPadding.
I thought of the "AES/KW/KWPPadding" style as well. The "AES/KWP/NoPadding" looks a
little bit weird to me because there is padding while we call it with "NoPadding".
KWP is not exactly like the traditional AES/CBC/PKCS5Padding, where the
components could be treated separately. The padding scheme of KWP impact the
IV as well. So it was arguable to me.
We keep referring to it as an IV - but it isn't - it's an Integrity
Check Value. Unlike an IV, it doesn't inform the decryption stage, it's
only checked after the decryption is complete. (E.g. in a mode with an
IV, you need to know the IV before you encrypt and before you decrypt).
Then there's this from Section 6.3 of SP800-38F.
Let S = ICV2|| [len(P)/8]32 || P|| PAD
Step 5 of the KWP-AE algorithm basically passes the A65959A6 value
pre-prepended to the pad length both pre-pended to the padded data
through to W().
The equivalent for KW-AE is step 2
Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
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. (Or Have you ever tried to set FSP on a Transformer?), limit deserialisation, restrict url handlers, impersonate Users (local and remote filesystem), run chroot child’s or pass credentials over named pipes. All mechanisms which are easier to do in other programming environments. There is a big hesitation to even offer those platform specific features. You've touched on a number of topics here, some of them quite far away from JEP 411 but okay. I think the issues with deploying an applications with hundreds of dependences and with a SM are well understood here. It tends to be whack-a-mole because so many libraries were developed without any consideration for the SM execution mode. The result is often granting AllPermission to many libraries just to get something working. XXE and secure XML processing is something that needs to be decoupled from the SM. As the JEP lists, there is potential future work to enable FSP by default. Now might be the time to bring up usability and other issues with FSP as I think it will be tricky transition to move to secure by default. I can't comment on Xerces as the code maintained in OpenJDK has diverged quite a bit, esp. with security features. There has been significant efforts to limit deserialization. JEP 415 is a candidate right now, as a follow from on JEP 290. If integration with native code and system calls is part of your concern then looking at Project Panama's foreign function API as it has made great strides in the last year or so. JEP 412 is targeted to JDK 17 to continue the incubation of the API and trying it out with code that uses named pipes would be great. JEP 380 added Unix domain socket support in JDK 16 and that includes the ability to obtain peer credentials, maybe that is close to what you are looking for. -Alan
Re: RFR: 8248268: Support KWP in addition to KW [v7]
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. AESWrapCipher class, is re-factored and renamed
>> to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil
>> class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded
>> classes which extend FeedbackCipher and used in KeyWrapCipher class. To
>> minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto
>> operation over the same input buffer which is allocated and managed by
>> KeyWrapCipher class.
>>
>> Also note that existing AESWrap impl does not take IV. However, the
>> corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to
>> both KW and KWP.
>>
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains seven commits:
>
> - Merge master into JDK-8248268
> - Minor update to address review comments.
> - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>KWParameters and KWPParameters.
> - Refactor code to reduce code duplication
>Address review comments
>Add more test vectors
> - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>AES/KWP/NoPadding
> - Restored Iv algorithm parameters impl.
> - 8248268: Support KWP in addition to KW
>
>Updated existing AESWrap support with AES/KW/NoPadding cipher
>transformation. Added support for AES/KWP/NoPadding and
>AES/KW/PKCS5Padding support to SunJCE provider.
Good points, Mike! Thank you!
> _Mailing list message from [Michael StJohns](mailto:mstjo...@comcast.net) on
> [security-dev](mailto:security-...@mail.openjdk.java.net):_
> > src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java line
> > 50:
> > > 48:
> > > 49: public AESParameters() {
> > > 50: core = new BlockCipherParamsCore(AESConstants.AES_BLOCK_SIZE,
> > > 4, 8);
> > > A cipher object may not take different IV sizes at the same time. I was
> > > just wondering how it could be used in practice. Maybe something like:
>
> The mode is KW - it has a fixed length 8 byte non-iv integrity tag.???
> KWP is a special case of KW where there's still an 8 byte tag, but part
> of it is interpreted by KWP to figure out how much padding was
> included.?? KW (AKA RFC3394) permits user (actually specification
> specified) IV values.? KWP (aka RFC5649) does not.
>
Hm, I missed this point. KW (RFC 3394) supports Alternative IV (AIV), while
KWP is just a case about how to construct the alternative IV for KWP operations.
> I'd treat KWP as a final (in the Java final sense) extension to KW with
> a fixed AIV flag value and a defined interpretation for the 8 byte AIV
> tag.? E.g. if you try to specify an IV for KWP, it should fail.?? If
> someone else wants to do something like KWP or even twiddle with the 4
> byte AIV, let them do their own KW wrap around - which they should be
> able to do that via the KW/NoPadding model by specifying their own AIV.?
> That should improve interoperability by preventing some monkey see
> monkey do errors.
>
I agreed. Maybe, we could do:
1. Support Alternative IV for KW, for the flexibility as described in section
2.2.3.2 of RFC 3394.
2. Use default IV if no AIV specified for KW, as described in section 2.2.3.1
of RFC 3394.
3. Use a fixed IV for KWP, as described in section 3of RFC 5649.
> This is sort of one reason I was arguing for AES/KW/KWPPadding rather
> than AES/KWP/NoPadding.
>
I thought of the "AES/KW/KWPPadding" style as well. The "AES/KWP/NoPadding"
looks a little bit weird to me because there is padding while we call it with
"NoPadding".
KWP is not exactly like the traditional AES/CBC/PKCS5Padding, where the
components could be treated separately. The padding scheme of KWP impact the
IV as well. So it was arguable to me.
Finally I feel better of the "AES/KWP/NoPadding" when I read the NIST SP title
again, "Recommendation for Block Cipher Modes of Operation: Methods for Key
Wrapping". Maybe, it is an industry accepted notation to treat KWP as a block
cipher mode.
-
PR: https://git.openjdk.java.net/jdk/pull/2404
Re: RFR: 8248268: Support KWP in addition to KW [v7]
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/PKCS5Padding.
Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to
KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class.
The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes
which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data
copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the
same input buffer which is allocated and managed by KeyWrapCipher class.
Also note that existing AESWrap impl does not take IV. However, the
corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to
both KW and KWP.
Thanks,
Valerie
Valerie Peng has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains seven commits:
- Merge master into JDK-8248268
- Minor update to address review comments.
- Changed AESParameters to allow 4-byte, 8-byte IVs and removed
KWParameters and KWPParameters.
- Refactor code to reduce code duplication
Address review comments
Add more test vectors
- Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
AES/KWP/NoPadding
- Restored Iv algorithm parameters impl.
- 8248268: Support KWP in addition to KW
Updated existing AESWrap support with AES/KW/NoPadding cipher
transformation. Added support for AES/KWP/NoPadding and
AES/KW/PKCS5Padding support to SunJCE provider.
src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java line 50:
48:
49: public AESParameters() {
50: core = new BlockCipherParamsCore(AESConstants.AES_BLOCK_SIZE, 4, 8);
A cipher object may not take different IV sizes at the same time. I was just
wondering how it could be used in practice. Maybe something like:
The mode is KW - it has a fixed length 8 byte non-iv integrity tag.
KWP is a special case of KW where there's still an 8 byte tag, but part
of it is interpreted by KWP to figure out how much padding was
included. KW (AKA RFC3394) permits user (actually specification
specified) IV values. KWP (aka RFC5649) does not.
I'd treat KWP as a final (in the Java final sense) extension to KW with
a fixed AIV flag value and a defined interpretation for the 8 byte AIV
tag. E.g. if you try to specify an IV for KWP, it should fail. If
someone else wants to do something like KWP or even twiddle with the 4
byte AIV, let them do their own KW wrap around - which they should be
able to do that via the KW/NoPadding model by specifying their own AIV.
That should improve interoperability by preventing some monkey see
monkey do errors.
This is sort of one reason I was arguing for AES/KW/KWPPadding rather
than AES/KWP/NoPadding.
Mike
AlgorithmParameters algParams = AlgorithmParameters.getInstance("AES");
algParams.init(ivParameterSpec);
The IV parameter is given with the init() method. Then, it may be not
necessary to construct the BlockCipherParamsCore object will all potential IV
sizes. See the comments in BlockCipherParamsCore.
src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java
line 52:
50: private byte[] iv = null;
51:
52: private int[] moreSizes = null;
The moreSizes is not used other than the init() method field. It may be not
easy to check the specific size if we cache all supported sized in the object.
For example, if the required IV size if 8 bytes, it may be a problem about how
to make sure the iv size is 8 bytes exactly for a specific algorithm.
Maybe, we could just have a ivSize filed. The default value is block_size,
which coupe be set with the init(ivParameterSpec) method.
private int ivSize;
...
BlockCipherParamsCore(int blkSize) {
block_size = blkSize;
ivSize = blkSize;
}
...
void init(AlgorithmParameterSpec paramSpec) {
ivSize = ...; // reset IV size.
}
// use ivSize while encoding and decoding.
src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java
line 81:
79: expectedLen + " bytes long");
80: }
81: iv = tmpIv.clone();
The moreSizes is not used after initialization. The iv/tmpIv could be a value
other than the block_size. The getEncoded() method would use the iv value for
the encoding. While in the decoding method init(byte[]) method, the IV sizes
other block_size is not considered, and IOE will be thrown. Could this be a
problem?
-
PR: https://git.openjdk.java.net/jdk/pull/2404
Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
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 —- as well as various security challenges, but none of them can be tackled with the vigour they deserve when the resources of the security team are invested in maintaining a very costly mechanism that was not only designed for a different threat environment, but, more importantly, isn’t deployed by the vast majority of Java users, even those that care deeply about security. All JEPs are usually submitted toward the *end* of a long deliberation process, and are intended to gather information that might have been overlooked, so the nothing could be further from the truth that this is done “without hesitation”. Indeed, no such new information has come to light yet. We believe that the principle of least privilege would be better served without the Security Manager, and that security overall be improved with mechanisms that people actually use, some are already in place but will continue to improve with more resources available, which include, but certainly aren’t limited to, strong encapsulation which was turned on in JDK 16, remote JFR streaming also added in that version, access control which will be separated from the Security Manager, and OS-level sandboxes. When taken over the entire ecosystem, it is our informed opinion that the number of attacks actually stopped by the Security Manager over the past decade does not justify effort it costs, while other mechanisms do. It doesn’t even serve as a deterrent to attacks, because attackers know that it is rarely installed. Therefore, to improve security we must shift resources from efforts that, however intrinsically effective, don’t have the intended and much needed impact in the security of the Java ecosystem to those that do and will. - Ron > On 22 May 2021, at 11:58, Bernd Eckenfels wrote: > > 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 tried to > find maintainers? > > 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. (Or Have you ever tried to set FSP on a > Transformer?), limit deserialisation, restrict url handlers, impersonate > Users (local and remote filesystem), run chroot child’s or pass credentials > over named pipes. All mechanisms which are easier to do in other programming > environments. There is a big hesitation to even offer those platform specific > features. > > I do hope the result of this discussion really is a set of new replacement > technologies which allow to use least priveledge methods from the operating > environments (be able to run as a different User token, drop permissions, use > chroot/jail, fsuid, capsetp,setgroups and other impersonation methods) as > thread scopes. Also facilities for multi-process solutions (named pipe > servers, shared memory) might help with doing proper low priveledged > architectures in the future (in addition to stuffing everything into rootless > containers) > > But more importantly we do need to get a handle on Defense in depth for > libraries. LFI and Remote connections is a big part of that, but not limited > to it. > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > Von: security-dev im Auftrag von Peter > Tribble > Gesendet: Saturday, May 22, 2021 11:11:43 AM > An: Ron Pressler > Cc: Peter Firmstone ; David Black > ; Alan Bateman ; > security-dev@openjdk.java.net > Betreff: Re: [External] : Re: JEP411: Missing use-case: Monitoring / > restricting libraries > > 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 the maintainers of other platforms who have decided to > either not try to offer security > through the deep stack-dependent sandbox model or did but have since also > removed it. Their view is backed > by security experts, both those working on OpenJDK and outside it. > > I understand that maintaining the Security Manager is a burden. I understand > the argument that not > having the Security Manager would allow resources to be better deployed > elsewhere. Yet here we're > only seeing the one side. It would be good to be
Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
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 tried to find maintainers? 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. (Or Have you ever tried to set FSP on a Transformer?), limit deserialisation, restrict url handlers, impersonate Users (local and remote filesystem), run chroot child’s or pass credentials over named pipes. All mechanisms which are easier to do in other programming environments. There is a big hesitation to even offer those platform specific features. I do hope the result of this discussion really is a set of new replacement technologies which allow to use least priveledge methods from the operating environments (be able to run as a different User token, drop permissions, use chroot/jail, fsuid, capsetp,setgroups and other impersonation methods) as thread scopes. Also facilities for multi-process solutions (named pipe servers, shared memory) might help with doing proper low priveledged architectures in the future (in addition to stuffing everything into rootless containers) But more importantly we do need to get a handle on Defense in depth for libraries. LFI and Remote connections is a big part of that, but not limited to it. Gruss Bernd -- http://bernd.eckenfels.net Von: security-dev im Auftrag von Peter Tribble Gesendet: Saturday, May 22, 2021 11:11:43 AM An: Ron Pressler Cc: Peter Firmstone ; David Black ; Alan Bateman ; security-dev@openjdk.java.net Betreff: Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries On Sat, May 22, 2021 at 2:12 AM Ron Pressler mailto:ron.press...@oracle.com>> 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 the maintainers of other platforms who have decided to either not try to offer security through the deep stack-dependent sandbox model or did but have since also removed it. Their view is backed by security experts, both those working on OpenJDK and outside it. I understand that maintaining the Security Manager is a burden. I understand the argument that not having the Security Manager would allow resources to be better deployed elsewhere. Yet here we're only seeing the one side. It would be good to be able to see the ways in which Java's security would be improved by this JEP, because at the moment we're having to take that on trust. While I seriously hope you don’t actually believe a decision was made before publication, it is also obviously true that this wouldn’t have been proposed in the first place without *a lot* of thought, study and discussion. The proposal was made only after it was clear this was a very, *very* strong case, and that the chances of finding fault with it are low. It wasn’t put up after someone just had an idea. It is, therefore, not entirely surprising that no one has been able to give any relevant arguments against it. Clearly, you have had far less time to think about it, but I can’t seem to steer your arguments in a direction that’s relevant to what is actually the issue. I understand you’re invested in the Security Manager and that its removal would impose real costs on you. I am even willing to believe that you actually believe that, despite what studies show, despite what experts say, despite what the developers of Java say, despite what the developers of *all* other mainstream software platforms with an emphasis on security, both new and old —- from .NET to WebAssembly —- have concluded after decades of experience, that the Security Manager is not only the best way to secure Java but apparently the only one. Maybe you’re right and those others are wrong, but please accept that we all want to improve Java’s security, we just disagree with you on the best way to do it. Yes, additional security measures, whatever they are, would provide additional security. But if the choice is between measure A and measure B -— you *can’t* have both —- you pick the one that is *more* effective per cost. And yet the proposal in front of us is to remove measure A, which *will* reduce security for those using it. Where's the proposal for measure B, so we can evaluate whether the tradeoff between A and B is beneficial? None of your arguments so much as glance in that direction, and they don’t acknowledge the fact that Java security would be hardly affected by the Security Manager’s removal
Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
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 the maintainers of other platforms who have decided to > either not try to offer security > through the deep stack-dependent sandbox model or did but have since also > removed it. Their view is backed > by security experts, both those working on OpenJDK and outside it. > I understand that maintaining the Security Manager is a burden. I understand the argument that not having the Security Manager would allow resources to be better deployed elsewhere. Yet here we're only seeing the one side. It would be good to be able to see the ways in which Java's security would be improved by this JEP, because at the moment we're having to take that on trust. > While I seriously hope you don’t actually believe a decision was made > before publication, it is also obviously > true that this wouldn’t have been proposed in the first place without *a > lot* of thought, study and discussion. > The proposal was made only after it was clear this was a very, *very* > strong case, and that the chances of finding > fault with it are low. It wasn’t put up after someone just had an idea. It > is, therefore, not entirely > surprising that no one has been able to give any relevant arguments > against it. Clearly, you have had far less > time to think about it, but I can’t seem to steer your arguments in a > direction that’s relevant to what is actually > the issue. > > I understand you’re invested in the Security Manager and that its removal > would impose real costs on you. I am even > willing to believe that you actually believe that, despite what studies > show, despite what experts say, despite > what the developers of Java say, despite what the developers of *all* > other mainstream software platforms with > an emphasis on security, both new and old —- from .NET to WebAssembly —- > have concluded after decades of experience, > that the Security Manager is not only the best way to secure Java but > apparently the only one. Maybe you’re right > and those others are wrong, but please accept that we all want to improve > Java’s security, we just disagree with you > on the best way to do it. > > Yes, additional security measures, whatever they are, would provide > additional security. But if the choice is > between measure A and measure B -— you *can’t* have both —- you pick the > one that is *more* effective per cost. > And yet the proposal in front of us is to remove measure A, which *will* reduce security for those using it. Where's the proposal for measure B, so we can evaluate whether the tradeoff between A and B is beneficial? > None of your arguments so much as glance in that direction, and they don’t > acknowledge the fact that Java security > would be hardly affected by the Security Manager’s removal even without > better protection elsewhere for the simple > reason that it is hardly ever installed, including on the most > security-critical applications, whose defences > apparently aren’t so feeble even today. In any event, if the question is, > do we want a perimeter fence and security > cameras *XOR* locks on all room doors, the argument that they provide > security through different mechanisms so we > should have both completely misunderstands the question. I am also > confused by your point about multi-user > applications. Of course different users have different access, but surely > you are aware that very few applications > do that using the Security Manager, which isn’t needed —- and is rarely > used -— for that purpose. > > Short of making relevant arguments, I would urge you again to focus on > suggestions to reduce the harm this proposal > would cause you. > > — Ron > > > > > On 22 May 2021, at 00:17, Peter Firmstone > wrote: > > > > I had hoped by end of this discussion, that there would at least be an > understanding of what OpenJDK is so hastily choosing to destroy. > > > > Once it is gone, it will be irretrievable, it will never be possible to > lock down the JVM so securely again. > > > > > > On 21/05/2021 11:06 pm, Ron Pressler wrote: > >> > >>> On 21 May 2021, at 12:52, Peter Firmstone > wrote: > >>> > >>> It's quite clear this will be pushed through anyway, > >>> > >> No, not *anyway*, but given the fact that the community consists of > millions of users, this > >> proposal has been well-publicised, > > > > > > I discovered the proposal on the 11th of the May on a mailing list I was > subscribed to and I almost missed it. Yes, it will be pushed through > regardless, clearly the decision was made before publication. Everyone > saw applets coming, if the developers were serious about supporting > applets, they would have designed a stripped down subset of Java, a JVM > specifically suited that task which,
Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]
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 guaranteeing to do this straight after > integration. > It sounds like it is up for deferral if time runs out. > > The amount of follow-on work that I am hearing about here, and may be for > tests, does not make it sound > like this JEP is nearly as done as first presented. > > If there was some expectation that groups responsible for an area would get > involved with this > issue which I am assured was already known about, then why was it not raised > before and made > part of the plan ? Sprinkling SuppressWarnings should be very low risk. Refactoring code to have the scope of the SW be as small as possible may be a bit more risky, esp. in areas where one doesn't know the code or the tests that exercise it. The tests may be good but it's not clear to me that we want to force Max to do significant refactoring in this PR. PR 4138 has been created as the follow-on PR so I think we should help get that reviewed so that it can be integrated soon after this PR. - PR: https://git.openjdk.java.net/jdk/pull/4073
