On 29/01/2019 13:11, Peter Eisentraut wrote:
> On 29/01/2019 04:18, Kyotaro HORIGUCHI wrote:
>> Some further investigation told me that the file
>> ~/.postgresql/root.cert was the culprit.
>
> OK, I could reproduce the problem and found a fix for it. Basically you
> need to specify sslrootcert in
At Tue, 29 Jan 2019 13:50:17 +0900, Michael Paquier wrote
in <20190129045017.gc3...@paquier.xyz>
> On Tue, Jan 29, 2019 at 12:18:29PM +0900, Kyotaro HORIGUCHI wrote:
> > At Mon, 28 Jan 2019 14:53:43 +0100, Peter Eisentraut
> > wrote in
> > <24783370-5acd-e0f3-8eb7-7f42ff2a0...@2ndquadrant.com>
On 29/01/2019 04:18, Kyotaro HORIGUCHI wrote:
> Some further investigation told me that the file
> ~/.postgresql/root.cert was the culprit.
OK, I could reproduce the problem and found a fix for it. Basically you
need to specify sslrootcert in each test, and these new tests didn't do
it. All othe
On Tue, Jan 29, 2019 at 12:18:29PM +0900, Kyotaro HORIGUCHI wrote:
> At Mon, 28 Jan 2019 14:53:43 +0100, Peter Eisentraut
> wrote in
> <24783370-5acd-e0f3-8eb7-7f42ff2a0...@2ndquadrant.com>
>> This is strange. The tests work for me, and also on the cfbot. The
>
> Agreed. It seemed so also to
At Mon, 28 Jan 2019 14:53:43 +0100, Peter Eisentraut
wrote in
<24783370-5acd-e0f3-8eb7-7f42ff2a0...@2ndquadrant.com>
> On 28/01/2019 09:14, Kyotaro HORIGUCHI wrote:
> > 0002:
> >
> > The test 54-56 of 001_ssltest.pl failed, which succeeded before
> > applying 0002. Seems to need to use anothe
On 28/01/2019 09:14, Kyotaro HORIGUCHI wrote:
> 0002:
>
> The test 54-56 of 001_ssltest.pl failed, which succeeded before
> applying 0002. Seems to need to use another user.
>
> # Failed test 'pg_stat_ssl view without client certificate: no stderr'
> # at t/001_ssltests.pl line 313.
> #
Sorry, I left a garbage.
At Mon, 28 Jan 2019 17:14:00 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190128.171400.111796002.horiguchi.kyot...@lab.ntt.co.jp>
> Hello, thank you for the new version.
>
> At Fri, 4 Jan 2019 00:25:57 +0100, Peter Eisentraut
> wrote in
> <3f8a7a73-ce
Hello, thank you for the new version.
At Fri, 4 Jan 2019 00:25:57 +0100, Peter Eisentraut
wrote in
<3f8a7a73-cebe-016f-49e3-853733f8b...@2ndquadrant.com>
> Updated patches for some merge conflicts
0001: Seems perfect to me.
0002:
The test 54-56 of 001_ssltest.pl failed, which succeeded befo
Updated patches for some merge conflicts
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 296d8d19cc49c2e7a6e8489a6d21cd6a182f2686 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 2 Oct 2018 12:17:22
Updated patch with the renamed columns.
On 29/11/2018 14:49, Peter Eisentraut wrote:
> On 29/11/2018 01:27, Lou Picciano wrote:
>> Further, I’m not sure exposing details about Cert Issuer, etc. to
>> non-privileged users is much of an issue. For the most part, in most use
>> cases, ‘users’ should
On 29/11/2018 01:27, Lou Picciano wrote:
> Further, I’m not sure exposing details about Cert Issuer, etc. to
> non-privileged users is much of an issue. For the most part, in most use
> cases, ‘users’ should//would/ want to know what entity is the issuer. If
> we’re talking about client certs, most
As we do make significant(?) use of the ssl-ish stuff - though not of the views
- should I weigh in?
We do make some not-insignificant use of the sslinfo data, but I see little
issue with adding underscores. In fact, ssl-ville is replete with underscores
anyway.
Further, I’m not sure exposing
Bruce Momjian writes:
> On Wed, Nov 28, 2018 at 06:31:59PM +0100, Peter Eisentraut wrote:
>> Any thoughts from others about whether to rename clientdn to client_dn
>> to allow better naming of the new fields?
> Makes sense. The SSL acronyms can get very complex.
+1. It seems unlikely to me tha
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Nov 28, 2018 at 06:31:59PM +0100, Peter Eisentraut wrote:
> > On 20/11/2018 22:41, Peter Eisentraut wrote:
> > >>> - Adds new fields to pg_stat_ssl: issuerdn and clientserial. These
> > >>> allow uniquely identifying the client certif
On Wed, Nov 28, 2018 at 06:31:59PM +0100, Peter Eisentraut wrote:
> On 20/11/2018 22:41, Peter Eisentraut wrote:
> >>> - Adds new fields to pg_stat_ssl: issuerdn and clientserial. These
> >>> allow uniquely identifying the client certificate. AFAICT, these are
> >>> the most interesting pieces of
On 20/11/2018 22:41, Peter Eisentraut wrote:
>>> - Adds new fields to pg_stat_ssl: issuerdn and clientserial. These
>>> allow uniquely identifying the client certificate. AFAICT, these are
>>> the most interesting pieces of information provided by sslinfo but not
>>> in pg_stat_ssl. (I don't lik
On 27/11/2018 00:29, Thomas Munro wrote:
> On Thu, Oct 18, 2018 at 11:05 AM Peter Eisentraut
> wrote:
>> - Adds tests under src/test/ssl/ for the pg_stat_ssl view.
>
> Hi Peter,
>
> Your new tests fail when run by cfbot (Ubuntu), and also on my Debian
> buster machine, but pass on my FreeBSD 13-
On Thu, Oct 18, 2018 at 11:05 AM Peter Eisentraut
wrote:
> - Adds tests under src/test/ssl/ for the pg_stat_ssl view.
Hi Peter,
Your new tests fail when run by cfbot (Ubuntu), and also on my Debian
buster machine, but pass on my FreeBSD 13-CURRENT box. I think the
problem is that you match ciph
On 20/11/2018 09:31, Kyotaro HORIGUCHI wrote:
> Comparing the two codes in pgstatfuncs.c and sslinfo.c, It seems
> that ssl_client_serial() can be largely simplified using
> be_tls_get_peer_serial(). X509_NAME_to_text() can be simplified
> using X509_NAME_to_cstring(). But this would be another pat
Hello.
At Thu, 18 Oct 2018 00:05:15 +0200, Peter Eisentraut
wrote in
<398754d8-6bb5-c5cf-e7b8-22e5f0983...@2ndquadrant.com>
> During discussions of alternative SSL implementations, contrib/sslinfo
> is usually mentioned as something that something needs to be done about.
> I've looked into ada
During discussions of alternative SSL implementations, contrib/sslinfo
is usually mentioned as something that something needs to be done about.
I've looked into adapting some functionality from sslinfo into the
pg_stat_ssl view. These two facilities have a lot of overlap but seem
mostly oblivious
21 matches
Mail list logo
