On Thu, 5 Sep 2024 20:20:28 GMT, Sean Mullan wrote:
>> I don't like the silent mode. If no one uses that key name, then everything
>> is fine anyway. Otherwise, if someone really sets it, it's very likely they
>> will want to read it somewhere and expect a non `null` value.
>>
>> Can we just s
On Thu, 5 Sep 2024 20:20:28 GMT, Sean Mullan wrote:
>> I don't like the silent mode. If no one uses that key name, then everything
>> is fine anyway. Otherwise, if someone really sets it, it's very likely they
>> will want to read it somewhere and expect a non `null` value.
>>
>> Can we just s
rity.util.PropertyExpander::expandNonStrict() throw
>> AssertionError instead of RuntimeException.
>>
>> Remove "this file" reference in java.security.
>>
>> Additionally, use java.security.Security::check() to check the
>> 'getProperty.'
On Thu, 5 Sep 2024 20:20:28 GMT, Sean Mullan wrote:
>> I don't like the silent mode. If no one uses that key name, then everything
>> is fine anyway. Otherwise, if someone really sets it, it's very likely they
>> will want to read it somewhere and expect a non `null` value.
>>
>> Can we just s
On Mon, 26 Aug 2024 18:53:58 GMT, Sean Mullan wrote:
>> I think throwing IAE is the cleanest approach and less likely there may be
>> unexpected behavior if we are not worried about backporting. It would break
>> any app previously using this as a property, but at least the behavior would
>> b
`activePaths` set to
>> detect recursive cycles. As we move down or up in the _includes_ stack,
>> `currentPath` and `activePaths` values are updated.
>>
>> ## Loading security properties from URLs (`loadFromUrl` method)
>>
>> The extra properti...
>
>
::getProperty/setProperty APIs.
>>
>> Co-authored-by: Martin Balao
>> Co-authored-by: Francisco Ferrari Bihurriet
>
> I think throwing IAE is the cleanest approach and less likely there may be
> unexpected behavior if we are not worried about backporting. It would break
&g
On Wed, 21 Aug 2024 00:09:25 GMT, Valerie Peng wrote:
>> Can someone help review this fix? Changed the required-mechanism check by
>> checking if the particular mechanism is inside the list of enabled supported
>> mechanisms. This should be more reliable than calling C_GetMechanismInfo(..)
>>
nclude" as key, also add a check in the test case.
>
> Initialize java.security.Security::props in a single place, and make it
> final.
>
> Make sun.security.util.PropertyExpander::expandNonStrict() throw
> AssertionError instead of RuntimeException.
>
> Remove
On Thu, 15 Aug 2024 17:15:33 GMT, Sean Mullan wrote:
> > We've not made a decision in regards to proposing this enhancement to old
> > releases. With that said, I wouldn't consider anything older than 21u. If
> > necessary, we can make backport-specific adjustments to the CSR and be more
> > c
nclude" as key, also add a check in the test case.
>
> Initialize java.security.Security::props in a single place, and make it
> final.
>
> Make sun.security.util.PropertyExpander::expandNonStrict() throw
> AssertionError instead of RuntimeException.
>
> Re
nclude" as key, also add a check in the test case.
>
> Initialize java.security.Security::props in a single place, and make it
> final.
>
> Make sun.security.util.PropertyExpander::expandNonStrict() throw
> AssertionError instead of RuntimeException.
>
>
On Wed, 7 Aug 2024 21:41:50 GMT, Weijun Wang wrote:
>> Done in 580d34a63b5d3b6c7d2323413f338527db2d9acd.
>
> Thanks. You might need to update the CSR to include this in the spec change.
Yes, I updated the user guide and the CSR to reflect this behavior.
-
PR Review Comment: https:/
rty("include", ...) is invoked.
>>
>> Co-authored-by: Martin Balao
>> Co-authored-by: Francisco Ferrari Bihurriet
>
> src/java.base/share/conf/security/java.security line 33:
>
>> 31: #
>> 32: # The special "include" property can be def
rty("include", ...) is invoked.
>>
>> Co-authored-by: Martin Balao
>> Co-authored-by: Francisco Ferrari Bihurriet
>
> src/java.base/share/classes/java/security/Security.java line 211:
>
>> 209: }
>> 210:
>> 211: private st
On Wed, 7 Aug 2024 18:40:53 GMT, Weijun Wang wrote:
>> Yes, that's intended. Files obtained from a URL have no issues with having
>> absolute-path includes. The only restriction for them is not to have
>> relative includes, as there isn't a file path base to resolve it.
>
> So you deploy some p
rty("include", ...) is invoked.
>>
>> Co-authored-by: Martin Balao
>> Co-authored-by: Francisco Ferrari Bihurriet
>
> src/java.base/share/classes/sun/security/util/PropertyExpander.java line 72:
>
>> 70: } catch (ExpandException e) {
>> 71:
On Wed, 7 Aug 2024 16:06:03 GMT, Weijun Wang wrote:
>> Proposed a change here:
>> https://github.com/openjdk/jdk/pull/16483/commits/530bd81c2a73a39f00c6ba9524752f30600cd04d
>
> I like this.
>
> Just wondering, shall we throw IAE if `getProperty("include")` is called as
> well? In a very rare c
rty("include", ...) is invoked.
>>
>> Co-authored-by: Martin Balao
>> Co-authored-by: Francisco Ferrari Bihurriet
>
> src/java.base/share/classes/java/security/Security.java line 241:
>
>> 239: try {
>> 240: Path path =
On Tue, 6 Aug 2024 23:19:08 GMT, Martin Balao wrote:
>> src/java.base/share/classes/java/security/Security.java line 901:
>>
>>> 899: if (SecPropLoader.isInclude(key)) {
>>> 900: return;
>>> 901: }
>>
>> Don't
On Tue, 6 Aug 2024 21:02:50 GMT, Weijun Wang wrote:
>> Francisco Ferrari Bihurriet has updated the pull request incrementally with
>> two additional commits since the last revision:
>>
>> - Ensure Security::setProperty() cannot issue an include
>>
>
On Wed, 17 Jul 2024 00:48:20 GMT, Valerie Peng wrote:
> Can someone help review this fix? Changed the required-mechanism check by
> checking if the particular mechanism is inside the list of enabled supported
> mechanisms. This should be more reliable than calling C_GetMechanismInfo(..)
> on t
On Tue, 6 Aug 2024 22:27:36 GMT, Martin Balao wrote:
>> Can someone help review this fix? Changed the required-mechanism check by
>> checking if the particular mechanism is inside the list of enabled supported
>> mechanisms. This should be more reliable than calling
On Wed, 24 Jul 2024 16:52:27 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>>
>> Work was begun in [another P
On Tue, 16 Jul 2024 23:22:45 GMT, Martin Balao wrote:
> Hi,
>
> I'd like to make a proposal to fix
> [JDK-8336499](https://bugs.openjdk.org/browse/JDK-8336499).
>
> With the proposed change, a non-sensitive RSA private key is first
> interpreted as a CRT key. If t
On Wed, 17 Jul 2024 16:32:09 GMT, Martin Balao wrote:
>> Hi,
>>
>> I'd like to make a proposal to fix
>> [JDK-8336499](https://bugs.openjdk.org/browse/JDK-8336499).
>>
>> With the proposed change, a non-sensitive RSA private key is first
>> in
equired. With that said, I manually exercised the `asNonCRT`
> path in the proposed change by using a CRT key and forcing `asCRT` to fail
> with the debugger.
>
> Thanks,
> Martin.-
Martin Balao has updated the pull request incrementally with one additional
commit since the last rev
Hi,
I'd like to make a proposal to fix
[JDK-8336499](https://bugs.openjdk.org/browse/JDK-8336499).
With the proposed change, a non-sensitive RSA private key is first interpreted
as a CRT key. If that fails (e.g. one of the attributes is not available), a
second attempt is made to interpret the
On Fri, 7 Jun 2024 13:33:55 GMT, Francisco Ferrari Bihurriet
wrote:
>> I created the release-note and doc sub-task for this RFE. Please take a look.
>> As for the code change, the rest looks fine to me.
>> Thanks,
>> Valerie
>
>> I created the release-note and doc sub-task for this RFE. Please t
On Fri, 7 Jun 2024 00:39:50 GMT, Valerie Peng wrote:
>> Francisco Ferrari Bihurriet has updated the pull request incrementally with
>> one additional commit since the last revision:
>>
>> Apply code-review suggestion
>>
>> Co-authored-by: Francisco
On Thu, 6 Jun 2024 22:22:06 GMT, Valerie Peng wrote:
>> Francisco Ferrari Bihurriet has updated the pull request incrementally with
>> one additional commit since the last revision:
>>
>> Apply code-review suggestion
>>
>> Co-authored-by: Francisco
On Thu, 6 Jun 2024 21:18:04 GMT, Valerie Peng wrote:
>> Francisco Ferrari Bihurriet has updated the pull request incrementally with
>> one additional commit since the last revision:
>>
>> Apply code-review suggestion
>>
>> Co-authored-by: Francisco
On Wed, 5 Jun 2024 18:27:11 GMT, Valerie Peng wrote:
>> The code does not assume that `outOfs = 0` but that the content of `out`
>> (between 0 and `outOfs`) is previously generated output of a multi-part
>> operation (not the whole output but one that is multiple of the block size).
>> `outOfs
On Wed, 5 Jun 2024 12:54:45 GMT, Francisco Ferrari Bihurriet
wrote:
>> I have no personal preference, but would suggest that if we change it to cut
>> the pad, we keep the decryption case aligned.
>
> What I like about this suggestion is that it allows unifying the repeated
> logic: the two bl
On Wed, 5 Jun 2024 02:41:35 GMT, Valerie Peng wrote:
>> Francisco Ferrari Bihurriet has updated the pull request incrementally with
>> one additional commit since the last revision:
>>
>> Apply code-review suggestion
>>
>> Co-authored-by: Francisco
On Wed, 5 Jun 2024 01:25:24 GMT, Valerie Peng wrote:
>> `convertCTSVariant` needs the total output's length to determine the
>> penultimate block size and do the slicing in the `out` array. The assumption
>> here is that `outOfs` has the previously generated output (if any) starting
>> at offs
mproving the error message.
>>
>>Co-authored-by: Francisco Ferrari
>>Co-authored-by: Martin Balao
>> - Merge 'openjdk/master' into JDK-8330843
>> - Revert re-arrangement of native methods parameters
>>
>>This reverts commit 0a77
mproving the error message.
>>
>>Co-authored-by: Francisco Ferrari
>>Co-authored-by: Martin Balao
>> - Merge 'openjdk/master' into JDK-8330843
>> - Revert re-arrangement of native methods parameters
>>
>>This reverts commit 0a77
mproving the error message.
>>
>>Co-authored-by: Francisco Ferrari
>>Co-authored-by: Martin Balao
>> - Merge 'openjdk/master' into JDK-8330843
>> - Revert re-arrangement of native methods parameters
>>
>>This reverts commit 0a77
On Wed, 29 May 2024 02:25:18 GMT, Valerie Peng wrote:
> Well, I am somewhat concerned about the incompatibility between the CTS
> support in SunJCE provider (CS3) and the ambiguity of CTS support in various
> PKCS11 libraries. The default for PKCS11 is CS1 which is based on NSS but may
> not a
ancisco Ferrari
>> Co-authored-by: Martin Balao
>
> src/java.base/share/conf/security/java.security line 40:
>
>> 38: # override properties in the included file.
>> 39: #
>> 40: # Included files, as well as files pointed by java.security.properties,
>
> S
ancisco Ferrari
>> Co-authored-by: Martin Balao
>
> src/java.base/share/conf/security/java.security line 70:
>
>> 68: # an error is thrown and explicit profile selection is required. In order
>> 69: # to override properties defined in this file, the include state
ancisco Ferrari
>> Co-authored-by: Martin Balao
>
> src/java.base/share/conf/security/java.security line 50:
>
>> 48: # switch between predefined security profiles on a per-execution basis.
>> 49: # Profile selection may be required or optional depending on the files
On Thu, 2 May 2024 21:07:03 GMT, Weijun Wang wrote:
> The revised text is much clearer. For the last sentence, I would suggest
> rephrasing "In order to prevent profile properties from being overridden" to
> "In order to override properties defined in the main file". Isn't that your
> real pur
On Thu, 2 May 2024 19:07:50 GMT, Weijun Wang wrote:
>> src/java.base/share/conf/security/java.security line 69:
>>
>>> 67: # statement will override any matching property defined in a profile.
>>> In order
>>> 68: # to avoid this behavior, the include statement may be placed at the
>>> end of
ancisco Ferrari
>> Co-authored-by: Martin Balao
>
> src/java.base/share/conf/security/java.security line 35:
>
>> 33: # this file with a filesystem path value. The effect of each definition
>> 34: # is to include a referred security properties file inline, adding all
On Thu, 2 May 2024 14:59:54 GMT, Weijun Wang wrote:
> In the new `java.security` text, you have "the file profile.security must
> exist". This is not necessary, right? I think what you meant to say is that
> "if the system property is not defined, then it will be expanded to an empty
> string
On Fri, 19 Apr 2024 13:02:03 GMT, Francisco Ferrari Bihurriet
wrote:
>>> In the compatibility risk description of the CSR:
>>>
>>> > In line with the efforts to check invalid URLs (see
>>> > [JDK-8294241](https://bugs.openjdk.org/browse/JDK-8294241): Deprecate URL
>>> > public constructors),
On Wed, 1 May 2024 18:34:41 GMT, Weijun Wang wrote:
> I'm seeing
>
> ```
> java.lang.reflect.InvocationTargetException
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
> at java.base/java.lang.reflect.Method.invoke(Method.j
On Wed, 1 May 2024 15:12:10 GMT, Weijun Wang wrote:
> Just one more question on the system property expansion when it's not
> defined. In your example:
>
> > include ${java.home}/conf/security/profile${SecurityProfile}.security
>
> How bad will it be if we require user to set `SecurityProfile`
VM flags
>>
>>Next, we will merge the openjdk/master branch and ignore the conflict in
>>this file.
>>
>>Co-authored-by: Martin Balao
>>Co-authored-by: Francisco Ferrari Bihurriet
>> - 8319332: Update copyright and ConfigFileTest.java
On Fri, 19 Apr 2024 19:40:53 GMT, Weijun Wang wrote:
> Yes, I can see its effect on the relative include. Maybe use the deprecated
> URL constructor as a fallback when the other mechanisms fail?
Yes, that's what we have in mind. We will try to handle it as a local path and
when not possible, w
On Fri, 19 Apr 2024 13:19:44 GMT, Weijun Wang wrote:
> > > > Is it worth breaking such invalid URLs?
>
> I'm just not sure about the compatibility impact. The example
> "file:///C:\some\path\extra.properties" you gave looks quite innocent and
> could be generated by a casual script.
>
> Can t
On Wed, 17 Apr 2024 14:55:05 GMT, Weijun Wang wrote:
> In the compatibility risk description of the CSR:
>
> > In line with the efforts to check invalid URLs (see
> > [JDK-8294241](https://bugs.openjdk.org/browse/JDK-8294241): Deprecate URL
> > public constructors), "java.security.properties"
VM flags
>>
>>Next, we will merge the openjdk/master branch and ignore the conflict in
>>this file.
>>
>>Co-authored-by: Martin Balao
>>Co-authored-by: Francisco Ferrari Bihurriet
>> - 8319332: Update copyright and ConfigFileTest.java
On Wed, 17 Apr 2024 14:28:58 GMT, Weijun Wang wrote:
> "If a system property does not have a value, it expands to the empty string."
> What's the benefit? It will be nice if you can include an example on the CSR.
Expanding to the empty string has the advantage that we can parameterize part
of
On Tue, 26 Mar 2024 17:48:49 GMT, Matthew Donovan wrote:
>> When resolving the location of the NSS library, the code appended a
>> hard-coded path: `/nss/lib`. This makes it difficult for a person to specify
>> the library when it is installed in a location such as `/usr/lib64`.
>>
>> In this
On Tue, 26 Mar 2024 14:02:27 GMT, Matthew Donovan wrote:
> When resolving the location of the NSS library, the code appended a
> hard-coded path: `/nss/lib`. This makes it difficult for a person to specify
> the library when it is installed in a location such as `/usr/lib64`.
>
> In this PR,
On Wed, 20 Mar 2024 03:39:58 GMT, Martin Balao wrote:
> Hi,
>
> I'd like to propose a fix for "8328556: Do not extract large CKO_SECRET_KEY
> keys from the NSS Software Token". See more details in the JBS ticket [1].
>
> No regressions observed in jdk
; --
> [1] - https://bugs.openjdk.org/browse/JDK-8328556
Martin Balao has updated the pull request incrementally with one additional
commit since the last revision:
Type in a TestLargeSecretKeys test comment.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18389/files
On Thu, 21 Mar 2024 17:17:41 GMT, Martin Balao wrote:
>> Hi,
>>
>> I'd like to propose a fix for "8328556: Do not extract large CKO_SECRET_KEY
>> keys from the NSS Software Token". See more details in the JBS ticket [1].
>>
>> No regressions
; --
> [1] - https://bugs.openjdk.org/browse/JDK-8328556
Martin Balao has updated the pull request incrementally with one additional
commit since the last revision:
Test TestLargeSecretKeys added.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18389/files
- new: ht
On Thu, 21 Mar 2024 06:32:56 GMT, Daniel Jeliński wrote:
> Would it be possible to add a regression test for this? I think you should be
> able to trigger a failure by calculating a HMAC using the same key two times.
May be possible. To create a large secret key we can use a DH derivation + TLS
Hi,
I'd like to propose a fix for "8328556: Do not extract large CKO_SECRET_KEY
keys from the NSS Software Token". See more details in the JBS ticket [1].
No regressions observed in jdk/sun/security/pkcs11.
Thanks,
Martin.-
--
[1] - https://bugs.openjdk.org/browse/JDK-8328556
-
C
Hi Kevin,
I implemented a prototype for HKDF derivation with SunPKCS11. This was
tested with the NSS Software Token v3.90, both in FIPS and non-FIPS
configurations. Testing includes the 7 vectors in RFC 5869 (*),
derivation of a DH base key, derivation of a ECDH base key and use of
derived ke
On 3/13/24 08:52, Wei-Jun Wang wrote:
On Mar 12, 2024, at 6:34 PM, Martin Balao wrote:
As I understand it, it's not that state is not maintained but that we are
keeping it on the parameters side. For example, a extraction phase call will
generate a PRK that will be kept in the param
egard—.
Thanks,
Martin.-
More soon.
Thanks!
image001.png
Kevin Driver
Mobile: +1.512.431.5690
Java Security Libraries
On Mar 12, 2024, at 4:25 PM, Martin Balao wrote:
Hi Kevin,
When looking at the proposed API, I noticed that the length of a
derived key or data can be potentially passed both as
Hi Kevin,
When looking at the proposed API, I noticed that the length of a derived
key or data can be potentially passed both as part of a KDFParameterSpec
and as a KDF::deriveKey or KDF::deriveData parameter. This is the case
for HKDF (HKDFParameterSpec) apparently. Having a length value on t
Hello,
We would like to announce that the Security Providers Filter JEP (draft)
is available for discussion.
* https://openjdk.org/jeps/8325511
As a reminder, the implementation pull-request is available at
https://github.com/openjdk/jdk/pull/15539
We look forward to any questions, commen
list of rules, returned by the parser, that represents filter
> patterns from left to right (see the filter syntax for reference). At the end
> of this list, a match-all and deny rule is added for default behavior. When a
> service is evaluated against the filter, each filter rul
On Mon, 5 Feb 2024 18:23:30 GMT, Martin Balao wrote:
> Hi,
>
> May I have a review for this fix to
> [JDK-8325254](https://bugs.openjdk.org/browse/JDK-8325254)?
>
> With this change, CKA_TOKEN = true is used as an indicator of a sensitive
> private key (opaque) only if
On Tue, 6 Feb 2024 18:32:58 GMT, Valerie Peng wrote:
>> Hi,
>>
>> May I have a review for this fix to
>> [JDK-8325254](https://bugs.openjdk.org/browse/JDK-8325254)?
>>
>> With this change, CKA_TOKEN = true is used as an indicator of a sensitive
>> private key (opaque) only if the token is NSS
On Tue, 6 Feb 2024 17:09:26 GMT, Mark Powers wrote:
>> Hi,
>>
>> May I have a review for this fix to
>> [JDK-8325254](https://bugs.openjdk.org/browse/JDK-8325254)?
>>
>> With this change, CKA_TOKEN = true is used as an indicator of a sensitive
>> private key (opaque) only if the token is NSS.
Hi,
May I have a review for this fix to
[JDK-8325254](https://bugs.openjdk.org/browse/JDK-8325254)?
With this change, CKA_TOKEN = true is used as an indicator of a sensitive
private key (opaque) only if the token is NSS. The behavior previous to
[JDK-8271566](https://bugs.openjdk.org/browse/JD
list of rules, returned by the parser, that represents filter
> patterns from left to right (see the filter syntax for reference). At the end
> of this list, a match-all and deny rule is added for default behavior. When a
> service is evaluated against the filter, each filter rul
list of rules, returned by the parser, that represents filter
> patterns from left to right (see the filter syntax for reference). At the end
> of this list, a match-all and deny rule is added for default behavior. When a
> service is evaluated against the filter, each filter rul
list of rules, returned by the parser, that represents filter
> patterns from left to right (see the filter syntax for reference). At the end
> of this list, a match-all and deny rule is added for default behavior. When a
> service is evaluated against the filter, each filter rul
list of rules, returned by the parser, that represents filter
> patterns from left to right (see the filter syntax for reference). At the end
> of this list, a match-all and deny rule is added for default behavior. When a
> service is evaluated against the filter, each filter rule is chec
list of rules, returned by the parser, that represents filter
> patterns from left to right (see the filter syntax for reference). At the end
> of this list, a match-all and deny rule is added for default behavior. When a
> service is evaluated against the filter, each filter rul
list of rules, returned by the parser, that represents filter
> patterns from left to right (see the filter syntax for reference). At the end
> of this list, a match-all and deny rule is added for default behavior. When a
> service is evaluated against the filter, each filter rule is chec
On Fri, 10 Nov 2023 17:33:33 GMT, Weijun Wang wrote:
> > By "the same key has multiple values", I assume you mean the key "import"?
> > The implementation overrides `put` and swallows these `include` lines so
> > they are never actually added as keys and values.
>
> Yes, I understand this, and
On Fri, 3 Nov 2023 05:42:56 GMT, Alan Bateman wrote:
>> Checking for _file_ in the URL scheme is not conclusive evidence that there
>> is a local file path behind. I'll give a couple of examples. In Unix/Linux
>> platforms, an URL of the form `file://example.com/path/to/some/file.txt` is
>> pr
On Thu, 2 Nov 2023 20:07:28 GMT, Alan Bateman wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
>> organized per fu
t changing all these
combined getInstance() calls?
thanks
Tony
On 10/6/23 9:55 AM, Martin Balao wrote:
Hi Tony,
Thanks for having a look at our proposal.
The main motivation for this enhancement is related to cryptographic
policy enforcement and, in particular, the following capabilities
On Fri, 1 Sep 2023 15:13:46 GMT, Martin Balao wrote:
> In addition to the goals, scope, motivation, specification and requirement
> notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would
> like to describe the most relevant decisions taken during the implementat
Hi Tony,
Thanks for having a look at our proposal.
The main motivation for this enhancement is related to cryptographic
policy enforcement and, in particular, the following capabilities: 1)
enforcing that cryptographic services are provided by chosen security
providers only, and 2) allowing o
uld not be a problem.
Martin.-
--
[1] - https://bugs.openjdk.org/browse/JDK-8315487
[2] - https://github.com/openjdk/jdk/pull/15539
On Thu, Jul 13, 2023 at 1:01 PM Sean Mullan wrote:
>
>
> On 7/13/23 12:27 PM, Martin Balao wrote:
> > On 7/13/23 12:06, Sean Mullan wrote:
>
introduced to make the SunNativeProvider security provider use the
Provider::putService API to register services, instead of the legacy
Provider::putAll. This was the only security provider in OpenJDK using a
non-Provider::putService API. While this change does not have any observable
implications,
On Fri, 2 Jun 2023 12:58:36 GMT, Andrew John Hughes wrote:
>> Currently, security properties are held within the `java.security` file in
>> the JDK tree for each installed JDK. The system property
>> `java.security.properties` can be used to point to a file containing
>> additional properties.
Thanks,
Martin.-
--Sean
On 7/13/23 11:44 AM, Martin Balao wrote:
Hi Sean,
Thanks for your feedback.
Just to give some visibility, we have implemented most of the
functionality and are now working on final adjustments, more tests
coverage, documentation and internal reviews. The implementation
github.com/openjdk/jdk/pull/14394
On 5/24/23 5:03 PM, Martin Balao wrote:
Hi,
Thanks Anthony for your feedback.
We've been exploring the syntax and semantics for this new property
further, with the goal of making it more consistent and simple while
retaining expressiveness power. We understand th
On Wed, 7 Jun 2023 20:24:12 GMT, Martin Balao wrote:
> We would like to propose a fix for 8309569. In this bug, a Java signature
> buffer of length 0 is passed to
> sun.security.pkcs11.wrapper.PKCS11::C_VerifyFinal to finish an ongoing
> signature verification operation. Notice th
We would like to propose a fix for 8309569. In this bug, a Java signature
buffer of length 0 is passed to
sun.security.pkcs11.wrapper.PKCS11::C_VerifyFinal to finish an ongoing
signature verification operation. Notice that finishing the operation by means
of C_SessionCancel was either not tried
On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao wrote:
> We would like to propose an implementation for the [JDK-8301553: Support
> Password-Based Cryptography in
> SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement
> requirement.
>
> In addition to pursui
On Tue, 6 Jun 2023 18:18:43 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #5)
>>
>>
od at the implementation level (see
> ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class
> and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The
> reason is to persist parameters data that has to be consistent between calls
> to ```P
On Mon, 5 Jun 2023 23:17:02 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4)
>>
>>
On Sat, 27 May 2023 06:24:36 GMT, Martin Balao wrote:
>> We would like to propose an implementation for the [JDK-8301553: Support
>> Password-Based Cryptography in
>> SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement
>> requirement.
>>
On Tue, 6 Jun 2023 00:24:21 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4)
>>
>>
On Mon, 5 Jun 2023 23:18:49 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4)
>>
>>
1 - 100 of 163 matches
Mail list logo
