On 03/06/2021 01:04, Chapman Flack wrote:
On 06/02/21 19:41, Peter Firmstone wrote:
We need the power of AccessController's stack walk, StackWalker doesn't work
with compiled code, only bytecode.
Is this correct? I have not tried it, but the apidocs had led me to
understand it did not distin
Apologies, I meant when compiled to native code, when you ship native
binaries.
Having said that, if it's necessary to use StackWalker behind
AccessController.doPrivileged going forward then lets do so, and maybe
the native binary is a later feature.
Hopefully my proposal is getting some con
On Wed, 2 Jun 2021 23:15:46 GMT, Bradford Wetmore wrote:
>> The JceSecurityManager is currently a subclass of
>> java.security.SecurityManager. Now that JEP 411 has been integrated, this
>> class should be updated to no longer subclass SecurityManager.
>>
>> The only reason for using Security
On 03/06/2021 08:28, Peter Firmstone wrote:
Apologies, I meant when compiled to native code, when you ship native
binaries.
I'm not sure what you mean here. Are you talking about native binaries
as generated by the GraalVM Native Image Generator? If you are
suggesting there is a disparity in
> On 3 Jun 2021, at 00:41, Peter Firmstone wrote:
>
>
> StackWalker doesn't work with compiled code, only bytecode.
If you’re referring to GraalVM’s Native Image, I don’t know about that problem
and
there does seem to be a relevant patch
(https://github.com/oracle/graal/pull/734), but
Nati
Ok, thanks Ron,
I think we are confirming that Java, post version 17, will not meet the
security needs our software. It's time I accepted that and moved on.
Thanks for your time.
Have you seen my latest article on foojay? Feel free to comment and
let me know what you think.
https://fooj
It is certainly time to accept that JEP 411 has been accepted, and so that those
who use Security Manager will need to do some work to change their software.
The purpose of this and upcoming discussions is to find reasonable approaches
that might relieve some portion of the burden on those who use
Yes, I think so too. However I will encourage developers to continue to
take advantage of SM for improved security now, there's no need to rush
to abandon it.
Maybe in future there will be better alternatives, but it's the best
option for those who are security focused now.
With time no dou
MultipleLogins.java should skip test where NSS support is not present
-
Commit messages:
- 8268167: MultipleLogins.java failure on macosx-aarch64
Changes: https://git.openjdk.java.net/jdk/pull/4333/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4333&range=00
Issue: h
On Thu, 3 Jun 2021 11:10:10 GMT, Sean Coffey wrote:
> MultipleLogins.java should skip test where NSS support is not present
Marked as reviewed by weijun (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/4333
On Thu, 3 Jun 2021 11:10:10 GMT, Sean Coffey wrote:
> MultipleLogins.java should skip test where NSS support is not present
This pull request has now been integrated.
Changeset: eb385c0d
Author:Sean Coffey
URL:
https://git.openjdk.java.net/jdk/commit/eb385c0de2026d6b184ce0c98ff421a4
On Wed, 2 Jun 2021 23:15:46 GMT, Bradford Wetmore wrote:
>> The JceSecurityManager is currently a subclass of
>> java.security.SecurityManager. Now that JEP 411 has been integrated, this
>> class should be updated to no longer subclass SecurityManager.
>>
>> The only reason for using Security
On Wed, 2 Jun 2021 23:15:46 GMT, Bradford Wetmore wrote:
>> The JceSecurityManager is currently a subclass of
>> java.security.SecurityManager. Now that JEP 411 has been integrated, this
>> class should be updated to no longer subclass SecurityManager.
>>
>> The only reason for using Security
On 6/2/21 7:41 PM, Peter Firmstone wrote:
AccessController and AccessControlContext allow backward compatiblity
for JAAS. JAAS whether we like it or not, is the default authorisation
layer framework.
http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/
I'm not su
> Hi,
>
> I need a review of this rather large change to GCM. GCM will no longer use
> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
> also a major code redesign limits the amount of data copies and make some
> performance-based decisions.
>
> Thanks
>
> Tony
An
On Wed, 2 Jun 2021 14:03:57 GMT, Fernando Guallini
wrote:
> The test `SSLSocketImplThrowsWrongExceptions` is failing intermittently after
> the change: [JDK-8259662: Don't wrap SocketExceptions into SSLExceptions in
> SSLSocketImpl](https://bugs.openjdk.java.net/browse/JDK-8259662)
>
> Since
> This patch overhauls the library loading mechanism used by the Foreign Linker
> API. We realized that, while handy, the *default* lookup abstraction
> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>
> This patch replaces `LibraryLookup` with a simpler `SymbolLookup
> This patch overhauls the library loading mechanism used by the Foreign Linker
> API. We realized that, while handy, the *default* lookup abstraction
> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>
> This patch replaces `LibraryLookup` with a simpler `SymbolLookup
On Thu, 3 Jun 2021 14:20:37 GMT, Sean Mullan wrote:
>> Bradford Wetmore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains eight commits:
>>
>> - Address codereview comments
>> - Merge branch 'master' into JDK-8267485
>> - Merge b
On Thu, 3 Jun 2021 08:27:14 GMT, Daniel Fuchs wrote:
>> Bradford Wetmore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains eight commits:
>>
>> - Address codereview comments
>> - Merge branch 'master' into JDK-8267485
>> - Merge
On Thu, 3 Jun 2021 17:44:42 GMT, Bradford Wetmore wrote:
>> src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 50:
>>
>>> 48: * @since 1.4
>>> 49: */
>>> 50: @SuppressWarnings("removal")
>>
>> You should remove this annotation now that the dependency on SecurityManager
>>
On Thu, 3 Jun 2021 17:44:22 GMT, Bradford Wetmore wrote:
>> src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 111:
>>
>>> 109: Option.RETAIN_CLASS_REFERENCE)
>>> 110: .walk((s) ->
>>> s.collect(Collectors.toList
On Thu, 3 Jun 2021 16:43:51 GMT, Maurizio Cimadamore
wrote:
>> This patch overhauls the library loading mechanism used by the Foreign
>> Linker API. We realized that, while handy, the *default* lookup abstraction
>> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>>
On Thu, 3 Jun 2021 16:04:19 GMT, Anthony Scarpino wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and mak
On Thu, 3 Jun 2021 19:13:00 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - missed resultLen and undo decrypt heap hasarray check
>> - code review comments
>> - fix
>
> src/java.base/sha
> This patch overhauls the library loading mechanism used by the Foreign Linker
> API. We realized that, while handy, the *default* lookup abstraction
> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>
> This patch replaces `LibraryLookup` with a simpler `SymbolLookup
On Thu, 3 Jun 2021 17:58:45 GMT, Daniel Fuchs wrote:
>> Unfortunately, we are still calling AccessController, thus the annotation
>> needs to remain.
>
> But if you follow my suggestion you can simply apply it to this line:
>
>
> @SuppressWarnings("removal")
> final List stack =
> AccessContr
Hi Sean,
Developers are still going to need single points of control, where we
can attach our agents to Java's API's. We can't be playing a game of
whack a mole trying to lock down the JDK.
It's fair enough that OpenJDK no longer wishes to maintain
SecurityManager, however there are those
On Thu, 3 Jun 2021 20:49:27 GMT, Bradford Wetmore wrote:
>> But if you follow my suggestion you can simply apply it to this line:
>>
>>
>> @SuppressWarnings("removal")
>> final List stack =
>> AccessController.doPrivileged(pa).walk(Stream::toList);
>
> For the static initializer that needs upd
On Thu, 3 Jun 2021 21:41:02 GMT, Sean Mullan wrote:
>> For the static initializer that needs updating: I could move the code out
>> of the initializer up to the declaration, or I could create a dummy
>> declaration and then assign to INSTANCE.
>
> The latter is probably better so you don't hav
On Thu, 3 Jun 2021 21:50:32 GMT, Bradford Wetmore wrote:
>> The latter is probably better so you don't have to move the code; @wangweij
>> used this technique quite a bit for JEP 411 refactoring, see
>> https://github.com/openjdk/jdk/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b
>
> @seanjmul
On Wed, 2 Jun 2021 20:23:38 GMT, Anthony Scarpino wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 1610:
>>
>>> 1608: // update the input parameters for what was taken
>>> out of 'in'
>>> 1609: inOfs += inUsed;
Sean,
Also moving forward we currently preserve AccessControlContext across
threads, and we do this to establish TLS connections for call backs.
Will there be a new way to preserve the calling Subject across threads,
so we can perform callbacks over TLS?
Regards,
--
Regards,
Peter Firmst
On Thu, 3 Jun 2021 20:45:41 GMT, Anthony Scarpino wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 84:
>>
>>> 82: private static final int MAX_BUF_SIZE = Integer.MAX_VALUE;
>>> 83: // data size when buffer is divided up to aid in intrinsics
>>
On Thu, 3 Jun 2021 16:04:19 GMT, Anthony Scarpino wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and mak
> The JceSecurityManager is currently a subclass of
> java.security.SecurityManager. Now that JEP 411 has been integrated, this
> class should be updated to no longer subclass SecurityManager.
>
> The only reason for using SecurityManager to easily get the Class Context
> (call stack), but we
On Wed, 2 Jun 2021 03:18:49 GMT, Anthony Scarpino wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 942:
>>
>>> 940:
>>> 941: System.arraycopy(out, originalOutOfs, originalOut,
>>> originalOutOfs,
>>> 942: len);
>>
>> Don
On Thu, 3 Jun 2021 16:04:19 GMT, Anthony Scarpino wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and mak
On Thu, 3 Jun 2021 22:27:16 GMT, Bradford Wetmore wrote:
>> The JceSecurityManager is currently a subclass of
>> java.security.SecurityManager. Now that JEP 411 has been integrated, this
>> class should be updated to no longer subclass SecurityManager.
>>
>> The only reason for using Security
On Thu, 3 Jun 2021 22:07:34 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - missed resultLen and undo decrypt heap hasarray check
>> - code review comments
>> - fix
>
> src/java.base/sha
On Thu, 3 Jun 2021 22:30:38 GMT, Valerie Peng wrote:
>> A engine is a one time use, so setting originalOut to null isn't necessary.
>> engineDoFinal() sets engine = null.
>
> engine is one time use per encryption/decryption. But 'originalOut' is for
> overlap detection/protection which may be
Could someone please advise the recommended way now to preserve the
Subject in Executors to establish a TLS connection?
I am unable to find the documentation.
We use Executors and we preserve the calling Subject across them, to use
for authentication our TLS endpoints.
This is now deprecated
Don't bother replying.
I found that it is actually on the TODO list.
https://bugs.openjdk.java.net/browse/JDK-8266592
I've had enough now anyway, there is no fixing this mess.
Sayonara.
On 4/06/2021 2:22 pm, Peter Firmstone wrote:
Could someone please advise the recommended way now to preser
On 04/06/2021 05:22, Peter Firmstone wrote:
Could someone please advise the recommended way now to preserve the
Subject in Executors to establish a TLS connection?
I think the primitive you are looking for is scope local variables. It's
still in the exploration phase but there is a draft JEP
> Hi,
>
> I need a review of this rather large change to GCM. GCM will no longer use
> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
> also a major code redesign limits the amount of data copies and make some
> performance-based decisions.
>
> Thanks
>
> Tony
An
Hi Max,
thank you for fixing my bug. I have finally verified it to properly work
just as specified in the RFC with AdoptOpenJDK 16 on Windows.
Do you see any chance to have this small change to be backported to 8
and 11? If this is the wrong list should this go to jdk8u-dev@?
Regards,
Mich
46 matches
Mail list logo
