David,
I understand the reasons behind seeing authorization checks at the runtime
layer as something that just adds, without any harm in the worst case (all
of this putting the maintenance cost and other arguments aside.)
My concern is more about the general security principles underpinning the
Hi,
On 4/8/22 11:13 AM, Sean Mullan wrote:
> In general, I think authorization is best done at a higher layer within
> the application and not via low-level SM callouts. Authorize the subject
> first and if not acceptable, prevent the operation or API from being
> called in the first place. Once
On Mon, 2 Aug 2021 19:31:54 GMT, Martin Balao wrote:
> As described in JDK-8271566 [1], this patch proposal is intended to fix a
> problem that arises when using DSA keys that have a 256-bits (or larger) G
> parameter for signatures (either signing or verifying). There were some
&g
On Tue, 30 Nov 2021 19:48:19 GMT, Valerie Peng wrote:
>> Hmm, thinking more about "internal"/"opaque", given this is naming for the
>> parent, maybe "internal" is more correct. The non-sensitive keys are
>> encapsulated by the children classes and is still an instance of the parent.
>> If you
ure that it will succeed.
>
> No regressions found in jdk/sun/security/pkcs11. A new test added:
> LargerDSAKey.
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566
Martin Balao has updated the pull request incrementally with one additional
commit since the la
On Fri, 3 Dec 2021 19:48:53 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains six commits:
>>
>> - 8271566: DSA signature length value is not accurate in P11Signat
On Tue, 30 Nov 2021 19:48:19 GMT, Valerie Peng wrote:
>> Hmm, thinking more about "internal"/"opaque", given this is naming for the
>> parent, maybe "internal" is more correct. The non-sensitive keys are
>> encapsulated by the children classes and is still an instance of the parent.
>> If you
On Fri, 19 Nov 2021 19:50:33 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> P11Key static inner classes refactorings.
>
> Hmm, thinking more about "inter
On Mon, 1 Nov 2021 17:24:48 GMT, Weijun Wang wrote:
>> The S4U2proxy extension requires that the service ticket to the first
>> service has the forwardable flag set, but some versions of Windows Server do
>> not set the forwardable flag in a S4U2self response and accept it in a
>> S4U2proxy
On Fri, 22 Oct 2021 16:31:02 GMT, Weijun Wang wrote:
> The S4U2proxy extension requires that the service ticket to the first service
> has the forwardable flag set, but some versions of Windows Server do not set
> the forwardable flag in a S4U2self response and accept it in a S4U2proxy
>
On Mon, 1 Nov 2021 14:42:32 GMT, Martin Balao wrote:
>>> * The names 'second' and 'secondTicket' -that were used before- don't look
>>> ideal to me. I've not seen them used neither in RFC 4120 nor in MS-SFU
>>> (v.20.0). In the case of 'additionalTickets
On Thu, 28 Oct 2021 21:49:54 GMT, Weijun Wang wrote:
>
> > * The FORWARDABLE check removed is the one in S4U2Self. Apparently, for
> > S4U2Proxy with non-S4U2Self second-tickets there were no checks. Now we
> > check at S4U2Proxy level (for all 'second' tickets, S4U2Self and
> > non-S4U2Self
On Thu, 18 Nov 2021 18:37:38 GMT, Valerie Peng wrote:
>>> > ```
>>> > * By eliminating P11RSAPrivateKey::getModulus, looks to me that
>>> > P11PrivateKeyRSA::getModulus and P11PrivateKeyRSA::fetchValues are now
>>> > called, leading to an unnecessary call to the native library as the
>>> >
On Tue, 2 Nov 2021 22:44:16 GMT, Valerie Peng wrote:
> > ```
> > * By eliminating P11RSAPrivateKey::getModulus, looks to me that
> > P11PrivateKeyRSA::getModulus and P11PrivateKeyRSA::fetchValues are now
> > called, leading to an unnecessary call to the native library as the modulus
> > was
On Tue, 2 Nov 2021 22:44:16 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> P11Key static inner classes refactorings.
>
> Hi Martin,
>
> P
On Fri, 13 Aug 2021 17:11:45 GMT, Martin Balao wrote:
>> As described in JDK-8271566 [1], this patch proposal is intended to fix a
>> problem that arises when using DSA keys that have a 256-bits (or larger) G
>> parameter for signatures (either signing or verifying
On Wed, 22 Sep 2021 10:36:37 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8273894?
>
> Given the nature of the code in `ReferralsCache`, I haven't been able to add
> a new jtreg test
On Fri, 13 Aug 2021 17:11:45 GMT, Martin Balao wrote:
>> As described in JDK-8271566 [1], this patch proposal is intended to fix a
>> problem that arises when using DSA keys that have a 256-bits (or larger) G
>> parameter for signatures (either signing or verifying
ure that it will succeed.
>
> No regressions found in jdk/sun/security/pkcs11. A new test added:
> LargerDSAKey.
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566
Martin Balao has updated the pull request incrementally with one additional
commit
On Fri, 6 Aug 2021 19:27:30 GMT, Martin Balao wrote:
> I'd like to propose a fix for JDK-8270137 [1].
>
> This bug is triggered when using a previously stored referral ticket (in the
> Referrals Cache) at the moment of following a S4U2Proxy cross-realm referral.
> The mistakenl
On Tue, 10 Aug 2021 16:16:39 GMT, Weijun Wang wrote:
>> The TGS in "the TGS is the one" is clientSvcTicketEnc indeed. I admit that
>> all these names are a bit confusing -but so it is the underlying protocol-.
>> I'll take the 'user" suggestion and rename it to userSvcTicketEnc -in the
>>
uses
> cached S4U2Proxy/S4U2Self referral tickets.
>
> No regressions observed in jdk/sun/security/krb5.
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8270137
Martin Balao has updated the pull request incrementally with one additional
commit sinc
On Tue, 10 Aug 2021 14:08:24 GMT, Weijun Wang wrote:
>> Hmm.. in my view, adding the S4U2Type to the key will provide not much value
>> other than minor consistency checks (in the form of debug-mode assertions)
>> because the assumptions that a key with a non-null 'user' value is of
>>
uses
> cached S4U2Proxy/S4U2Self referral tickets.
>
> No regressions observed in jdk/sun/security/krb5.
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8270137
Martin Balao has updated the pull request incrementally with one additional
commit since the last revisi
On Mon, 9 Aug 2021 19:54:21 GMT, Weijun Wang wrote:
>> I'd like to propose a fix for JDK-8270137 [1].
>>
>> This bug is triggered when using a previously stored referral ticket (in the
>> Referrals Cache) at the moment of following a S4U2Proxy cross-realm
>> referral. The mistakenly-used
On Mon, 9 Aug 2021 19:48:24 GMT, Weijun Wang wrote:
>> I'd like to propose a fix for JDK-8270137 [1].
>>
>> This bug is triggered when using a previously stored referral ticket (in the
>> Referrals Cache) at the moment of following a S4U2Proxy cross-realm
>> referral. The mistakenly-used
On Mon, 2 Aug 2021 19:31:54 GMT, Martin Balao wrote:
> As described in JDK-8271566 [1], this patch proposal is intended to fix a
> problem that arises when using DSA keys that have a 256-bits (or larger) G
> parameter for signatures (either signing or verifying). There were some
&g
On Tue, 3 Aug 2021 21:05:24 GMT, Valerie Peng wrote:
>> As described in JDK-8271566 [1], this patch proposal is intended to fix a
>> problem that arises when using DSA keys that have a 256-bits (or larger) G
>> parameter for signatures (either signing or verifying). There were some
>>
I'd like to propose a fix for JDK-8270137 [1].
This bug is triggered when using a previously stored referral ticket (in the
Referrals Cache) at the moment of following a S4U2Proxy cross-realm referral.
The mistakenly-used referral ticket matched the client and service names but it
was obtained
On 6/30/21 3:09 PM, mark.reinh...@oracle.com wrote:
> The best way to submit a bug report against the JDK is via
> https://bugreport.java.com. Please include your patch in that
> submission. For IP clarity, we cannot take in patches posted to
> non-OpenJDK infrastructure.
>
>> In case you would
As described in JDK-8271566 [1], this patch proposal is intended to fix a
problem that arises when using DSA keys that have a 256-bits (or larger) G
parameter for signatures (either signing or verifying). There were some
incorrect assumptions and hard-coded length values in the code before.
On Fri, 23 Apr 2021 19:32:35 GMT, Martin Balao wrote:
> Hi,
>
> Please find in this PR a proposal to fix JDK-8265462 [1].
>
> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
> Module. If the NSS Internal Module has more slots (for ex
On Tue, 4 May 2021 23:26:34 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Documentation improvements and minor reordering
>
> Here are some comments. Re
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8265462
Martin Balao has updated the pull request incrementally with one additional
commit since the last revision:
Documentation improvements and minor reordering
-
Changes:
- all: https://git.openjdk.java.net/jdk/p
On Tue, 4 May 2021 23:25:16 GMT, Valerie Peng wrote:
>> Hi,
>>
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>>
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
>> Module. If the NSS Internal Module has more slots (for example, as a result
>> of
On Tue, 4 May 2021 22:24:36 GMT, Valerie Peng wrote:
>> Hi,
>>
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>>
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
>> Module. If the NSS Internal Module has more slots (for example, as a result
>> of
On Tue, 4 May 2021 22:19:18 GMT, Valerie Peng wrote:
>> Hi,
>>
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>>
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
>> Module. If the NSS Internal Module has more slots (for example, as a result
>> of
On Tue, 4 May 2021 22:14:00 GMT, Valerie Peng wrote:
>> Hi,
>>
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>>
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
>> Module. If the NSS Internal Module has more slots (for example, as a result
>> of
Hi,
Please find in this PR a proposal to fix JDK-8265462 [1].
With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
Module. If the NSS Internal Module has more slots (for example, as a result of
an initialization sequence such as the one triggered from the
On Wed, 10 Feb 2021 15:06:35 GMT, Martin Balao wrote:
> Hi,
>
> I'd like to propose a fix for JDK-8261355 [1].
>
> The scheme used for holding data and padding while performing encryption
> operations is almost the same than the existing one for decryption. The
On Wed, 10 Feb 2021 15:06:35 GMT, Martin Balao wrote:
> Hi,
>
> I'd like to propose a fix for JDK-8261355 [1].
>
> The scheme used for holding data and padding while performing encryption
> operations is almost the same than the existing one for decryption. The
observed in jdk/sun/security/pkcs11.
>
> Thanks,
> Martin.-
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355
Martin Balao has updated the pull request incrementally with one additional
commit since the last revision:
Minor comment enhancement
-
Change
On Wed, 17 Feb 2021 12:22:55 GMT, Valerie Peng wrote:
>> Hi,
>>
>> I'd like to propose a fix for JDK-8261355 [1].
>>
>> The scheme used for holding data and padding while performing encryption
>> operations is almost the same than the existing one for decryption. The only
>> difference is
observed in jdk/sun/security/pkcs11.
>
> Thanks,
> Martin.-
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355
Martin Balao has updated the pull request incrementally with one additional
commit since the last revision:
Bug fixes and improvements as discu
On Tue, 6 Apr 2021 16:56:49 GMT, Martin Balao wrote:
>> test/jdk/sun/security/pkcs11/Cipher/EncryptionPadding.java line 97:
>>
>>> 95: throw new Exception("Cross-provider cipher test failed.");
>>> 96: }
>>> 9
On Wed, 31 Mar 2021 00:16:28 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains three commits:
>>
>> - Avoid overriding buffered bytes with padding in the doF
On Wed, 31 Mar 2021 00:07:14 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains three commits:
>>
>> - Avoid overriding buffered bytes with padding in the doF
On Wed, 31 Mar 2021 17:00:26 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains three commits:
>>
>> - Avoid overriding buffered bytes with padding in the doF
On Wed, 31 Mar 2021 16:51:31 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains three commits:
>>
>> - Avoid overriding buffered bytes with padding in the doF
On Tue, 30 Mar 2021 22:12:16 GMT, Valerie Peng wrote:
>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java
>> line 819:
>>
>>> 817: int startOff = 0;
>>> 818: if (reqBlockUpdates) {
>>> 819: startOff =
On Tue, 30 Mar 2021 21:49:57 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains three commits:
>>
>> - Avoid overriding buffered bytes with padding in the doF
On Tue, 30 Mar 2021 21:24:37 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains three commits:
>>
>> - Avoid overriding buffered bytes with padding in the doF
On Tue, 30 Mar 2021 21:19:38 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains three commits:
>>
>> - Avoid overriding buffered bytes with padding in the doF
On Tue, 30 Mar 2021 20:51:26 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contain
On Tue, 2 Mar 2021 13:16:24 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains three commits:
>>
>> - Avoid overriding buffered bytes with padding in the doF
observed in jdk/sun/security/pkcs11.
>
> Thanks,
> Martin.-
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355
Martin Balao has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains three commits:
- Avoid overriding bu
On Fri, 12 Feb 2021 11:05:22 GMT, Matthias Baesken wrote:
>> Fix exception in test
>> sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java:
>>
>> java.security.AccessControlException: access denied
>> ("java.security.SecurityPermission" "removeProvider.SUN")
>> at
>>
Hi,
I'd like to propose a fix for JDK-8261355 [1].
The scheme used for holding data and padding while performing encryption
operations is almost the same than the existing one for decryption. The only
difference is that encryption does not require a block-sized buffer to be
always held
On Mon, 28 Dec 2020 16:24:43 GMT, Martin Balao wrote:
> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
> invalid block size), we now cancel the operation before returning the
> underlying Session to the Session Manager. This allows to use the returned
On Wed, 20 Jan 2021 13:47:13 GMT, Martin Balao wrote:
>> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
>> invalid block size), we now cancel the operation before returning the
>> underlying Session to the Session Manager. This allows to use the re
ATION_ACTIVE error
> would be raised from the PKCS#11 library.
>
> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is
> introduced as part of this PR.
>
> No regressions found in jdk/sun/security/pkcs11.
Martin Balao has updated the pull request inc
On Wed, 20 Jan 2021 06:00:41 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Minor documentation improvement in P11Mac regarding Cancel Operation
>
> src/jdk.cry
On Wed, 20 Jan 2021 05:58:49 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removing the encryption-update path in CancelMultipart test as it depends
>> on a kno
On Wed, 20 Jan 2021 05:55:26 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removing the encryption-update path in CancelMultipart test as it depends
>> on a kno
On Wed, 20 Jan 2021 03:16:32 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removing the encryption-update path in CancelMultipart test as it depends
>> on a kno
On Thu, 14 Jan 2021 20:29:54 GMT, Valerie Peng wrote:
>> The update fails because the native mechanism (CKM_AES_ECB) has no padding
>> and OpenJDK does not buffer data in the Java side for encryption [1] (this
>> is a bug that I'll address soon). As a result, there is a PKCS#11 call with
>>
ATION_ACTIVE error
> would be raised from the PKCS#11 library.
>
> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is
> introduced as part of this PR.
>
> No regressions found in jdk/sun/security/pkcs11.
Martin Balao has updated the pull request inc
ATION_ACTIVE error
> would be raised from the PKCS#11 library.
>
> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is
> introduced as part of this PR.
>
> No regressions found in jdk/sun/security/pkcs11.
Martin Balao has updated the pull request inc
On Wed, 13 Jan 2021 00:53:01 GMT, Valerie Peng wrote:
>>> For cipher impls, there are more than just P11Cipher, there are also
>>> P11AEADCipher and P11RSACipher. It looks like they should be updated with
>>> this defensive cancellation change unless the non-compliant NSS impl is
>>>
ATION_ACTIVE error
> would be raised from the PKCS#11 library.
>
> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is
> introduced as part of this PR.
>
> No regressions found in jdk/sun/security/pkcs11.
Martin Balao has updated the pull request inc
On Wed, 13 Jan 2021 00:53:01 GMT, Valerie Peng wrote:
>>> For cipher impls, there are more than just P11Cipher, there are also
>>> P11AEADCipher and P11RSACipher. It looks like they should be updated with
>>> this defensive cancellation change unless the non-compliant NSS impl is
>>>
On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote:
> As described in JDK-8259319 [1], this fix proposal is to set proper access
> permissions so the SunPKCS11 provider can create instances of SunJCE classes
> when a Security Manager is installed and the fallback schem
On Fri, 8 Jan 2021 20:08:57 GMT, Valerie Peng wrote:
>> Because a C_EncryptUpdate call that returns with an error here [1] implies
>> that a session (with an active operation) is returned to the Session Manager
>> here [2] [3]. For decryption, where we have proper padding on the Java side
>>
On Mon, 11 Jan 2021 19:52:16 GMT, Valerie Peng wrote:
> For cipher impls, there are more than just P11Cipher, there are also
> P11AEADCipher and P11RSACipher. It looks like they should be updated with
> this defensive cancellation change unless the non-compliant NSS impl is
>
On Fri, 8 Jan 2021 19:35:47 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Limit P11Util::getProvider privileged access to the required
>> 'accessClassInP
tests category.
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319
Martin Balao has updated the pull request incrementally with two additional
commits since the last revision:
- Limit P11Util::getProvider privileged access to the required
'accessClassInPackage' Runtim
On Thu, 7 Jan 2021 21:23:55 GMT, Sean Mullan wrote:
>> Martin Balao has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Limit P11Util::getProvider privileged access to the required
>> 'accessClassInP
On Thu, 7 Jan 2021 19:29:29 GMT, Valerie Peng wrote:
>> As described in JDK-8259319 [1], this fix proposal is to set proper access
>> permissions so the SunPKCS11 provider can create instances of SunJCE classes
>> when a Security Manager is installed and the fallback scheme is used.
>>
>> No
ATION_ACTIVE error
> would be raised from the PKCS#11 library.
>
> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is
> introduced as part of this PR.
>
> No regressions found in jdk/sun/security/pkcs11.
Martin Balao has updated the pull request inc
On Thu, 7 Jan 2021 20:51:02 GMT, Martin Balao wrote:
>
> @valeriepeng are you okay with this reasoning?
>
I changed my mind around this decision and I'm inclined not to make any code
changes to P11Signature. Only a documentation note that reflects this analysis
should be neede
On Thu, 7 Jan 2021 21:00:58 GMT, Valerie Peng wrote:
>> I chose the term 'leak' in the sense of a resource not properly cleaned up.
>> In this case, the 'leak' would not cause a memory/sockets/file-descriptors
>> but a 'usable-sessions' exhaustion. It's always an analogy, but the sense is
>>
On Thu, 7 Jan 2021 18:56:03 GMT, Martin Balao wrote:
> In summary, I believe we need changes in the OpenJDK side to properly handle
> CKR_BUFFER_TOO_SMALL errors when C_SignFinal or C_Sign PKCS#11 functions are
> called from P11Signature. Even if other error types or
On Tue, 5 Jan 2021 19:41:27 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Comment describing the CancelMultipart test assertion.
>
> test/jdk/sun/security/pkcs
On Tue, 5 Jan 2021 19:32:42 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Comment describing the CancelMultipart test assertion.
>
> test/jdk/sun/security/pkcs
ATION_ACTIVE error
> would be raised from the PKCS#11 library.
>
> The jdk/sun/security/pkcs11/Cipher/CancelMultipart.java regression test is
> introduced as part of this PR.
>
> No regressions found in jdk/sun/security/pkcs11.
Martin Balao has updated the pull request inc
On Tue, 5 Jan 2021 19:30:13 GMT, Valerie Peng wrote:
>> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
>> invalid block size), we now cancel the operation before returning the
>> underlying Session to the Session Manager. This allows to use the returned
>> Session
On Mon, 4 Jan 2021 21:35:48 GMT, Valerie Peng wrote:
>> When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
>> invalid block size), we now cancel the operation before returning the
>> underlying Session to the Session Manager. This allows to use the returned
>> Session
As described in JDK-8259319 [1], this fix proposal is to set proper access
permissions so the SunPKCS11 provider can create instances of SunJCE classes
when a Security Manager is installed and the fallback scheme is used.
No regressions found in jdk/sun/security/pkcs11 tests category.
--
[1] -
When a multi-part cipher operation fails in SunPKCS11 (i.e. because of an
invalid block size), we now cancel the operation before returning the
underlying Session to the Session Manager. This allows to use the returned
Session for a different purpose. Otherwise, an CKR_OPERATION_ACTIVE error
Hi,
I'd like to propose a fix for 8251117 [1], on behalf of Zdenek Zambersky
(Red Hat employee - OCA signed).
Webrev.00:
* http://cr.openjdk.java.net/~mbalao/webrevs/8251117/8251117.webrev.00/
As noted in the ticket [1], the fix is about using P11Key::length method
for retrieving P11Key sizes
Hello Max,
I'd like to propose a patch for "8250582: Revert Principal Name type to
NT-UNKNOWN when requesting TGS Kerberos tickets" [1].
Webrev.00:
* http://cr.openjdk.java.net/~mbalao/webrevs/8250582/8250582.webrev.00/
This change is trivial and we are reverting to a previous (and known
Hi,
On 6/5/20 5:46 PM, Simon Tooke wrote:
> Please let me know what you think.
>
> updated webrev:
> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/01/01/
>
Overall, the intrinsics looks good to me.
A few minor comments:
* sharedRuntime_x86_64.cpp
* L3685
* Do we still need
On 5/30/20 8:54 AM, Weijun Wang wrote:
> Please take a review at
>
>http://cr.openjdk.java.net/~weijun/8246193/webrev.00/
>
> While searching for ENC-PA-REP in the PA-DATA list of AS-REQ, it's possible
> there is no PA-DATA at all. This could happen when preauth is turned off.
>
I'm not a
Hi Max,
On 3/30/20 5:24 PM, Martin Balao wrote:
>
> CSR requested here: https://bugs.openjdk.java.net/browse/JDK-8241871
>
Now that the CSR has been approved, are we good to push?
Thanks,
Martin.-
Hi Sean,
On 4/2/20 6:23 PM, Martin Balao wrote:
> Webrev.02:
>
> * http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.02
>
> On 4/2/20 5:02 PM, Sean Mullan wrote:
>>
>> In the java.security file might add the sentence "The default value of
Hi,
Webrev.02:
* http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.02
On 4/2/20 5:02 PM, Sean Mullan wrote:
>
> In the java.security file might add the sentence "The default value of
> the property is "false"" just to avoid any confusion.
>
Added.
Thanks,
Martin.-
Hi Sean,
Thanks for having a look at this.
On 4/1/20 4:47 PM, Sean Mullan wrote:
>
> 65 * System property that if set (or set to "true"), allows trust
> anchor
>
> Change this to "System or security property ..."
Fixed.
>
> - Update the copyright date.
Fixed.
>
> * java.security
>
Hi Max,
Thanks for having a look at the CSR.
On 3/30/20 11:39 PM, Weijun Wang wrote:
> 1. I don't think there is a need to talk about the java.security.krb5.conf
> system property, the krb5.conf file name is more popular.
>
Added a reference to the krb5.conf file in the first place. I wish we
Hi,
I'd like to request a review for 8241888 [1].
Webrev.00:
* http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.00/
CSR (waiting for review): https://bugs.openjdk.java.net/browse/JDK-8241893
I've not included my regression test as it's a trivial change and my
test is
Hi Max,
CSR requested here: https://bugs.openjdk.java.net/browse/JDK-8241871
Look forward to your comments or approval there.
Thanks,
Martin.-
1 - 100 of 236 matches
Mail list logo
