Re: RFR: 8279903: Redundant modulo operation in ECDHKeyAgreement [v2]
> In class `sun.security.ec.ECDHKeyAgreement.java`, the last `mod()` in the > below line looks redundant, > > BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p); John Jiang has updated the pull request incrementally with one additional commit since the last revision: update copyright notes - Changes: - all: https://git.openjdk.java.net/jdk/pull/7042/files - new: https://git.openjdk.java.net/jdk/pull/7042/files/4b44997f..6504ac3d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7042=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7042=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7042.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7042/head:pull/7042 PR: https://git.openjdk.java.net/jdk/pull/7042
RFR: 8279903: Redundant modulo operation in ECDHKeyAgreement
In class `sun.security.ec.ECDHKeyAgreement.java`, the last `mod()` in the below line looks redundant, BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p); - Commit messages: - 8279903: Redundant modulo operation in ECDHKeyAgreement Changes: https://git.openjdk.java.net/jdk/pull/7042/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7042=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279903 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7042.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7042/head:pull/7042 PR: https://git.openjdk.java.net/jdk/pull/7042
Re: RFR: 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
On Tue, 11 Jan 2022 20:38:30 GMT, Weijun Wang wrote:
> Change the order so parent class is at the left.
Hm, an interesting catch. I have a concern, although.
src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java
line 111:
> 109: T getParameterSpec(Class
> paramSpec)
> 110: throws InvalidParameterSpecException {
> 111: if (paramSpec.isAssignableFrom(IvParameterSpec.class)) {
The call to cast() is confusing. But if the paramSpec is
AlgorithmParameterSpec.class or Object.class, what's the expected behavior?
There are potential casting exception, I guess. Maybe, a exactly class
matching could be better.
-
Changes requested by xuelei (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7037
Re: RFR: 8279801: EC KeyFactory and KeyPairGenerator do not have aliases for OID format
On Tue, 11 Jan 2022 20:34:59 GMT, Weijun Wang wrote: > Add OID aliases for the 2 service. This makes sure KeyFactory can be created > and read an encoded key without knowing what the OID in the encoding is for. It is not obvious about the description "Add OID aliases for the 2 service", but I think I got the idea. Looks good to me. - Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7036
RFR: 8273236: keytool does not accurately warn about algorithms that are disabled but have additional constraints
`keytool` currently uses a simpler scheme in `DisabledAlgorithmConstraints` class when performing algorithm constraints checks. This change is to enhance `keytool` to make use of the new methods `DisabledAlgorithmConstraints.permits` with `CertPathConstraintsParameters` and `checkKey` parameters. For the keyusage in the EE certificate of a certificate chains, set the variant accordingly when calling `CertPathConstraintsParameters` constructor. - Commit messages: - 8273236: keytool does not accurately warn about algorithms that are disabled but have additional constraints Changes: https://git.openjdk.java.net/jdk/pull/7039/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7039=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273236 Stats: 399 lines in 3 files changed: 346 ins; 0 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/7039.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7039/head:pull/7039 PR: https://git.openjdk.java.net/jdk/pull/7039
Re: JEP 411: sandboxing use case
On 1/10/22 9:22 AM, Olivier Cailloux wrote: Dear list, I would like to share my use case for currently using the security manager mechanism (SM) in my software. Now that JEP 411 is there, any advice about any currently existing solution for replacement would be welcome, if this is already possible; alternatively, I hope that a replacement for these needs will be available soon. You may want to consider container technologies. This is mentioned in the last paragraph of the Motivation section of JEP 411. --Sean My software grades student work. It download their code from GitHub, compiles it, runs it, and observe the results (similar to running JUnit tests, but on pluggable code). Their code is then graded automatically depending on the expected versus actual results. I currently use SM to prevent student code to alter the system on which the code runs or have external impact. I don’t want them to read files or send network requests (they usually do not need to do anything like this for the exercices assigned to them). I currently use a simple “no priviledged calls at all” configuration, where everything that can be forbidden by SM is forbidden for their code, as they only need to be able to deal with their own objects and classes from the JDK that operate “taint-free” (as Chapman Flak puts it), such as classical List or Set structures. Though I do not currently need such more advanced feature, I considered as a good bonus that SM allowed me, if I wanted to, to give exercices that also deal with file writing (through telling SM that their code can access a restricted set of files). If any replacement solution could also allow this kind of flexibility, that would be nice. I am aware that their code could implement a denial of service; I am okay to live with this risk as any resulting damage would be low (worst case, just restart the computer). But I’d like to reduce the risk that their code would read or modify files or other aspects of the system it is running on, for example, as the resulting damage could be much higher (such as: alter the way the system works so that the grading of other students, graded next, would be modified; read personal files from the account that is running the grading software and posting their content on the internet; inadvertently delete files on the host system…) I implement code isolation so that one student code does not see or interact with the code of other students classical using class loader mechanisms, for which JEP 411 does not create problems. But I ignore how to prevent file writing, socket opening, or similar stuff, using other means than SM. My needs resemble (but are not identical to) the ones exposed by Chapman Flack in “JEP 411: Missing use-case: user functions in an RDBMS”, https://marc.info/?m=162216583127042. I share the concern of this poster (https://marc.info/?m=162221303911911) that it currently seems that I’d have to come up with various, specialized mechanisms to prevent various kinds of operations (file system access, socket access, …), which seems inelegant and error-prone. Even after reading the insightful article of Ron Pressler, Shallow Java Sandboxes (https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/), it is unclear to me whether I can get rid of SecurityManager with existing Java 17 technology. Any advice would be welcome. If not possible, please consider this use case when thinking about further progress in replacing the security related APIs. (I am quite worried by the wording of JEP 411 Future Work not mentioning this kind of sandboxing need.) Olivier
RFR: 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards
Change the order so parent class is at the left. - Commit messages: - 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards Changes: https://git.openjdk.java.net/jdk/pull/7037/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7037=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279800 Stats: 106 lines in 12 files changed: 84 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/7037.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7037/head:pull/7037 PR: https://git.openjdk.java.net/jdk/pull/7037
RFR: 8279801: EC KeyFactory and KeyPairGenerator do not have aliases for OID format
Add OID aliases for the 2 service. This makes sure KeyFactory can be created and read an encoded key without knowing what the OID in the encoding is for. - Commit messages: - 8279801: EC KeyFactory and KeyPairGenerator do not have aliases for OID format Changes: https://git.openjdk.java.net/jdk/pull/7036/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7036=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279801 Stats: 52 lines in 2 files changed: 45 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7036.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7036/head:pull/7036 PR: https://git.openjdk.java.net/jdk/pull/7036
