On Fri, Oct 31, 2025 at 10:26:01AM +0100, Filip Janus wrote:
> While fixing the actual issue will take some time, I’ve fixed the requested
> test.
> Since I’m still quite new to the PG community, would it make sense to
> propose a patch that only adds the test?
Yes, we could add a test that tracks
On Fri, Oct 31, 2025 at 2:26 AM Filip Janus wrote:
> While fixing the actual issue will take some time, I’ve fixed the requested
> test.
> Since I’m still quite new to the PG community, would it make sense to propose
> a patch that only adds the test?
You mean like in a TODO: block in the test?
út 28. 10. 2025 v 6:55 odesílatel Michael Paquier
napsal:
> On Sun, Oct 26, 2025 at 11:20:53AM +0100, Filip Janus wrote:
> > I have prepared a test case following the pattern from commit
> 9244c11afe23
> > (RSA-PSS fix).
>
> Thanks, I'm able to reproduce your problem with the error you have,
> af
On Thu, Oct 30, 2025 at 11:39:38AM +0100, Filip Janus wrote:
> Thank you for posting it there. If I understand correctly, the resolution
> should be to use internal hash algorithms — in this case, SHAKE.
In this case, yes, it seem the consensus (though it's early to call it)
is SHAKE256.
> Now, t
Thank you for posting it there. If I understand correctly, the resolution
should be to use internal hash algorithms — in this case, SHAKE.
Now, the question is whether to wait for the implementation of a public API
to make the change as general as possible, or to try implementing it on the
PG side?
I posted (including your attachment, by accident, since at first I was
going to forward your post) about this to the IETF TLS WG mailing list.
https://mailarchive.ietf.org/arch/msg/tls/CEaZg1l-4iVg0_wdEr5_rXfGYWc/
On Mon, Oct 20, 2025 at 09:12:52AM +0200, Filip Janus wrote:
> The problem is caused by a difference between the currently used algorithms
> and post-quantum ones. For example, commonly used algorithms like RSA have
> a defined digest algorithm, but ML-DSA does not.
Looking more carefully, ML-DSA
On Tue, Oct 28, 2025 at 10:34:27AM -0700, Jacob Champion wrote:
> On Tue, Oct 28, 2025 at 9:46 AM Nico Williams wrote:
>> RFC 5929 co-author here. We should take this to the IETF TLS WG mailing
>> list and update RFC 5929 and the tls-server-end-point registraion to fix
>> this.
Wow. Thanks Nico
On Tue, Oct 28, 2025 at 9:46 AM Nico Williams wrote:
> RFC 5929 co-author here. We should take this to the IETF TLS WG mailing
> list and update RFC 5929 and the tls-server-end-point registraion to fix
> this.
>
> Options in the case that the certificate's signature algorithm does not
> have a di
On Mon, Oct 20, 2025 at 05:06:12PM +0900, Michael Paquier wrote:
> On Mon, Oct 20, 2025 at 09:12:52AM +0200, Filip Janus wrote:
> > The problem is caused by a difference between the currently used algorithms
> > and post-quantum ones. For example, commonly used algorithms like RSA have
> > a define
On Mon, Oct 27, 2025 at 10:55 PM Michael Paquier wrote:
> Another thing that bugs me is that this patch would force sha-256 for
> everything, without at least checks based on NID_ML_DSA_44,
> NID_ML_DSA_65 or NID_ML_DSA_87. That may be more flexible, but I'm
> wondering if it could become a probl
On Sun, Oct 26, 2025 at 11:20:53AM +0100, Filip Janus wrote:
> I have prepared a test case following the pattern from commit 9244c11afe23
> (RSA-PSS fix).
Thanks, I'm able to reproduce your problem with the error you have,
after generating the certs.
+ my $mldsa_cert = "ssl/server-mldsa65.crt";
Hi,
Thank you for the detailed feedback. Let me address your points:
Test Case
=
I have prepared a test case following the pattern from commit 9244c11afe23
(RSA-PSS fix).
Regarding the Hash Algorithm
=
You are correct that, according to RFC 5929, we should i
On Mon, Oct 20, 2025 at 09:12:52AM +0200, Filip Janus wrote:
> The problem is caused by a difference between the currently used algorithms
> and post-quantum ones. For example, commonly used algorithms like RSA have
> a defined digest algorithm, but ML-DSA does not.
>
> PostgreSQL's channel bindin
14 matches
Mail list logo
