On 25/04/2022 10:53 pm, David Lloyd wrote:
Nothing in the proposal is intended to solve the issue of tainted
data; with or without this proposal, this is an unsolved problem.
Well, actually, the statement "this is an unsolved problem" is not entirely
true, I think we came very close to solvin
On 25/04/2022 13:53, David Lloyd wrote:
Nothing in the proposal causes splitting or delegation of
responsibilities. It is _only_ about preserving security checkpoints
in the JDK, which *add* a layer of checks to what the container might
already provide. Nothing is being subtracted, and thus I fin
On 26/04/2022 6:28 pm, Alan Bateman wrote:
On 25/04/2022 13:53, David Lloyd wrote:
Nothing in the proposal causes splitting or delegation of
responsibilities. It is _only_ about preserving security checkpoints
in the JDK, which *add* a layer of checks to what the container might
already provid
Hello,
I dont agree with the statement that this can be solved on higher level.
(Unless higher level means move away from existing architectures which is
perfectly fine for some workloads but not for all)
IMHO Infrastructure to enforce on lower level is needed either for traditional
sandboxing
On 26/04/2022 10:06, Peter Firmstone wrote:
:
What about ensuring that all network access occurs through a single
location that we can instrument?
Network, file, and process launch are potentially interesting but
instrumenting them to run arbitrary code may be problematic (for the
same reas
Just to add to the discussion some more, as I understand it the new (Graal
based?) multi language environment running inside a Oracle database is exactly
what others want to do here: multimtenant untrusted code execution inside a
bigger application.
There are a number of complications here, fir
On 26/04/2022 8:10 pm, Alan Bateman wrote:
On 26/04/2022 10:06, Peter Firmstone wrote:
:
What about ensuring that all network access occurs through a single
location that we can instrument?
Network, file, and process launch are potentially interesting but
instrumenting them to run arbitrary
On Tue, 26 Apr 2022 05:02:51 GMT, Xue-Lei Andrew Fan wrote:
>> src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java
>> line 54:
>>
>>> 52: private final Cleaner.Cleanable cleanable;
>>> 53:
>>> 54: long pName = 0; // Pointer to the gss_name_t structure
>>
On Tue, 26 Apr 2022 05:05:30 GMT, Xue-Lei Andrew Fan wrote:
>> The same for `GSSName`. Where is a test for `GSSCredential`?
>
>> Where is a test for `GSSCredential`?
>
> I did not find a way to create a GSSCredential object successfully, exception
> thrown. Is there an example I can refer to?
On Tue, Apr 26, 2022 at 4:47 AM Alan Bateman wrote:
>
> On 25/04/2022 13:53, David Lloyd wrote:
> > Nothing in the proposal causes splitting or delegation of
> > responsibilities. It is _only_ about preserving security checkpoints
> > in the JDK, which *add* a layer of checks to what the container
On Mon, Apr 25, 2022 at 2:55 PM David Lloyd wrote:
> Nothing in the proposal causes splitting or delegation of
> responsibilities. It is _only_ about preserving security checkpoints
> in the JDK, which *add* a layer of checks to what the container might
> already provide. Nothing is being subtrac
On Tue, Apr 26, 2022 at 8:17 AM Mario Torre wrote:
> I think there's a difference between "perceived" security and "actual" one.
>
> The SM in today's post Spectre, Meltdown and the likes world is
> "perceived" security, which may lead to a relaxation on the security
> of other layers because at l
On Tue, 26 Apr 2022 11:54:36 GMT, Weijun Wang wrote:
>> Did you mean pName? The dispose() method will reset it to zero. 'pName" is
>> used a lot in native implementation. It may be doable to make it final, but
>> it may be more complicated than I could expect. I would like to leave it as
>>
I will have a look at it. I may need help for more information.
On Apr 25, 2022, at 7:45 AM, Flavia Rainone
mailto:[email protected]>> wrote:
Hi everyone,
I work with the XNIO ( https://github.com/xnio/xnio/ ) project, led by David
Lloyd in CC.
I'm not sure if this is the best way to get
Is it the same problem as discussed in this thread:
https://mail.openjdk.java.net/pipermail/security-dev/2022-April/030129.html
Xuelei
On Apr 26, 2022, at 7:36 AM, Thomas Lußnig
mailto:[email protected]>> wrote:
Hi,
i changed the logging and now better get the Location of the error
javax.cry
On Tue, 26 Apr 2022 02:59:48 GMT, Valerie Peng wrote:
> This is to update the method javadoc of
> java.security.Signature.getParameters() with the missing `@throws
> UnsupportedOperationException`. In addition, the wording on the returned
> parameters are updated to match those in Cipher and C
On Tue, 26 Apr 2022 04:27:37 GMT, Xue-Lei Andrew Fan wrote:
>> test/jdk/javax/security/auth/callback/PasswordCleanup.java line 74:
>>
>>> 72: }
>>> 73:
>>> 74: private static void checkClearing() throws Exception {
>>
>> How is this test testing that the password is cleared?
>
> The te
On Mon, 25 Apr 2022 06:07:00 GMT, Xue-Lei Andrew Fan wrote:
>> Please review the update to remove finalizer method in the
>> java.security.jgss module. It is one of the efforts to clean up the use of
>> finalizer method in JDK.
>
> Xue-Lei Andrew Fan has updated the pull request with a new targ
On Tue, 26 Apr 2022 13:38:04 GMT, Xue-Lei Andrew Fan wrote:
>> IMO, there's no need to reset it to zero in `dispose()`. As for the usage in
>> native implementation, if there is really a case that it gets updated, then
>> the cleanable you registered at the beginning will be useless. Isn't that
On Tue, 26 Apr 2022 15:19:30 GMT, Sean Mullan wrote:
>> The test case is used to check that the Cleaner used is not bind to 'this'
>> object, and the cleaner during finalization could work. Unfortunately, as
>> the cleaner behavior is not visible, I don't find a way to automated test
>> that
> Compare encoded instead of decoded digest in RSA signature verification.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
only check digest value
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8365/files
- n
> Please review this password cleanup enhancement in the PasswordCallback
> implementation. This is one of the effort to clean up the buffered passwords.
>
> The PasswordCallback.setPassword() clones the password, but is not registered
> for cleanup. An application could call clearPassword() fo
On Tue, 26 Apr 2022 15:45:47 GMT, Xue-Lei Andrew Fan wrote:
>> Ok, then I would suggest changing the name of the test as it is misleading.
>> I suggest creating a directory named "PasswordCallback" and then adding a
>> test named perhaps "CheckCleanerNotBoundToThis" or something like that. I
>
Hello Scott,
On 4/25/22 2:25 PM, Scott Stark wrote:
Hello,
I'm Scott Stark of Red Hat, and a member of the Jakarta EE platform dev
group (EEPD). I'm currently coordinating the Jakarta EE 10 release that
is targeting June of this year (2022). The removal of the
SecurityManager as described in
With this update, is the purpose of this PR changed? The bug subject and
description may need an update.
Xuelei
> On Apr 26, 2022, at 9:02 AM, Weijun Wang wrote:
>
>> Compare encoded instead of decoded digest in RSA signature verification.
>
> Weijun Wang has updated the pull request increme
On Tue, 26 Apr 2022 16:02:41 GMT, Weijun Wang wrote:
>> Compare encoded instead of decoded digest in RSA signature verification.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> only check digest value
> _Mailing list messag
On Sun, 24 Apr 2022 14:34:46 GMT, Weijun Wang wrote:
> Regardless whether we ended up with decode/encode, we should make sure
> RSASSA-PSS signature impl is also covered and consistent.
Never mind, PSS has its own way of verification and its impl is based on RFC
8017.
-
PR: https
On Tue, 26 Apr 2022 14:51:31 GMT, Weijun Wang wrote:
>> This is to update the method javadoc of
>> java.security.Signature.getParameters() with the missing `@throws
>> UnsupportedOperationException`. In addition, the wording on the returned
>> parameters are updated to match those in Cipher an
On 4/26/22 1:06 PM, Scott Stark wrote:
By "migration feature" I'm talking about being able to retain the type
of library code where one has a conditional call to an
AccessController::doPrivileged(...) method that is only done when
System.getSecurityManager() is not null. Not having to remove
On Mon, 25 Apr 2022 06:07:00 GMT, Xue-Lei Andrew Fan wrote:
>> Please review the update to remove finalizer method in the
>> java.security.jgss module. It is one of the efforts to clean up the use of
>> finalizer method in JDK.
>
> Xue-Lei Andrew Fan has updated the pull request with a new targ
> This is to update the method javadoc of
> java.security.Signature.getParameters() with the missing `@throws
> UnsupportedOperationException`. In addition, the wording on the returned
> parameters are updated to match those in Cipher and CipherSpi classes.
>
> CSR will be filed later.
>
> Th
On Tue, 26 Apr 2022 16:02:41 GMT, Weijun Wang wrote:
>> Compare encoded instead of decoded digest in RSA signature verification.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> only check digest value
Marked as reviewed by
By "migration feature" I'm talking about being able to retain the type of
library code where one has a conditional call to an
AccessController::doPrivileged(...) method that is only done when
System.getSecurityManager() is not null. Not having to remove this code in
all dependent libraries for a g
On Mon, 25 Apr 2022 18:14:07 GMT, Sean Mullan wrote:
>> As for the 2nd sentence, it boils down whether we requires provider to
>> generate default parameters and return it when parameter is required.
>> Existing javadoc states that null is returned when parameter is not
>> required. Given Ciph
On Tue, 26 Apr 2022 04:37:58 GMT, Jaikiran Pai wrote:
>> Mark Powers has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Alan Bateman comments
>
> src/java.base/share/classes/javax/net/ssl/KeyStoreBuilderParameters.java line
> 71:
>
>> 69:
On Tue, 26 Apr 2022 00:27:43 GMT, Mark Powers wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8285504
>>
>> JDK-8273046 is the umbrella bug for this bug. The changes were too large for
>> a single code review, so it was decided to split into smaller chunks. This
>> is one such chunk:
>>
>
On Tue, 26 Apr 2022 00:27:43 GMT, Mark Powers wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8285504
>>
>> JDK-8273046 is the umbrella bug for this bug. The changes were too large for
>> a single code review, so it was decided to split into smaller chunks. This
>> is one such chunk:
>>
>
> https://bugs.openjdk.java.net/browse/JDK-8285504
>
> JDK-8273046 is the umbrella bug for this bug. The changes were too large for
> a single code review, so it was decided to split into smaller chunks. This is
> one such chunk:
>
> open/src/java.base/share/classes/java/net
Mark Powers has u
On Tue, 26 Apr 2022 00:27:43 GMT, Mark Powers wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8285504
>>
>> JDK-8273046 is the umbrella bug for this bug. The changes were too large for
>> a single code review, so it was decided to split into smaller chunks. This
>> is one such chunk:
>>
>
On Tue, 26 Apr 2022 18:28:03 GMT, Valerie Peng wrote:
>>> I can do the Signature update through
>>> https://bugs.openjdk.java.net/browse/JDK-8253176 which I have targeted to
>>> fix in 19 also.
>>
>> Ok.
>
> I have filed the PR for the Signature at:
> https://github.com/openjdk/jdk/pull/8396
On Tue, 26 Apr 2022 18:39:33 GMT, Bradford Wetmore wrote:
>> Mark Powers has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Alan Bateman comments
>
> src/java.base/share/classes/javax/net/ssl/KeyStoreBuilderParameters.java line
> 72:
>
>>
On Tue, 26 Apr 2022 19:05:05 GMT, Weijun Wang wrote:
>> Mark Powers has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Alan Bateman comments
>
> src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java line 69:
>
>> 67: Str
On Thu, 21 Apr 2022 17:32:32 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on modules owned by the security team (`java.security.jgss
>> java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki
>> jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth jdk.security.jgss`), and
>
On Mon, 18 Apr 2022 13:26:30 GMT, Sibabrata Sahoo wrote:
>> A Test updated to cover the getCodeSigners.
>
> Sibabrata Sahoo has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Update Implies.java
Marked as reviewed by mullan (Reviewer).
-
On Mon, 18 Apr 2022 13:35:25 GMT, Sean Mullan wrote:
> This change improves the specification for the case when a
> `PKIXRevocationChecker` is supplied as one of the `CertPathChecker`
> parameters. Specifically, it makes it more clear that a
> `PKIXRevocationChecker` overrides the default revo
On Thu, 21 Apr 2022 17:32:32 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on modules owned by the security team (`java.security.jgss
>> java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki
>> jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth jdk.security.jgss`), and
>
On Tue, 26 Apr 2022 19:49:11 GMT, Bradford Wetmore wrote:
>> src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java line 69:
>>
>>> 67: String type;
>>> 68: type = AccessController.doPrivileged((PrivilegedAction)
>>> () ->
>>> 69: Security.getProperty("ssl.
On Fri, 22 Apr 2022 17:10:58 GMT, Weijun Wang wrote:
> Compare encoded instead of decoded digest in RSA signature verification.
This pull request has now been integrated.
Changeset: 14e7d911
Author:Weijun Wang
URL:
https://git.openjdk.java.net/jdk/commit/14e7d911997d33eba2893991fa0e
Security mailing list
Only numbers from the same modular fields can be involved in arithmetic
calculations. Add `assert` to guarantee this.
Also, found one broken case and rewrote it.
-
Commit messages:
- ECC calculation error fix
Changes: https://git.openjdk.java.net/jdk/pull/8409/files
Webrev: https
On Thu, 10 Mar 2022 08:52:17 GMT, Сергей Цыпанов wrote:
>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with
>> smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when
>> called with vararg of size 0, 1, 2.
>>
>> In general replacement of `Arrays.asList(
Hi all,
Recently we (at JetBrains) were faced with the vulnerability issue
CVE-2018-25032 (zlib before 1.2.12 allows memory corruption…)
It is known that Linux, macOS builds uses system’s zlib but Windows - bundled
one (by default).
On Linux and macOS users can work around the issue by installin
Hi -
FYI - This is currently getting some play time on the Crypto Forum
Research Group (related to the IETF):
https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/ The
thread starts here:
https://mailarchive.ietf.org/arch/msg/cfrg/wlIuVws-pmccvbGbBrIBVBhN2GQ/
It's probably covered
Well said, we're not trying to sandbox untrusted code. We're simply
trying to provide authorization controls on authenticated users and in
my particular case, service proxy's. It's well known the JVM can't
handle untrusted code, nor does it have well designed defenses against
parsing untrust
On Tue, 26 Apr 2022 20:40:50 GMT, Bradford Wetmore wrote:
>> Wasn't there another bug to address this?
>
> Perhaps as part of
> [JDK-6725221](https://bugs.openjdk.java.net/browse/JDK-6725221)?
No problem.
-
PR: https://git.openjdk.java.net/jdk/pull/8384
To enable more complete doclint checking (courtesy @jonathan-gibbons), please
review this PR to add type-level @param tags where they are missing.
To the maintainers of java.util.concurrent, those changes could be separated
out in another bug if that would ease maintenance of that code.
Making
Hello Michael,
thanks for the pointer, interesting read.
I think the key takeaway from that discussion is, that the Wycheproof Testcases
would have catched this problem and should probably be added to the OpenJDK
tests. (I wonder, does Google not run those in qualification builds?)
The disc
Two new constant fields `MGF1ParameterSpec.SHA512_224` and
`MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of
[JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293).
This bug addresses this issue.
-
Commit messages:
- 8285683: Missing @ since 11
On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote:
> To enable more complete doclint checking (courtesy @jonathan-gibbons), please
> review this PR to add type-level @param tags where they are missing.
>
> To the maintainers of java.util.concurrent, those changes could be separated
> out in an
On 4/20/2022 5:06 PM, Vitaly Provodin wrote:
Recently we (at JetBrains) were faced with the vulnerability issue
CVE-2018-25032 (zlib before 1.2.12 allows memory corruption…)
It is known that Linux, macOS builds uses system’s zlib but Windows - bundled
one (by default).
On Linux and macOS us
On Tue, 26 Apr 2022 22:55:29 GMT, Bradford Wetmore wrote:
> Two new constant fields `MGF1ParameterSpec.SHA512_224` and
> `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of
> [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293).
>
> This bug addresses this i
Hello Vitaly,
(Personal answer not affiliated with OpenJDK members)
I had also asked about this before, but there was no answer (which is however
not surprising, since it is the policy of OpenJDK and Oracle to not comment on
unfixed security issues).
My hope was, that by reporting it before th
On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote:
> To enable more complete doclint checking (courtesy @jonathan-gibbons), please
> review this PR to add type-level @param tags where they are missing.
>
> To the maintainers of java.util.concurrent, those changes could be separated
> out in an
On Tue, 26 Apr 2022 22:55:29 GMT, Bradford Wetmore wrote:
> Two new constant fields `MGF1ParameterSpec.SHA512_224` and
> `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of
> [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293).
>
> This bug addresses this i
On Tue, 26 Apr 2022 22:55:29 GMT, Bradford Wetmore wrote:
> Two new constant fields `MGF1ParameterSpec.SHA512_224` and
> `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of
> [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293).
>
> This bug addresses this i
On Wed, 27 Apr 2022 00:12:32 GMT, Valerie Peng wrote:
> Is a CSR needed?
@valeriepeng I would be surprised. I don't think so, but checking with CSR.
-
PR: https://git.openjdk.java.net/jdk/pull/8411
On Tue, 26 Apr 2022 14:59:35 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Undo un-intentional changes.
>
> src/java.base/share/classes/java/security/Signature.java line 1015:
>
>> 1013: *
On Tue, 12 Apr 2022 19:03:40 GMT, Mat Carter wrote:
> On Windows you can now access the local machine keystores using the strings
> "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the
> application requires admin privileges.
>
> "Windows-MY" and "Windows-ROOT" remain unchanged,
On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote:
> To enable more complete doclint checking (courtesy @jonathan-gibbons), please
> review this PR to add type-level @param tags where they are missing.
>
> To the maintainers of java.util.concurrent, those changes could be separated
> out in an
On Tue, 26 Apr 2022 22:55:29 GMT, Bradford Wetmore wrote:
> Two new constant fields `MGF1ParameterSpec.SHA512_224` and
> `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of
> [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293).
>
> This bug addresses this i
On Tue, 12 Apr 2022 19:03:40 GMT, Mat Carter wrote:
> On Windows you can now access the local machine keystores using the strings
> "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the
> application requires admin privileges.
>
> "Windows-MY" and "Windows-ROOT" remain unchanged,
On Tue, 12 Apr 2022 19:03:40 GMT, Mat Carter wrote:
> On Windows you can now access the local machine keystores using the strings
> "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the
> application requires admin privileges.
>
> "Windows-MY" and "Windows-ROOT" remain unchanged,
On Wed, 27 Apr 2022 02:21:07 GMT, Bernd wrote:
>> On Windows you can now access the local machine keystores using the strings
>> "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the
>> application requires admin privileges.
>>
>> "Windows-MY" and "Windows-ROOT" remain unchanged,
On Tue, 26 Apr 2022 17:51:45 GMT, Valerie Peng wrote:
>> This is to update the method javadoc of
>> java.security.Signature.getParameters() with the missing `@throws
>> UnsupportedOperationException`. In addition, the wording on the returned
>> parameters are updated to match those in Cipher a
On Tue, 26 Apr 2022 21:02:49 GMT, Weijun Wang wrote:
> Only numbers from the same modular fields can be involved in arithmetic
> calculations. Add `assert` to guarantee this.
>
> Also, found one broken case and rewrote it.
src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSAOperations.java li
On Mon, 18 Apr 2022 13:35:25 GMT, Sean Mullan wrote:
> This change improves the specification for the case when a
> `PKIXRevocationChecker` is supplied as one of the `CertPathChecker`
> parameters. Specifically, it makes it more clear that a
> `PKIXRevocationChecker` overrides the default revo
On Thu, 7 Apr 2022 20:17:28 GMT, Xue-Lei Andrew Fan wrote:
>> Please review the update to remove finalizer method in the SunJSSE provider
>> implementation. It is one of the efforts to clean up the use of finalizer
>> method in JDK.
>
> Xue-Lei Andrew Fan has updated the pull request increment
77 matches
Mail list logo
