On 25.07.24 11:36, Daniel Gustafsson wrote:
On 24 Jul 2024, at 15:32, Peter Eisentraut wrote:
On 25.06.24 16:21, Tom Lane wrote:
Peter Eisentraut writes:
On 21.06.24 16:53, Tom Lane wrote:
Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
portability. Is that relevant here?
L
> On 24 Jul 2024, at 15:32, Peter Eisentraut wrote:
>
> On 25.06.24 16:21, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> On 21.06.24 16:53, Tom Lane wrote:
Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
portability. Is that relevant here?
>>> Looking inside the OpenS
On 25.06.24 16:21, Tom Lane wrote:
Peter Eisentraut writes:
On 21.06.24 16:53, Tom Lane wrote:
Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
portability. Is that relevant here?
Looking inside the OpenSSL code, it makes no efforts to translate
between winsock error codes an
Peter Eisentraut writes:
> On 21.06.24 16:53, Tom Lane wrote:
>> Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
>> portability. Is that relevant here?
> Looking inside the OpenSSL code, it makes no efforts to translate
> between winsock error codes and standard error codes, so I
On 21.06.24 16:53, Tom Lane wrote:
Peter Eisentraut writes:
- strlcpy(errbuf, strerror(ERR_GET_REASON(ecode)), SSL_ERR_LEN);
+ strerror_r(ERR_GET_REASON(ecode), errbuf, SSL_ERR_LEN);
Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
portability. Is that relevant here
Peter Eisentraut writes:
> - strlcpy(errbuf, strerror(ERR_GET_REASON(ecode)), SSL_ERR_LEN);
> + strerror_r(ERR_GET_REASON(ecode), errbuf, SSL_ERR_LEN);
Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
portability. Is that relevant here?
regards,
> On 21 Jun 2024, at 13:15, Peter Eisentraut wrote:
> I noticed that this change uses not-thread-safe strerror() in libpq code.
>
> Perhaps something like this would be better (and simpler):
Nice catch, LGTM.
--
Daniel Gustafsson
On 08.03.24 01:46, Tom Lane wrote:
Daniel Gustafsson writes:
On 7 Mar 2024, at 20:58, Tom Lane wrote:
This could probably do with a comment, and we need to propagate
the fix into libpq's copy of the function too. Barring objections,
I'll take care of that and push it later today.
LGTM.
Daniel Gustafsson writes:
> On 7 Mar 2024, at 20:58, Tom Lane wrote:
>> This could probably do with a comment, and we need to propagate
>> the fix into libpq's copy of the function too. Barring objections,
>> I'll take care of that and push it later today.
> LGTM.
Done so far as be-secure-open
> On 7 Mar 2024, at 20:58, Tom Lane wrote:
>
> I wrote:
>> Stephen Frost writes:
>>> Agreed that it doesn't seem well documented. I was trying to figure out
>>> what the 'right' answer here was myself and not having much success. If
>>> the above works, then +1 to that.
>
>> My reaction as we
I wrote:
> Stephen Frost writes:
>> Agreed that it doesn't seem well documented. I was trying to figure out
>> what the 'right' answer here was myself and not having much success. If
>> the above works, then +1 to that.
> My reaction as well --- I was just gearing up to test this idea,
> unless
David Zhang writes:
> When configuring SSL on the Postgres server side with the following
> information:
> ssl = on
> ssl_ca_file = 'root_ca.crt'
> ssl_cert_file = 'server-cn-only.crt'
> ssl_key_file = 'server-cn-only.key'
> If a user makes a mistake, for example, accidentally using 'root_ca.cr
Stephen Frost writes:
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> That's pretty unfortunate. As typical with OpenSSL, this stuff is not very
>> well documented, but I think we could do something like this in
>> SSLerrmessage():
>>
>> if (ERR_SYSTEM_ERROR(e))
>> errreason = strerror(ERR_GET
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 07/03/2024 02:12, David Zhang wrote:
> > The SSL_CTX_load_verify_locations function in OpenSSL will return NULL
> > if there is a system error, such as "No such file or directory" in this
> > case:
> >
> > const char *ERR_reason_error_
On 07/03/2024 02:12, David Zhang wrote:
The SSL_CTX_load_verify_locations function in OpenSSL will return NULL
if there is a system error, such as "No such file or directory" in this
case:
const char *ERR_reason_error_string(unsigned long e)
{
ERR_STRING_DATA d, *p = NULL;
unsigned l
Hi Hackers,
When configuring SSL on the Postgres server side with the following
information:
ssl = on
ssl_ca_file = 'root_ca.crt'
ssl_cert_file = 'server-cn-only.crt'
ssl_key_file = 'server-cn-only.key'
If a user makes a mistake, for example, accidentally using 'root_ca.crl'
instead of 'root
16 matches
Mail list logo
