> On 9 May 2025, at 18:42, Tom Lane wrote:
>
> Pushed all that stuff. The SSL tests pass for me now on OpenBSD 7.7,
> and hopefully the CI environment will be happy too.
Thanks!
--
Daniel Gustafsson
Pushed all that stuff. The SSL tests pass for me now on OpenBSD 7.7,
and hopefully the CI environment will be happy too.
regards, tom lane
Daniel Gustafsson writes:
> On 9 May 2025, at 02:15, Tom Lane wrote:
>> Right. I think the attached would be amenable to that.
> It will be a bit awkward to ask "are you libressl" if we ever add support for
> something not OpenSSL based, but we could always revisit should that happen.
I was im
> On 9 May 2025, at 02:15, Tom Lane wrote:
> Daniel Gustafsson writes:
>> If we were to end up with a
>> Libressl libtls implementation in libpq we'd still have to test with Libressl
>> against the OpenSSL compat layer in libssl since it could act as both. Not a
>> bridge we have to cross today
Daniel Gustafsson writes:
> Maybe the ssl_library function should return a hash with backend => 'OpenSSL'
> and library => ?
I don't love doing it exactly like that: seems like it adds notational
complexity for little gain. Also, it forces ssl_library to expend
work detecting things the current
> On 8 May 2025, at 22:24, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> On 8 May 2025, at 15:49, Tom Lane wrote:
>>> I was feeling itchy about having two copies of code that looks none
>>> too set-in-stone. Maybe we should just do that. Any preferences
>>> on the API?
>
>> There is alrea
Daniel Gustafsson writes:
> On 8 May 2025, at 15:49, Tom Lane wrote:
>> I was feeling itchy about having two copies of code that looks none
>> too set-in-stone. Maybe we should just do that. Any preferences
>> on the API?
> There is already SSL::Server::ssl_library() which returns the underlyi
> On 8 May 2025, at 15:49, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> On 7 May 2025, at 23:54, Tom Lane wrote:
>>> +# Determine whether this build uses OpenSSL or LibreSSL. As a heuristic,
>>> the
>>> +# HAVE_SSL_CTX_SET_CERT_CB macro isn't defined for LibreSSL.
>>> +my $libressl = not c
Daniel Gustafsson writes:
> On 7 May 2025, at 23:54, Tom Lane wrote:
>> +# Determine whether this build uses OpenSSL or LibreSSL. As a heuristic, the
>> +# HAVE_SSL_CTX_SET_CERT_CB macro isn't defined for LibreSSL.
>> +my $libressl = not check_pg_config("#define HAVE_SSL_CTX_SET_CERT_CB 1");
> L
> On 7 May 2025, at 23:54, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> I haven't looked at the test in question yet, but we do skip some SSL tests
>> if
>> running against libressl already so I assume this will be able to follow the
>> same pattern.
>
> Ah, thanks for the tip. I propose
Daniel Gustafsson writes:
> I haven't looked at the test in question yet, but we do skip some SSL tests if
> running against libressl already so I assume this will be able to follow the
> same pattern.
Ah, thanks for the tip. I propose the attached, which disables the
RSA-PSS test altogether on
Thomas Munro writes:
> Oh, interesting. I also wondered if the problem I reported might be
> related to the separate legacy code paths in x509_vfy.c.
I poked at this a little more, and apparently the code to look at is
actually in the sibling file x509_verify.c. Here's the backtrace
(in OpenBSD
> On 7 May 2025, at 21:29, Tom Lane wrote:
>
> I filed a report with the LibreSSL folks, and the answer was basically
> "yeah, we know RSA-PSS doesn't work; there are multiple things that
> need fixing" [1]. So it seems like we'd better find a way to skip
> that test case when using LibreSSL. N
I filed a report with the LibreSSL folks, and the answer was basically
"yeah, we know RSA-PSS doesn't work; there are multiple things that
need fixing" [1]. So it seems like we'd better find a way to skip
that test case when using LibreSSL. Not sure what the most
appropriate check would look like
> On 7 May 2025, at 18:04, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 7 May 2025, at 06:34, Tom Lane wrote:
>>> I couldn't help noticing that the backtraces went through
>>> lib/libssl/tls13_legacy.c, which doesn't give a warm feeling
>>> about how supported they think our usage is (a
Daniel Gustafsson writes:
>> On 7 May 2025, at 06:34, Tom Lane wrote:
>> I couldn't help noticing that the backtraces went through
>> lib/libssl/tls13_legacy.c, which doesn't give a warm feeling
>> about how supported they think our usage is (and perhaps also
>> explains why they didn't detect th
> On 7 May 2025, at 06:34, Tom Lane wrote:
>
> Thomas Munro writes:
>> On Wed, May 7, 2025 at 1:18 PM Tom Lane wrote:
>>> Anyone know anything about where to submit LibreSSL bugs?
>
>> I think it's done with sendbug on an OpenBSD box, or perhaps you can
>> just write a normal email to the b...
On Wed, May 7, 2025 at 4:34 PM Tom Lane wrote:
> Thanks, I'll look into reporting it tomorrow. In the meantime,
> I couldn't help noticing that the backtraces went through
> lib/libssl/tls13_legacy.c, which doesn't give a warm feeling
> about how supported they think our usage is (and perhaps als
Thomas Munro writes:
> On Wed, May 7, 2025 at 1:18 PM Tom Lane wrote:
>> Anyone know anything about where to submit LibreSSL bugs?
> I think it's done with sendbug on an OpenBSD box, or perhaps you can
> just write a normal email to the b...@openbsd.org or
> libre...@openbsd.org list, based on:
On Wed, May 7, 2025 at 1:18 PM Tom Lane wrote:
> So it seems like this might be a simple oversight in
> ssl_sigalg_pkey_ok(), which doesn't make any such correction:
>
> if (sigalg->key_type != EVP_PKEY_id(pkey))
> return 0;
Nice detective work.
> Anyone know anything abo
I wrote:
> Yeah, I see that too. But I also see three failures in 002_scram.pl,
> which presumably were there before e0f373ee. (Tested on OpenBSD 7.6
> and 7.7.) The buildfarm's OpenBSD animals haven't caught this
> because they don't run this test suite :-(.
I dug into this with gdb, and it se
Thomas Munro writes:
> If you run the not-yet-enabled-by-default OpenBSD CI task on master,
> ssl/001_ssltests fails in "intermediate client certificate is
> untrusted", recently uncommented by commit e0f373ee.
Yeah, I see that too. But I also see three failures in 002_scram.pl,
which presumably
If you run the not-yet-enabled-by-default OpenBSD CI task on master,
ssl/001_ssltests fails in "intermediate client certificate is
untrusted", recently uncommented by commit e0f373ee. I think it might
be telling us that LibreSSL's x509_store_ctx_get_current_cert() is
giving us the client certifica
I wrote:
> The fact that mamba hasn't been failing on the other affected
> tests is a bit puzzling. mamba isn't running kerberos or ldap
> or oauth_validator, so the lack of failures there is expected.
> authentication/t/001_password.pl appears accidentally not vulnerable:
> it's not using log_lik
Andrew Dunstan writes:
> On 2025-04-18 Fr 7:26 PM, Tom Lane wrote:
> +See C. CAUTION: use of either option requires that
> +the server's log_min_messages be at least DEBUG2, and that no other
> +client backend is launched concurrently. These requirements allow
> +C to wait to see the postmaster-
On 2025-04-18 Fr 7:26 PM, Tom Lane wrote:
I wrote:
What I think happened here is that a previous backend hadn't exited
yet when we start the test, and when its report does come out,
connect_fails prematurely stops waiting. (In the above, evidently
the child process we want to wait for is 599,
I wrote:
> What I think happened here is that a previous backend hadn't exited
> yet when we start the test, and when its report does come out,
> connect_fails prematurely stops waiting. (In the above, evidently
> the child process we want to wait for is 599, but we're fooled by
> a delayed report
I wrote:
> * I was more than slightly surprised to find that there are a bunch of
> other connect_fails callers that are testing log_like or log_unlike
> and thereby risking the same type of race condition. Some of those
> tests are relatively new and perhaps just haven't failed *yet*,
> but I won
On Fri, Apr 18, 2025 at 12:46 PM Tom Lane wrote:
> * The commented-out tests in 001_ssltests.pl contained hard-wired
> expectations as to certificate serial numbers, which are obsolete now.
> I just replaced them with "\d+", but if anyone feels like that's not
> good enough, we could continue to c
Andrew Dunstan writes:
> On 2025-04-17 Th 10:56 AM, Tom Lane wrote:
>> However, I wonder whether Andres' work at 8b886a4e3 could be used
>> to improve this, either directly or as inspiration?
> I don't think so - these tests are about checking log file contents, not
> a psql problem.
Well, I wa
On 2025-04-17 Th 10:56 AM, Tom Lane wrote:
Andrew Dunstan writes:
Back in 2022 in commit 55828a6b6084 we disabled a bunch of tests due to
a timing issue. Nothing seems to have been done since ... do we still
want to keep these commented out lines around? This "temporary" fix
seems to have str
Andrew Dunstan writes:
> Back in 2022 in commit 55828a6b6084 we disabled a bunch of tests due to
> a timing issue. Nothing seems to have been done since ... do we still
> want to keep these commented out lines around? This "temporary" fix
> seems to have stretched the definition of that term mo
32 matches
Mail list logo
