Nice! Thank you!
On Wed, Dec 18, 2024 at 5:57 AM Martin Balao wrote:
> On 12/18/24 05:25, Xuelei Fan wrote:> Hm, that would be nice if JIT
> could optimize it. Did you have a chance
> > to verify it?
> >
>
> Yes. For example, to verify we can do the followin
On Tue, Dec 17, 2024 at 9:34 PM Martin Balao wrote:
> On Wed, Dec 18, 2024 at 1:39 AM Xuelei Fan wrote:
>
>> On Tue, Dec 17, 2024 at 6:45 PM Martin Balao wrote:
>>
>>> On Wed, 18 Dec 2024 00:35:38 GMT, Xue-Lei Andrew Fan
>>> wrote:
>>>
>>>
On Tue, Dec 17, 2024 at 8:26 PM Xuelei Fan wrote:
>
>
> > I have to disable this feature, and don’t allow any security property
>> setting, which is not easy to me once an editable property is introduced.
>>
>> No need for this, the filter is disabled by default. I
>
>
> Hi @XueleiFan,
>
> > I did not see the benefit of the proposal yet, except the troublesome I
> have to handle with in practice.
>
> The benefit is the removal of the limitation described in the [section
> **What is the current limitation?** of the JBS enhancement issue](
> https://bugs.openjd
Oh, your testing is checking service type Cipher which is Java SE service.
It is not the case we discussed in the context: non-Java SE service types.
Xuelei
On Tue, Dec 17, 2024 at 2:47 PM Martin Balao wrote:
> On Tue, 17 Dec 2024 22:13:09 GMT, Xue-Lei Andrew Fan
> wrote:
>
> > Sorry, I meant
Let’s simplify the discussion. Just one question, is the filter able to
filter out FIPS unapproved crypto algorithms and parameters form a provide?
If the answer is yes, I will support this proposal and you take any
possible action to make it. If the answer is no, I will stop to discuss as
well a
On Thu, Dec 12, 2024 at 1:20 PM Sean Mullan wrote:
> Xuelei,
>
> What value does a pluggable provider API provide?
With a public API, it is not necessary any longer for OpenJDK to maintain a
filter syntax. If the filter syntax is supported, it will require JDK to
maintain and track the develop
]: https://chromestatus.com/feature/5696925844111360
> On Aug 2, 2022, at 7:53 PM, Xuelei Fan wrote:
>
>>
>> On Aug 2, 2022, at 2:55 PM, Bradford Wetmore
>> wrote:
>>
>> Hi Xuelei,
>>
>> Sean wrote:
>>
>>> I haven't had time to
> On Jan 25, 2023, at 8:43 PM, Wei-Jun Wang wrote:
> If someone really cares about the result of getProvider(), they should be
> careful no other thread calls encapsulation or decapsulation.
If no-one care about the result of getProvider(), is it possible to remove this
method from the desi
n designed as more immutable, the APIs may look
different.
- var kemS = KEM.getInstance("DHKEM”);
+ var kemS = KEM.getInstance("DHKEM”, pkR, new
DerivedKeyParameterSpec("AES", 32));
Best,
Xuelei
> Thanks,
> Max
>
>
> > On Feb 4, 2023, at 10:44 AM, Xuelei Fan
Hi,
Thank you for the update.
What’s the different impact of parameters like algorithm name,
KEMParameterSpec, PublicKey/PrivateKey and DerivedKeyParameterSpec? I’m not
very sure of it.
For example, at 2013, the following cord should work without any issues:
1. var kemS = KEM.getInstance("
> On Jan 25, 2023, at 8:43 PM, Wei-Jun Wang wrote:
> If someone really cares about the result of getProvider(), they should be
> careful no other thread calls encapsulation or decapsulation.
If no-one care about the result of getProvider(), is it possible to remove this
method from the desi
Jun Wang wrote:
>
> Hi Xuelei,
>
> That's a bold suggestion. However, we'd like to the tradition of JCA/JCE at
> the moment.
>
> Thanks,
> Max
>
>
>> On Jan 25, 2023, at 3:03 PM, Xuelei Fan wrote:
>>
>> For new set of service API
For new set of service APIs, it may be worthy of considering to simplify the
design and avoid duplicated SPIs by using java.util.ServiceLoade.
Xuelei
> On Jan 25, 2023, at 11:24 AM, Wei-Jun Wang wrote:
>
> Hi All,
>
> We are working on providing a new API for KEM (Key Encapsulation Mechanism)
I’m not very sure what the update public APIs may look like. If we are able to
collect the possible card exception reasons, the design of
CertPathValidatorException and CertPathValidatorException.BasicReason could be
a reference.
Xuelei
> On Nov 23, 2022, at 9:21 AM, Michael StJohns wrote:
>
Hi,
As I’m working on this area recently, I will see if I can contribute. But it
may be no easier than JDK 21. If you don’t mind, I may ask for more
requirement details later and help for testing.
Thanks,
Xuelei
> On Nov 15, 2022, at 11:23 PM,
> wrote:
>
> Hi Xuelei and Sean,
>
> We use
> The wording in this PR specifically refers to the protocol version that
was specified. It isn't covering other optional protocols that may be
supported.
Sorry, I may not make it clear. The protocol specified in
SSLContext.getInstance is not TLS protocol version. I think the protocol
disabled i
Hi Benjamin,
May I ask what are the sizes of brainpool curves used in practice?
Thank,
Xuelei
> On Nov 14, 2022, at 12:36 AM, benjamin.marw...@f-i.de wrote:
>
> Hello everyone!
>
> To our surprise, brainpool EC have been deprecated with Java 14+ [1].
> However, JDK-8234924 [1] does not add any
4434>
> [3] https://trac.nginx.org/nginx/ticket/1977
> <https://trac.nginx.org/nginx/ticket/1977>
>
>
> sob., 5 lis 2022 o 04:01 Bradford Wetmore <mailto:bradford.wetm...@oracle.com>> napisał(a):
>
>
> On 11/4/2022 8:58 AM, Xuelei Fan wrote:
> > The
The padding may be also necessary to prevent from a kind of attacks, besides
hiding the length. But I cannot recall the details.
Removing padding may be not the direction. Instead, a padding length
customizable solution may be more flexible. Here is an enhancement request in
JBS (https://bug
lto:b...@coldbox.org>
> ColdBox Platform: http://www.coldbox.org <http://www.coldbox.org/>
> Blog: http://www.codersrevolution.com <http://www.codersrevolution.com/>
>
>
>
> On Wed, Aug 10, 2022 at 9:36 AM Xuelei Fan <mailto:xuele...@gmail.com>> wrote:
>
> ColdBox Platform: http://www.coldbox.org <http://www.coldbox.org/>
> Blog: http://www.codersrevolution.com <http://www.codersrevolution.com/>
>
>
>
> On Tue, Aug 9, 2022 at 9:05 PM Xuelei Fan <mailto:xuele...@gmail.com>> wrote:
> If we have a look from
If we have a look from the viewpoint of HTTP/2, how applications could meet the
requirements in HTTP/2? Did you have a plan to have the application works with
HTTP/2 in the future?
Xuelei
> On Aug 9, 2022, at 12:29 PM, Brad Wood wrote:
>
> I have some questions about this ticket
> https://
> On Aug 2, 2022, at 2:55 PM, Bradford Wetmore
> wrote:
>
> Hi Xuelei,
>
> Sean wrote:
>
>> I haven't had time to look at this in detail yet. I would like a
>> couple more weeks to review the draft.
>
> We've been looking closely at RFC 8879 and your proposal to add support into
> JSSE. I
it is something that could be contributed to the JDK,
>> or do you suggest this should be taken up as an external provider?
>> From: Ravi Patel8 <mailto:ravi.pat...@ibm.com>
>> Sent: Thursday, July 14, 2022 6:26 PM
>> To: Xuelei Fan <mailto:xuele...@gmail.com&
> On Jul 13, 2022, at 2:20 PM, Michael StJohns wrote:
>
> On 7/13/2022 3:26 PM, Xuelei Fan wrote:
>> Is it possible make it in the application layer? For example, mapping
>> case-sensitive name to case-in-sensitive name before calling into the
>> standard KeyStor
Is it possible make it in the application layer? For example, mapping
case-sensitive name to case-in-sensitive name before calling into the standard
KeyStore APIs. It may be not good to break the standards for corner cases?
Xuelei
> On Jul 13, 2022, at 4:38 AM, Ravi Patel8 wrote:
>
> We hav
27 matches
Mail list logo
