On Fri, 2022-04-01 at 16:07 +0200, Peter Eisentraut wrote:
> I have committed this.
>
> I have removed the inet header refactoring that you had. That wasn't
> necessary, since pg_inet_net_ntop() can use the normal AF_INET*
> constants. The PGSQL_AF_INET* constants are only for the internal
> sto
On 31.03.22 20:15, Jacob Champion wrote:
On Thu, 2022-03-31 at 16:32 +0200, Peter Eisentraut wrote:
Why add a (failry complicated) pg_inet_pton() when a perfectly
reasonable inet_pton() exists?
I think it was mostly just that inet_aton() and pg_inet_net_ntop() both
had ports, and I figured I m
On Thu, 2022-03-31 at 16:32 +0200, Peter Eisentraut wrote:
> Why add a (failry complicated) pg_inet_pton() when a perfectly
> reasonable inet_pton() exists?
I think it was mostly just that inet_aton() and pg_inet_net_ntop() both
had ports, and I figured I might as well port the other one since we
On 30.03.22 18:17, Jacob Champion wrote:
Also, if someone ever
wants to change how those backend data types work, we then have to check
a bunch of other code as well.
I think we should be using inet_ntop()/inet_pton() directly here. We
can throw substitute implementations into libpgport if nece
On Wed, 2022-03-30 at 13:37 +0200, Peter Eisentraut wrote:
> On 28.03.22 22:21, Jacob Champion wrote:
> > On Mon, 2022-03-28 at 11:17 +0200, Daniel Gustafsson wrote:
> > > Fixing up the switch_server_cert() calls and using default_ssl_connstr
> > > makes
> > > the test pass for me. The required f
On 28.03.22 22:21, Jacob Champion wrote:
On Mon, 2022-03-28 at 11:17 +0200, Daniel Gustafsson wrote:
Fixing up the switch_server_cert() calls and using default_ssl_connstr makes
the test pass for me. The required fixes are in the supplied 0004 diff, I kept
them separate to allow the original au
On Mon, 2022-03-28 at 11:17 +0200, Daniel Gustafsson wrote:
> Fixing up the switch_server_cert() calls and using default_ssl_connstr makes
> the test pass for me. The required fixes are in the supplied 0004 diff, I
> kept
> them separate to allow the original author to incorporate them without ha
On Mon, 28 Mar 2022 at 05:17, Daniel Gustafsson wrote:
>
> named to match the git format-patch output
> since I think the CFBot just applies the patches in alphabetical order).
The first patch doesn't seem to actually apply though so it doesn't
get to the subsequent patches.
http://cfbot.cputube
> On 28 Mar 2022, at 00:44, Daniel Gustafsson wrote:
> I'll take a look at fixing up the test in this patch tomorrow.
Fixing up the switch_server_cert() calls and using default_ssl_connstr makes
the test pass for me. The required fixes are in the supplied 0004 diff, I kept
them separate to allo
Hi,
On 2022-03-27 17:19:27 -0400, Tom Lane wrote:
> The cfbot doesn't provide a lot of evidence about
> why it's failing, but I applied the patchset locally and what
> I see is
FWIW - and I agree that's not nice user interface wise - just below the cpu /
memory graphs there's a "directory browser
> On 27 Mar 2022, at 23:19, Tom Lane wrote:
> This may be caused by 9ca234bae or 4a7e964fc.
I'd say 4a7e964fc is the culprit here. From a quick skim the the
switch_server_cert() calls need to be changed along the lines of:
from: switch_server_cert($node, 'server-ip-in-dnsname');
to: swi
Jacob Champion writes:
> [ v10-0001-Move-inet_net_pton-to-src-port.patch etc ]
There is something broken about the ssl tests as modified by
this patch. The cfbot doesn't provide a lot of evidence about
why it's failing, but I applied the patchset locally and what
I see is
...
ok 47 - mismatch b
On Thu, 2022-03-24 at 17:10 +0900, Kyotaro Horiguchi wrote:
> I'm fine with it. Thanks. I marked it as Ready-for-Commiter.
Thank you for the reviews and feedback!
--Jacob
At Wed, 23 Mar 2022 23:52:06 +, Jacob Champion wrote
in
> On Wed, 2022-03-23 at 14:20 +0900, Kyotaro Horiguchi wrote:
> > I tried to write out the doc part. What do you think about it?
>
> I like it, thanks! I've applied that in v10, with a tweak to two
> iPAddress spellings and a short ex
On Wed, 2022-03-23 at 14:20 +0900, Kyotaro Horiguchi wrote:
> I tried to write out the doc part. What do you think about it?
I like it, thanks! I've applied that in v10, with a tweak to two
iPAddress spellings and a short expansion of the condition in the Note,
and I've added you as a co-author t
At Tue, 22 Mar 2022 20:42:37 +, Jacob Champion wrote
in
> Thanks, looks like I had some old header dependencies left over from
> several versions ago. Fixed in v9.
Thanks! Looks perfect.
> v9 contains the bare minimum but I don't think it's quite enough. How
> much of the behavior (and ed
On Tue, 2022-03-22 at 13:32 +0900, Kyotaro Horiguchi wrote:
> At Fri, 18 Mar 2022 16:38:57 +0900 (JST), Kyotaro Horiguchi
> wrote in
> >
> > fe-secure-common.c doesn't need netinet/in.h.
> >
> >
> > +++ b/src/include/utils/inet.h
> > ..
> > +#include "common/inet-common.h"
> >
> > I'm not sur
At Fri, 18 Mar 2022 16:38:57 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 17 Mar 2022 21:55:07 +, Jacob Champion
> wrot> Thanks! .. and some nitpicks..(Sorry)
>
> fe-secure-common.c doesn't need netinet/in.h.
>
>
> +++ b/src/include/utils/inet.h
> ..
> +#include "common/inet-comm
At Thu, 17 Mar 2022 21:55:07 +, Jacob Champion wrote
in
> On Wed, 2022-03-16 at 23:49 +, Jacob Champion wrote:
> > Thank you for the explanation -- the misunderstanding was all on my
> > end. I thought you were asking me to move the check_cn assignment
> > instead of copying it to the en
On Wed, 2022-03-16 at 23:49 +, Jacob Champion wrote:
> Thank you for the explanation -- the misunderstanding was all on my
> end. I thought you were asking me to move the check_cn assignment
> instead of copying it to the end. I agree that your suggestion is much
> clearer, and I'll make that c
On Wed, 2022-03-16 at 15:56 +0900, Kyotaro Horiguchi wrote:
> At Tue, 15 Mar 2022 21:41:49 +, Jacob Champion
> wrote in
> > Hmm, the sslinfo tests are failing? I wouldn't have expected that based
> > on the patch changes. Just to confirm -- they pass for you without the
> > patch?
>
> Mmm..
At Wed, 16 Mar 2022 15:56:02 +0900 (JST), Kyotaro Horiguchi
wrote in
> Mmm I'm not sure how come I didn't noticed that, master also fails
> for me fo the same reason. In the past that may fail when valid
> clinent-certs exists in the users ~/.postgresql but I believe that has
> been fixed.
At Tue, 15 Mar 2022 21:41:49 +, Jacob Champion wrote
in
> On Mon, 2022-03-14 at 15:30 +0900, Kyotaro Horiguchi wrote:
> > t/003_sslinfo.pl ... 1/? # Tests were run but no plan was declared and
> > done_testing() was not seen.
> > # Looks like your test exited with 29 just after 6.
> > t/003
On Tue, 2022-03-15 at 21:41 +, Jacob Champion wrote:
> Sounds good. I'll work on adding tests for the current behavior, and if
> the committers don't like it, we can change it.
Done in v7, attached.
--Jacob
commit 51052e322f4d4e4f75d3cf3d000a363244696013
Author: Jacob Champion
Date: Tue Ma
On Mon, 2022-03-14 at 15:30 +0900, Kyotaro Horiguchi wrote:
> t/003_sslinfo.pl ... 1/? # Tests were run but no plan was declared and
> done_testing() was not seen.
> # Looks like your test exited with 29 just after 6.
> t/003_sslinfo.pl ... Dubious, test returned 29 (wstat 7424, 0x1d00)
> All 6 su
At Thu, 17 Feb 2022 17:29:15 +, Jacob Champion wrote
in
> On Tue, 2022-02-15 at 15:16 +0900, Kyotaro Horiguchi wrote:
> > (This needs rebasing)
>
> Done in v6, attached.
Thanks!
> > # I forgot to mention that, the test fails for me even without the
> > # change. I didn't checked what is
On Tue, 2022-02-15 at 15:16 +0900, Kyotaro Horiguchi wrote:
> (This needs rebasing)
Done in v6, attached.
> # I forgot to mention that, the test fails for me even without the
> # change. I didn't checked what is wrong there, though.
Ah. We should probably figure that out, then -- what failures
(This needs rebasing)
At Wed, 9 Feb 2022 00:52:48 +, Jacob Champion wrote
in
> On Mon, 2022-02-07 at 17:29 +0900, Kyotaro Horiguchi wrote:
> > I feel this should be a part of 0001. (But the patches will be
> > finally merged so maybe no need to bother moving it).
>
> Okay. I can move it e
On Mon, 2022-02-07 at 17:29 +0900, Kyotaro Horiguchi wrote:
> At Fri, 4 Feb 2022 17:06:53 +, Jacob Champion
> wrote in
> > That works a lot better than what I had in my head. Done that way in
> > v4. Thanks!
>
> Thanks!
>
> 0002:
>
> +#define PGSQL_AF_INET (AF_INET + 0)
> +#define PGSQL_
At Fri, 4 Feb 2022 17:06:53 +, Jacob Champion wrote
in
> That works a lot better than what I had in my head. Done that way in
> v4. Thanks!
Thanks!
0002:
+#define PGSQL_AF_INET (AF_INET + 0)
+#define PGSQL_AF_INET6 (AF_INET + 1)
..
-#define PGSQL_AF_INET (AF_INET + 0)
-#define PGSQL_AF_
On Thu, 2022-02-03 at 16:23 +0900, Kyotaro Horiguchi wrote:
> At Wed, 2 Feb 2022 19:46:13 +, Jacob Champion
> wrote in
> > On Mon, 2022-01-31 at 17:29 +0900, Kyotaro Horiguchi wrote:
> > > +#define PGSQL_AF_INET (AF_INET + 0)
> > > +#define PGSQL_AF_INET6 (AF_INET + 1)
> > > +
> > >
> > >
At Wed, 2 Feb 2022 19:46:13 +, Jacob Champion wrote
in
> On Mon, 2022-01-31 at 17:29 +0900, Kyotaro Horiguchi wrote:
> > +#define PGSQL_AF_INET (AF_INET + 0)
> > +#define PGSQL_AF_INET6 (AF_INET + 1)
> > +
> >
> > Now we have the same definition thrice in frontend code. Coulnd't we
> > def
On Mon, 2022-01-31 at 17:29 +0900, Kyotaro Horiguchi wrote:
> However, 0002,
>
> +/*
> + * In a frontend build, we can't include inet.h, but we still need to have
> + * sensible definitions of these two constants. Note that pg_inet_net_ntop()
> + * assumes that PGSQL_AF_INET is equal to AF_INET.
At Thu, 6 Jan 2022 00:02:27 +, Jacob Champion wrote
in
> On Mon, 2022-01-03 at 16:19 +, Jacob Champion wrote:
> > On Fri, 2021-12-17 at 15:40 +0900, Kyotaro Horiguchi wrote:
> > >
> > > + inet_net_pton_ipv4(const char *src, u_char *dst)
> > > (calls inet_net_pton_ipv4_internal(src, dst
On Mon, 2022-01-03 at 16:19 +, Jacob Champion wrote:
> On Fri, 2021-12-17 at 15:40 +0900, Kyotaro Horiguchi wrote:
> >
> > + inet_net_pton_ipv4(const char *src, u_char *dst)
> > (calls inet_net_pton_ipv4_internal(src, dst, true))
> > + inet_pton_ipv4(const char *src, u_char *dst)
> > (calls
On Thu, 2021-12-16 at 18:44 +, Jacob Champion wrote:
> It sounds like both you and Andrew might be comfortable with that same
> behavior? I think it looks like a sane solution, so I'll implement that
> and we can see what it looks like. (My work on this will be paused over
> the end-of-year hol
On Sun, 2022-01-02 at 13:29 -0800, Andres Freund wrote:
> Hi,
>
> On 2021-12-16 01:13:57 +, Jacob Champion wrote:
> > Attached is a patch for libpq to support IP addresses in the server's
> > Subject Alternative Names, which would allow admins to issue certs for
> > multiple IP addresses, both
On Fri, 2021-12-17 at 16:54 +0900, Kyotaro Horiguchi wrote:
> Sorry for the silly mistake.
>
> At Fri, 17 Dec 2021 15:40:10 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > > NSS departs slightly from the spec and will additionally try to match
> > > an IP address against the CN, but only if there
Hi,
On 2021-12-16 01:13:57 +, Jacob Champion wrote:
> Attached is a patch for libpq to support IP addresses in the server's
> Subject Alternative Names, which would allow admins to issue certs for
> multiple IP addresses, both IPv4 and IPv6, and mix them with
> alternative DNS hostnames. These
Sorry for the silly mistake.
At Fri, 17 Dec 2021 15:40:10 +0900 (JST), Kyotaro Horiguchi
wrote in
> > NSS departs slightly from the spec and will additionally try to match
> > an IP address against the CN, but only if there are no iPAddresses in
> > the SAN. It roughly matches the logic for DNS
At Thu, 16 Dec 2021 18:44:54 +, Jacob Champion wrote
in
> On Thu, 2021-12-16 at 14:54 +0900, Kyotaro Horiguchi wrote:
> > It seems like saying that we must search for iPAddress and mustn't use
> > CN nor dNSName if the client connected using IP address. Otherwise, if
> > the host name is a d
On Thu, 2021-12-16 at 10:50 -0500, Andrew Dunstan wrote:
> Good job, this is certainly going to be useful.
Thanks!
> I don't think we should fall back on the CN. It would seem quite odd to
> do so for IP addresses but not for DNS names.
So there's at least one compatibility concern with disablin
On Thu, 2021-12-16 at 14:54 +0900, Kyotaro Horiguchi wrote:
> In RFC2828 and 6125,
>
> > In some cases, the URI is specified as an IP address rather than a
> > hostname. In this case, the iPAddress subjectAltName must be present
> > in the certificate and must exactly match the IP in the UR
On 12/15/21 20:13, Jacob Champion wrote:
> Hello all,
>
> libpq currently supports server certificates with a single IP address
> in the Common Name. It's fairly brittle; as far as I can tell, the
> single name you choose has to match the client's address exactly.
>
> Attached is a patch for libp
At Thu, 16 Dec 2021 01:13:57 +, Jacob Champion wrote
in
> This patch arose because I was writing tests for the NSS implementation
> that used a server cert with both DNS names and IP addresses, and then
> they failed when I ran those tests against the OpenSSL implementation.
> NSS supports t
45 matches
Mail list logo
