On Mon, 2022-02-21 at 11:42 +0100, Peter Eisentraut wrote:
> On 15.02.22 00:07, Jacob Champion wrote:
> > After this patch, bad padding is no longer ignored during decryption,
> > and encryption without padding now requires the input size to be a
> > multiple of the b
On Wed, 2022-02-23 at 16:28 +0100, Gunnar "Nick" Bluth wrote:
> I'm extremely unhappy that I called it "--config-file" here, while
> "postgres" itself wants "--config_file". But as the other dashed options
> of pg_rewind are, well, dashed and not underscored, it seemed to be
> better that the ot
a simple test alongside that?
Thanks,
--Jacob
[1]
https://www.postgresql.org/message-id/a1798e46d6d801344ebc93672c6947ef5297c8a0.camel%40vmware.com
From a5e5549ccec9c70a510f031a678e9f0f32a35382 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 29 Nov 2021 14:36:38 -0800
Subject: [PATCH 1/
On Wed, 2022-02-23 at 14:11 -0500, Andrew Dunstan wrote:
> On 2/23/22 13:38, Jacob Champion wrote:
> >
> > If this looks good, I'm not sure how best to test it in the regression
> > suite. I see that libpq has an installcheck recipe that compiles a test
> > exec
ks,
--Jacob
[1]
https://www.postgresql.org/message-id/CAOuzzgpFpuroNRabEvB9kST_TSyS2jFicBNoXvW7G2pZFixyBw%40mail.gmail.com
From 155a490d28cecf161d994e6d8824cbe967f4d469 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 14 Feb 2022 08:10:53 -0800
Subject: [PATCH] Add APIs to retrieve authn_id from
On Thu, 2022-02-24 at 20:39 +0900, Michael Paquier wrote:
> I don't quite see the additional value that this API brings as
> MyProcPort is directly accessible, and contrib modules like
> postgres_fdw and sslinfo just use that to find the data of the current
> backend.
Right -- I just didn't know i
On Thu, 2022-02-24 at 08:46 -0800, Andres Freund wrote:
> One annoying bit is that our current tap invocation infrastructure for msvc
> won't know how to deal with that. We put the build directory containing t/
> onto PATH, but that won't work for test/. But we also don't want to install
> test bin
On Fri, 2022-02-25 at 01:15 +0800, Julien Rouhaud wrote:
> On Thu, Feb 24, 2022 at 04:50:59PM +0000, Jacob Champion wrote:
> > On Thu, 2022-02-24 at 20:39 +0900, Michael Paquier wrote:
> > > I don't quite see the additional value that this API brings as
> > > MyProc
On Thu, 2022-02-24 at 20:44 +, Jacob Champion wrote:
> That simplifies things. PFA a smaller v2; if pgaudit can't make use of
> libpq-be.h for some reason, then I guess we can tailor a fix to that
> use case.
Ha, opr_sanity caught my use of cstring. I'll work on a fix later
today.
--Jacob
On Fri, 2022-02-25 at 09:43 -0500, Andrew Dunstan wrote:
> AIUI TAP consumers are supposed to ignore lines they don't understand.
It's undefined behavior [1]:
> Any output that is not a version, a plan, a test line, a YAML block,
> a diagnostic or a bail out is incorrect. How a harness handles th
On Fri, 2022-02-25 at 16:35 +, Jacob Champion wrote:
> On Fri, 2022-02-25 at 09:43 -0500, Andrew Dunstan wrote:
> > AIUI TAP consumers are supposed to ignore lines they don't understand.
>
> It's undefined behavior [1]:
And of course the minute I send this I notice
On Fri, 2022-02-25 at 13:40 -0500, Jonathan S. Katz wrote:
> I'm generally in favor of being able to support additional
> authentication methods, the first one coming to mind is supporting OIDC.
> Having a pluggable auth infrastructure could possibly make such efforts
> easier. I'm definitely in
On Fri, 2022-02-25 at 16:28 +, Jacob Champion wrote:
> Ha, opr_sanity caught my use of cstring. I'll work on a fix later
> today.
Fixed in v3.
--Jacob
From 2fde60a6bc3739f1894c8c264120e4fa0f04df64 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 14 Feb 2022 08:10:53 -0
a duplicate.
It was easy enough to add, so I added it. I suppose it does protect
against any reimplementations of pg_session_authn_id() that can't
handle longer ID strings, though I admit that's a stretch.
Thanks,
--Jacob
commit efec9f040843d1de2fc52f5ce0d020478a5bc75d
Author: Jacob Champion
Date: Mo
On Wed, 2022-02-23 at 23:20 +, Jacob Champion wrote:
> First stab in v2-0002. Though I see that Andres is overhauling the
> tests in this folder today [1], so I'll need to watch that thread. :)
v3 rebases over Andres' changes and actually adds the Perl driver that
I missed
On Mon, 2022-02-28 at 16:00 -0500, Stephen Frost wrote:
> > commit efec9f040843d1de2fc52f5ce0d020478a5bc75d
> > Author: Jacob Champion
> > Date: Mon Feb 28 10:28:51 2022 -0800
> >
> > squash! Add API to retrieve authn_id from SQL
>
> Bleh. :) Squash
nches -- but I've dropped it from the
patch and will just carry that diff locally.
Thanks,
--Jacob
From fd6e8a5b09b7facbecc8e38ef1f8a3d2cef866d4 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 14 Feb 2022 08:10:53 -0800
Subject: [PATCH v5] Add API to retrieve authn_id from SQL
The authn_id field in MyProcPort is curren
On Tue, 2022-03-01 at 19:56 +0100, Peter Eisentraut wrote:
> This patch contains no documentation. I'm having a hard time
> understanding what the name "session_authn_id" is supposed to convey.
> The comment for the Port.authn_id field says this is the "system
> username", which sounds like a c
On Wed, 2022-03-02 at 09:18 +0100, Peter Eisentraut wrote:
> On 01.03.22 23:05, Jacob Champion wrote:
> > On Tue, 2022-03-01 at 19:56 +0100, Peter Eisentraut wrote:
> > > This patch contains no documentation. I'm having a hard time
> > > understanding what the nam
On Thu, 2022-03-03 at 16:45 +0900, Michael Paquier wrote:
> Anyway, FixedParallelState
> includes some authentication data passed down by the leader when
> spawning a worker. So, if we were to pass down the authn, we are
> going to need a new PARALLEL_KEY_* to serialize and restore the data
> pass
On Thu, 2022-03-03 at 11:12 +0100, Peter Eisentraut wrote:
> At the moment, it is not possible to judge whether the hook interface
> you have chosen is appropriate.
>
> I suggest you actually implement the Azure provider, then make the hook
> interface, and then show us both and we can see what
all that helpful; worst-case, it pretends to do something it can't,
since the client can't determine what the plaintext password is
actually used for on the backend. And if someone devises (say) a SASL
scheme for proxied LDAP authentication, that spelling becomes obsolete.
Speaking of obs
On Thu, 2022-01-13 at 14:51 +, Jelte Fennema wrote:
> Attached is an updated patch which I believe fixes windows and the other test
> failures.
> At least on my machine make check-world passes now when compiled with
> --enable-tap-tests
>
> I also included a second patch which adds some basi
On Mon, 2022-02-28 at 20:28 -0500, Stephen Frost wrote:
> Will add to the CF for consideration.
GSSAPI newbie here, so caveat lector.
> diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
> index efc53f3135..6f820a34f1 100644
> --- a/src/backend/libpq/auth.c
> +++ b/src/backend/libpq
On Fri, 2022-03-11 at 19:39 -0500, Stephen Frost wrote:
>
> On Fri, Mar 11, 2022 at 18:55 Jacob Champion wrote:
> >
> > [5] says we have to free the proxy credential with GSS_Release_cred();
> > I don't see that happening anywhere, but I may have missed it.
>
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
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 Champ
On Wed, 2022-03-16 at 15:56 +0900, Kyotaro Horiguchi wrote:
> At Tue, 15 Mar 2022 21:41:49 +0000, 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
On Thu, 2022-03-17 at 14:03 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> >
> > trust, reject, md5, password, ident, peer, pam, ldap, radius look trivially
> > possible. I think sspi is doable as well, but I don't know it well enough to
> > be confident. gss without t
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&
On Fri, 2022-03-04 at 10:45 +0900, Michael Paquier wrote:
> At the end of the day, Port is an interface used for the communication
> between the postmaster with the frontends, so I'd like to say that it
> is correct to not apply this concept to parallel workers because they
> are not designed to co
escribes
> the new behavior.
v9 contains the bare minimum but I don't think it's quite enough. How
much of the behavior (and edge cases) do you think we should detail
here? All of it?
Thanks,
--Jacob
commit 6278176f7f417f0afecceb71807eb480e20769ef
Author: Jacob Champion
Date: Tue Mar 22 13:21:48 2022 -0700
squash!
On Tue, 2022-03-22 at 14:48 -0700, samay sharma wrote:
> Thank you for porting this on top of the pluggable auth methods API.
> I've addressed the feedback around other backend changes in my latest
> patch, but the client side changes still remain. I had a few
> questions to understand them better.
On Mon, 2022-03-07 at 11:44 +0100, Laurenz Albe wrote:
> I am all for the idea, but you implemented the reverse of proposal 2.
(This email was caught in my spam filter; sorry for the delay.)
> Wouldn't it be better to list the *rejected* authentication methods?
> Then we could have "password" on
e broken off into its own thing with its own
allocation. But I don't know if we should do it all at once, yet.
WDYT?
--Jacob
From c1323d7694deedf1fa829772083977c18c7f77f6 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 14 Feb 2022 08:10:53 -0800
Subject: [PATCH v6 1/3] Add API to retrieve au
On Wed, 2022-03-23 at 19:00 -0400, Tom Lane wrote:
> Hm. I was more envisioning getting the "sharable" info out of Port
> entirely, although I'm not quite sure where it should go instead.
If it helps, I can move the substruct out and up to a new global struct
(MyProcShared?). At this point I thin
s a co-author to 0002.
--Jacob
From 84a107da33b7d901cb318f8c2fd140644fbc5100 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Wed, 24 Nov 2021 14:46:11 -0800
Subject: [PATCH v10 1/3] Move inet_net_pton() to src/port
This will be helpful for IP address verification in libpq.
---
src/back
On Nov 17, 2020, at 7:00 AM, Daniel Gustafsson wrote:
>
> Nice, thanks for the fix! I've incorporated your patch into the attached v20
> which also fixes client side error reporting to be more readable.
I was testing handshake failure modes and noticed that some FATAL
messages are being sent th
On Mon, 2021-02-15 at 15:09 +0100, Peter Eisentraut wrote:
> The question I had was whether this should be an optional behavior, or
> conversely a behavior that can be turned off, or whether it should just
> be turned on all the time.
Personally I think there should be a toggle, so that any user
On Mon, 2020-07-20 at 15:35 +0200, Daniel Gustafsson wrote:
> This version adds support for sslinfo on NSS for most the functions.
I've poked around to see what can be done about the
unimplemented ssl_client_dn_field/ssl_issuer_field functions. There's a
nasty soup of specs to wade around in, and
While reviewing the NSS patch [1], I noticed that the cryptohash
implementation for OpenSSL doesn't set up any locking callbacks in
frontend code. I think there has to be a call to
OPENSSL_set_locking_callback() before libpq starts reaching into the
EVP_* API, if ENABLE_THREAD_SAFETY and HAVE_CRYPT
On Wed, 2021-02-17 at 22:19 +0100, Daniel Gustafsson wrote:
> > On 17 Feb 2021, at 02:02, Jacob Champion wrote:
> > Would that be desirable, or do we want this interface to be something
> > more generally compatible with (some as-of-yet unspecified) spec?
>
> Regardless o
On Wed, 2021-02-17 at 22:35 +0100, Daniel Gustafsson wrote:
> Attached is a rebase on top of this and the recent cryptohash changes to pass
> in buffer lengths to the _final function. On top of that, I fixed up and
> expanded the documentation, improved SCRAM handling (by using NSS digest
> operat
On Sat, 2021-01-30 at 16:18 -0500, Andrew Dunstan wrote:
> cd src/test/ssl
> touch ../../Makefile.global
> rm -f ssl/client-dn.crt ssl/client-dn.key
> touch ssl/root_ca-certindex
> echo 01> ssl/root_ca.srl
Note that, on my machine at least, the root_ca serial counter is at 03
On Mon, 2021-02-22 at 14:31 +0100, Daniel Gustafsson wrote:
> The attached fixes that as well as implements the sslcrldir
> support that was committed recently. The crldir parameter isn't applicable to
> NSS per se since all CRL's are loaded into the NSS database, but it does need
> to be supporte
On Thu, 2021-02-25 at 17:00 +0100, Peter Eisentraut wrote:
> Just as additional data points, it has come to my attention that both
> the Go driver ("lib/pq") and the JDBC environment already send SNI
> automatically. (In the case of JDBC this is done by the Java system
> libraries, not the JDBC
On Thu, 2021-02-11 at 20:32 +, Jacob Champion wrote:
> v2 just updates the patchset to remove the Windows TODO and fill in the
> patch notes; no functional changes. The question about escaping log
> contents remains.
v3 rebases onto latest master, for SSL test conflicts.
Note:
-
On Fri, 2021-02-05 at 21:54 +, Jacob Champion wrote:
> That just leaves the first patch, then.
I've moved the first patch into the commitfest entry for [1], which
depends on it.
--Jacob
[1]
https://www.postgresql.org/message-id/flat/c55788dd1773c521c862e8e0dddb367df51222
On Sat, 2021-01-30 at 16:18 -0500, Andrew Dunstan wrote:
> Making incremental additions to the certificate set easier wouldn't be a
> bad thing.
>
> I wonder if we should really be setting 1 as the serial number, though.
> Might it not be better to use, say, `date +%Y%m%d01` rather like we do
> wi
On Mon, 2021-03-01 at 16:59 -0600, Justin Pryzby wrote:
> -
> pgstat_progress_update_param(PROGRESS_ANALYZE_CURRENT_CHILD_TABLE_RELID,
>
>
>
>
On Mon, 2021-03-01 at 23:13 +, Jacob Champion wrote:
> On Mon, 2021-03-01 at 16:59 -0600, Justin Pryzby wrote:
> > Why is this removed ?
>
> Mm, both of those analyze.c changes seem suspect. Possibly a mismerge
> from the zedstore branch; let me double-check.
>
> >
On Sat, 2021-02-27 at 17:02 -0500, Jeff Janes wrote:
> Note that in one case you do get the "does not match" line. That is
> if the user has a scram password assigned and the hba specifies
> plain-text 'password' as the method. So if the absence of the DETAIL
> is intentional, it is not internall
On Fri, 2021-02-26 at 15:40 -0500, Andrew Dunstan wrote:
> I think the thing that's principally outstanding w.r.t. this patch is
> what format we should use to extract the DN.
That and the warning label for sharp edges.
> Should we use RFC2253,
> which reverses the field order, as has been sugges
On Wed, 2020-12-16 at 10:45 +0100, Laurenz Albe wrote:
> I consider this a bug fix, but one that shouldn't be backpatched.
> Re-executing the previous query if the editor is quit is
> annoying at least and dangerous at worst.
I like that this patch also clears the query buffer in the error case.
(
On Tue, 2021-03-02 at 18:43 +0100, Magnus Hagander wrote:
> PFA a simple patch that implements support for the PROXY protocol.
I'm not all the way through the patch yet, but this part jumped out at
me:
> + if (memcmp(proxyheader.sig,
> "\x0d\x0a\x0d\x0a\x00\x0d\x0a\x51\x55\x49\x54\x0a", size
On Wed, 2021-03-03 at 17:08 +0100, Laurenz Albe wrote:
> This is no new behavior, and I think this is rare enough that we don't
> have to bother.
I agree that it's not new behavior, but this patch exposes that
behavior for the temporary file case, because you've fixed the bug that
caused the times
On Tue, 2021-03-02 at 10:35 -0800, Zhihong Yu wrote:
> Hi,
Thanks for the review!
> + /* Make sure the the new slot is not dependent on the original tuple */
>
> There is duplicate 'the'.
Thanks, I'll add this for the next batch of updates.
> For neededColumnContextWalker(),
>
> + els
-a8e3-ef8e-a642-a592f5b76771%40dunslane.net
From 3414796bf8e5ea0134bdf524cf932a15f6227354 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Fri, 26 Feb 2021 15:25:28 -0800
Subject: [PATCH] test/ssl: rework the sslfiles Makefile target
Adding a new certificate is as easy as dropping in a new .conf
On Thu, 2021-03-04 at 17:41 +0100, Laurenz Albe wrote:
> So if you do your "modify and save the file in less than a second"
> trick with the old code, you would end up with the old, unmodified
> data in the query buffer.
Sorry, I was unclear in my first post -- I'm not modifying the
temporary file
On Thu, 2021-03-04 at 10:42 +0900, Tatsuo Ishii wrote:
> Is there any formal specification for the "a protocol common and very
> light weight in proxies"?
See
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
which is maintained by HAProxy Technologies.
--Jacob
On Wed, 2021-03-03 at 10:39 +0100, Magnus Hagander wrote:
> On Wed, Mar 3, 2021 at 10:00 AM Magnus Hagander wrote:
> > Another option would of course be to listen on a separate port for it,
> > which seems to be the "haproxy way". That would be slightly more code
> > (we'd still want to keep the c
On Thu, 2021-03-04 at 21:45 +0100, Magnus Hagander wrote:
> On Thu, Mar 4, 2021 at 9:07 PM Jacob Champion wrote:
> > Idle thought I had while setting up a local test rig: Are there any
> > compelling cases for allowing PROXY packets to arrive over Unix
> > sockets? (By which
On Fri, 2021-03-05 at 10:22 +0100, Magnus Hagander wrote:
> On Fri, Mar 5, 2021 at 12:21 AM Jacob Champion wrote:
> > A small nitpick on the current separate-port PoC is that I'm forced to
> > set up a "regular" TCP port, even if I only want the PROXY behavior.
>
On Wed, 2021-03-03 at 15:30 +0900, Michael Paquier wrote:
> Extra eyes are welcome here, though I feel comfortable with the
> approach taken here.
I have one suggestion for the new logic:
>else
>{
>/*
> * In the non-SSL case, just remove the crypto
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Very nice quality-of-life improvement. Thanks!
The new status of
On Sat, 2021-03-06 at 18:33 +0100, Magnus Hagander wrote:
> It looks like patch 0001 has some leftover debuggnig code at the end?
> Or did you intend for that to be included permanently?
I'd intended to keep it -- it works hand-in-hand with the existing
"current_logfiles" log line on 219 and might
On Mon, 2021-03-08 at 22:16 +, Jacob Champion wrote:
> On Sat, 2021-03-06 at 18:33 +0100, Magnus Hagander wrote:
> > With this we store the same value as the authn and as
> > port->gss->princ, and AFAICT it's only used once. Seems we could just
> > use the n
On Sat, 2021-03-06 at 18:33 +0100, Magnus Hagander wrote:
> In fact, if we're storing it in the Port, why
> are we even passing it as a separate parameter to check_usermap --
> shouldn't that one always use this same value?
Ah, and now I remember why I didn't consolidate this to begin with.
Severa
On Mon, 2021-03-08 at 22:16 +, Jacob Champion wrote:
> On Sat, 2021-03-06 at 18:33 +0100, Magnus Hagander wrote:
> > As for log escaping, we report port->user_name already unescaped --
> > surely this shouldn't be a worse case than that?
>
> Ah, that's a fai
On Tue, 2021-03-09 at 18:03 +, Jacob Champion wrote:
> v4 removes the TODO and the extra allocation for peer_user. I'll hold
> off on the other two suggestions pending that conversation.
And v5 is rebased over this morning's SSL test change
On Wed, 2021-03-10 at 17:21 +0900, Michael Paquier wrote:
> Do you mean something like the attached?
Yes! Patch LGTM.
--Jacob
On Tue, 2021-03-09 at 11:25 +0100, Magnus Hagander wrote:
> I've also added some trivial tests (man that took an ungodly amount of
> fighting perl -- it's clearly been a long time since I used perl
> properly).
Yeah. The tests I'm writing for this and NSS have been the same way;
it's a real proble
On Tue, 2021-03-09 at 19:10 +, Jacob Champion wrote:
> And v5 is rebased over this morning's SSL test changes.
Rebased again after the SSL test revert (this is the same as v4).
--Jacob
From 470bf11f4b8feb6c22dc72626f6f3fcb7971ac26 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date
On Nov 4, 2020, at 5:09 AM, Daniel Gustafsson wrote:
> (sorry for slow response). You are absolutely right, the has_password flag
> must be tracked per connection in PGconn. The attached v17 implements this as
> well a frontend bugfix which caused dropped connections and some smaller
> fixups
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Patch looks good to me. Seems like a useful feature, and I agree that
On Nov 6, 2020, at 3:11 PM, Daniel Gustafsson wrote:
>
> The attached switches to SSL_ConfigServerSessionIDCacheWithOpt
> with which one can explicitly make the cache non-shared, which in turn backs
> the mutexes with NSPR locks rather than the missing sem_init. Can you test
> this version and s
On Nov 10, 2020, at 2:28 PM, Daniel Gustafsson wrote:
>
> Digging through the archives from when this landed in curl, the assertion
> failure was never fully identified back then but happened spuriously. Which
> version of NSPR is this happening with?
This is NSPR 4.29, with debugging enabled.
On Nov 11, 2020, at 10:17 AM, Jacob Champion wrote:
>
> (Two failures left on my machine.)
False alarm -- the stderr debugging I'd added in to track down the
assertion tripped up the "no stderr" tests. Zero failing tests now.
--Jacob
On Nov 11, 2020, at 10:57 AM, Jacob Champion wrote:
>
> False alarm -- the stderr debugging I'd added in to track down the
> assertion tripped up the "no stderr" tests. Zero failing tests now.
I took a look at the OpenSSL interop problems you mentioned upthread. I
don&#
On Nov 12, 2020, at 2:40 PM, Tomas Vondra wrote:
>
> Hi,
>
> Thanks for the updated patch. It's a quite massive amount of code - I I
> don't think we had many 2MB patches in the past, so this is by no means
> a full review.
Thanks for taking a look! You're not kidding about the patch size.
FYI
On Nov 13, 2020, at 4:14 AM, Daniel Gustafsson wrote:
>> On 12 Nov 2020, at 23:12, Jacob Champion wrote:
>>
>> I'm not completely sure why this is exposed so easily with an OpenSSL
>> server -- I'm guessing the implementation slices up its packets
>>
On Nov 13, 2020, at 2:00 PM, Tomas Vondra wrote:
>
> Fedora 32, nothing special. I'm not sure if I ran the tests with pglz or
> lz4, maybe there's some dependence on that, but it does fail for me
> quite reliably with this:
>
> ./configure --enable-debug --enable-cassert --enable-tap-tests
> --
On Tue, 2020-10-27 at 21:07 +0100, Daniel Gustafsson wrote:
> > On 20 Oct 2020, at 21:15, Andres Freund wrote:
> >
> > > +static SECStatus
> > > +pg_cert_auth_handler(void *arg, PRFileDesc * fd, PRBool checksig, PRBool
> > > isServer)
> > > +{
> > > + SECStatus status;
> > > + Port *
On Tue, 2021-01-19 at 21:21 +0100, Daniel Gustafsson wrote:
> There is something iffy with these certs (the test fails
> on mismatching ciphers and/or signature algorithms) that I haven't been able
> to
> pin down, but to get more eyes on this I'm posting the patch with the test
> enabled.
Removi
On Mon, 2021-01-18 at 11:23 +0100, Daniel Gustafsson wrote:
> + /* use commas instead of slashes */
> + X509_NAME_print_ex(bio, x509name, 0, XN_FLAG_SEP_COMMA_PLUS);
> I don't have strong opinions on whether we shold use slashes or commas, but I
> think it needs to be do
On Wed, 2021-01-20 at 19:07 +, Jacob Champion wrote:
> I think you'll want to be careful to specify the format as much as
> possible, both to make sure that other backend TLS implementations can
> actually use the same escaping system and to ensure that user regexes
> don
On Mon, 2020-07-20 at 15:35 +0200, Daniel Gustafsson wrote:
> With this, I have one failing test ("intermediate client certificate is
> provided by client") which I've left failing since I believe the case should
> be
> supported by NSS. The issue is most likely that I havent figured out the
> r
On Thu, 2021-01-21 at 14:21 +0900, Michael Paquier wrote:
> Also, what's the minimum version of NSS that would be supported? It
> would be good to define an acceptable older version, to keep that
> documented and to track that perhaps with some configure checks (?),
> similarly to what is done for
ql to use it via the KRB5CCNAME envvar.
This prevents the global cache pollution. WDYT?
--Jacob
From c9532e72a762abeef0996ad8df5da9bbdedbccad Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 25 Jan 2021 09:32:44 -0800
Subject: [PATCH] test/kerberos: use a local credentials cache
Previously
On Mon, 2021-01-25 at 13:49 -0500, Tom Lane wrote:
> Yeah, changing global state is just awful. However, I don't
> actually see any change here (RHEL8):
Interesting. I'm running Ubuntu 20.04:
$ klist
klist: No credentials cache found (filename: /tmp/krb5cc_1000)
$ make check
...
$ klist
Ticket
On Mon, 2021-01-25 at 14:04 -0500, Tom Lane wrote:
> Jacob Champion writes:
> > On Mon, 2021-01-25 at 13:49 -0500, Tom Lane wrote:
> > > Also, why are you only setting the ENV variable within narrow parts
> > > of the test script? I'd be inclined to enforce it thr
On Mon, 2021-01-25 at 14:36 -0500, Tom Lane wrote:
> However, this doesn't seem to explain why the test script isn't
> causing a global state change. Whether the state is held in a
> file or the sssd daemon shouldn't matter, it seems like.
>
> Also, it looks like the test causes /tmp/krb5cc_ to g
On Tue, 2021-01-26 at 13:49 +0100, Daniel Gustafsson wrote:
> Reading more on this it seems we would essentially have to go with RFC 4514,
> as
> it's the closest to a standard which seems to exist. Having done a lot
> research on this topic, do you have a gut feeling on direction?
Yeah, if we'r
On Wed, 2021-01-27 at 16:39 +0900, Michael Paquier wrote:
> My apologies for chiming in. I was looking at your patch set here,
> and while reviewing the strong random and cryptohash parts I have
> found a couple of mistakes in the ./configure part. I think that the
> switch from --with-openssl to
On Tue, 2021-01-26 at 18:43 +, Jacob Champion wrote:
> On Tue, 2021-01-26 at 13:49 +0100, Daniel Gustafsson wrote:
> > The OpenSSL X509_NAME_cmp function use RFC 5280 section 7.1 and RFC 4517
> > section 4.2.15 (which in turn reference RFC 4514 for the DN string format).
On Wed, 2021-01-27 at 15:42 -0500, Andrew Dunstan wrote:
> I'm not sure where we want to go with the present patch. Do we want to
> go with what we have and document the limitations more, or try to do
> something more elaborate? If so, exactly what?
After sleeping on it:
I think that if you expec
id/flat/92e70110-9273-d93c-5913-0bccb6562...@dunslane.net
From 3f6e87a744be339748fc707cd071896e81e0323c Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Fri, 22 Jan 2021 14:03:14 -0800
Subject: [PATCH] WIP: log authenticated identity from multiple auth backends
This is stored into port->authn_id according to t
On Thu, 2021-01-21 at 20:16 +, Jacob Champion wrote:
> I think we're missing a counterpart to this piece of the OpenSSL
> implementation, in be_tls_init():
Never mind. Using SSL_SetTrustAnchor is something we could potentially
do if we wanted to further limit the CAs that are actua
On Fri, 2021-01-29 at 13:57 +0100, Daniel Gustafsson wrote:
> > On 21 Jan 2021, at 06:21, Michael Paquier wrote:
> > I really need to study more the choide of the options chosen for
> > NSS_InitContext()... But based on the docs I can read on the matter I
> > think that saving nsscontext in pg_cr
On Fri, 2021-01-29 at 17:01 -0500, Stephen Frost wrote:
> > - for LDAP, the bind DN is discarded entirely;
>
> We don't support pg_ident.conf-style entries for LDAP, meaning that the
> user provided has to match what we check, so I'm not sure what would be
> improved with this change..?
For simpl
1 - 100 of 1184 matches
Mail list logo
