On 6/1/21 10:06 AM, Peter Firmstone wrote:
> If a vendor were to continue supporting SecurityManager and was
> backporting from OpenJDK, if it passes the JCK with SecurityManager
> disabled, that's still acceptable right?
Look at the licence agreement in conjunction with the JCK users' guide.
Se
Thanks Andrew,
I've been thinking about how to do this in a compatible manner.
The Guard.check call checks whether SecurityManager is enabled.
All permission checks in the JDK could be changed to call the
Guard.check method. Unfortunately other permission checks in user code
will be broken,
On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore
wrote:
> This PR contains the API and implementation changes for JEP-412 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.jav
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
> The essential change for this JEP, incl
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote:
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28
On Tue, 25 May 2021 16:20:35 GMT, Weijun Wang wrote:
>> For all modified files in #4073 having "security", "crypto", or "ssl" in
>> their names. Codes are refactored to bring a `@SuppressWarning` annotation
>> nearer to the deprecated API usage and also shrink the size of its target.
>>
>> I'l
On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote:
>> The code change refactors classes that have a `SuppressWarnings("removal")`
>> annotation that covers more than 50KB of code. The big annotation is often
>> quite faraway from the actual deprecated API usage it is suppressing, and
>> with
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 SocketExceptions are not wrapped into SSLException, also need to be
ca
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
> The code change refactors classes that have a `SuppressWarnings("removal")`
> annotation that covers more than 50KB of code. The big annotation is often
> quite faraway from the actual deprecated API usage it is suppressing, and
> with the annotation covering too big a portion it's easy to cal
> For all modified files in #4073 having "security", "crypto", or "ssl" in
> their names. Codes are refactored to bring a `@SuppressWarning` annotation
> nearer to the deprecated API usage and also shrink the size of its target.
>
> I'll add a copyright year update commit before integration.
We
On Fri, 21 May 2021 01:52:27 GMT, Weijun Wang wrote:
> The code change refactors classes that have a `SuppressWarnings("removal")`
> annotation that covers more than 50KB of code. The big annotation is often
> quite faraway from the actual deprecated API usage it is suppressing, and
> with the
On Mon, 24 May 2021 20:23:27 GMT, Weijun Wang wrote:
> For all modified files in #4073 having "security", "crypto", or "ssl" in
> their names. Codes are refactored to bring a `@SuppressWarning` annotation
> nearer to the deprecated API usage and also shrink the size of its target.
>
> I'll add
On Thu, 20 May 2021 18:38:35 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounte
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
On Thu, 20 May 2021 19:06:31 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounte
On Thu, 20 May 2021 19:46:51 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounte
On Fri, 28 May 2021 14:31:25 GMT, Sean Coffey wrote:
>> Added capability to allow the PKCS11 Token to be destroyed once a session is
>> logged out from. New configuration properties via pkcs11 config file.
>> Cleaned up the native resource poller also.
>>
>> New unit test case to test behaviou
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` abstract
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
On Wed, 2 Jun 2021 17:19:06 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.
>
> T
> 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
On Thu, 20 May 2021 20:00:07 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounte
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 can achieve
On 06/02/21 13:30, Maurizio Cimadamore wrote:
> This patch replaces `LibraryLookup` with a simpler `SymbolLookup`
> abstraction, a functional interface. Crucially, `SymbolLookup` does not
> concern with library loading, only symbol lookup. For this reason, two
> factories are added:
Hi,
While I a
On Thu, 20 May 2021 23:27:51 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounte
On Wed, 2 Jun 2021 17:52:07 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. AESWra
On Thu, 20 May 2021 22:59:18 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounte
On Sat, 22 May 2021 00:20:11 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 SecurityMana
On Wed, 2 Jun 2021 17:19:06 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.
>
> T
On Wed, 2 Jun 2021 17:29:51 GMT, Clive Verghese wrote:
> Thank you @fguallini for fixing this test.
>
> Should the SocketException be expected by the client logic as well?
> https://github.com/openjdk/jdk/blob/3631a39a4797919acbc7862cb94fa7f7be7f4f8a/test/jdk/sun/security/ssl/SSLSocketImpl/SSLSo
On Fri, 21 May 2021 00:05:17 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounte
On Wed, 2 Jun 2021 01:53:51 GMT, Anthony Scarpino wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 741:
>>
>>> 739: } else {
>>> 740: // If the remaining in buffer + data does
>>> not fill a
>>> 741
On Fri, 21 May 2021 00:03:40 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounte
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
On Wed, 2 Jun 2021 03:26:03 GMT, Anthony Scarpino wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 975:
>>
>>> 973: doUpdate(in, inOff, inLen, output, 0);
>>> 974: } catch (ShortBufferException e) {
>>> 975:
> 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 Wed, 2 Jun 2021 17:19:06 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.
>
> T
On Fri, 21 May 2021 01:19:44 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounte
On Mon, 24 May 2021 20:33:33 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review comments update
>
> test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java line 673:
>
>> 671:
>>
On Wed, 2 Jun 2021 20:17:20 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 Wed, 2 Jun 2021 18:40:48 GMT, Paul Sandoz wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with 10
>> additional commits since the last revision:
>>
>> - Update test/jdk/java/foreign/TestIntrinsics.java
>>
>>Co-authored-by: Paul Sandoz
>> - Update test/jdk/
> 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, 4 Feb 2021 10:51: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. AESWrapCiphe
> 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 18:18:46 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 six commits:
>>
>> - Merge branch 'master' into JDK-8267485
>> - Merge branch 'master' into JDK-8267485
>>
> 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
A comment from Ron highlites our issue:
the JDK contains only things that either only the JDK can technically do
We have a need to distinguish between different sources of code, as well
as user principles, and as well as Services. Our services are loaded
by separate ClassLoaders and are to
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 distinguish much between JITed and interpreted cod
On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey wrote:
> Added capability to allow the PKCS11 Token to be destroyed once a session is
> logged out from. New configuration properties via pkcs11 config file. Cleaned
> up the native resource poller also.
>
> New unit test case to test behaviour. So
51 matches
Mail list logo
