Re: [PoC] Federated Authn/z with OAUTHBEARER

On Mon, Dec 12, 2022 at 9:06 PM Andrey Chudnovsky wrote: > If your concern is extension not honoring the DBA configured values: > Would a server-side logic to prefer HBA value over extension-provided > resolve this concern? Yeah. It also seals the role of the extension here as "optional". > We

Re: Remove SHA256_HMAC_B from scram-common.h

On Mon, Dec 12, 2022 at 8:57 PM Michael Paquier wrote: > While doing some hackery on SCRAM, I have noticed $subject giving the > attached. I guess that this is not going to cause any objections, but > feel free to comment just in case. Yeah, no objection :D That cryptohash refactoring was quite

RFC: logical publication via inheritance root?

Hi, TImescale makes use of inheritance in its partitioning implementation, so we can't make use of the publish_via_partition_root publication option during logical replication. We don't guarantee that the exact same partitions exist on both sides, so that's a major roadblock for our implementing

Re: [PoC] Federated Authn/z with OAUTHBEARER

On Wed, Dec 7, 2022 at 3:22 PM Andrey Chudnovsky wrote: > >> I think it's okay to have the extension and HBA collaborate to >> provide discovery information. Your proposal goes further than >> that, though, and makes the server aware of the chosen client flow. >> That appears to be an

Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

On Mon, Dec 5, 2022 at 10:53 AM Jacob Champion wrote: > We are not the first using Homebrew to run into this, and best I can > tell, it is a brew-specific bug. The certificate directory that's been > configured isn't actually installed by the formula. (A colleague here > was ab

Re: [PATCH] pg_dump: lock tables in batches

On Wed, Dec 7, 2022 at 2:53 PM Tom Lane wrote: > Is "-s" mode actually a relevant criterion here? With per-table COPY > commands added into the mix you could not possibly get better than 2x > improvement, and likely a good deal less. Don't we hit this code path in pg_upgrade? You won't see huge

Re: [PoC] Federated Authn/z with OAUTHBEARER

On Mon, Dec 5, 2022 at 4:15 PM Andrey Chudnovsky wrote: > I think we can focus on the roles and responsibilities of the components > first. > Details of the patch can be elaborated. Like "flow type code" is a > mistake on our side, and we will use the term "grant_type" which is > defined by OIDC

Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

On Fri, Dec 2, 2022 at 9:58 AM Jacob Champion wrote: > Thanks for the nudge -- running with OpenSSL 3.0.7 in CI did not fix > the issue. I suspect a problem with our error stack handling... It is a problem with the error queue, but *whose* problem is probably up for debate. The queue look

Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

On Thu, Dec 1, 2022 at 9:26 PM Michael Paquier wrote: > On Mon, Nov 07, 2022 at 05:04:14PM -0800, Jacob Champion wrote: > > The macOS/OpenSSL 3.0.0 failure is still unfixed. > > Err, could you look at that? I am switching the patch as waiting on > author. Thanks for th

Re: [PoC] Federated Authn/z with OAUTHBEARER

On 11/24/22 00:20, mahendrakar s wrote: > I had validated Github by skipping the discovery mechanism and letting > the provider extension pass on the endpoints. This is just for > validation purposes. > If it needs to be supported, then need a way to send the discovery > document from extension.

Re: [PoC] Federated Authn/z with OAUTHBEARER

On 11/23/22 19:45, Andrey Chudnovsky wrote: > Mostly terminology questions here. OAUTHBEARER SASL appears to be the > spec about using OAUTH2 tokens for Authentication. > While any OAUTH2 can generally work, we propose to specifically > highlight that only OIDC providers can be supported, as we

Re: [PoC] Federated Authn/z with OAUTHBEARER

On 11/23/22 01:58, mahendrakar s wrote: > We validated on  libpq handling OAuth natively with different flows > with different OIDC certified providers. > > Flows: Device Code, Client Credentials and Refresh Token. > Providers: Microsoft, Google and Okta. Great, thank you! > Also validated with

Re: libpq support for NegotiateProtocolVersion

On Tue, Nov 15, 2022 at 2:19 AM Peter Eisentraut wrote: > I think for the current code, the following would be an appropriate > adjustment: > > diff --git a/src/interfaces/libpq/fe-connect.c > b/src/interfaces/libpq/fe-connect.c > index 746e9b4f1efc..d15fb96572d9 100644 > ---

Re: [PoC] Let libpq reject unexpected authentication requests

s = CONNECTION_BAD; - appendPQExpBuffer(>errorMessage, - libpq_gettext("sslcertmode value \"%s\" is not supported (check OpenSSL version)\n"), - conn->sslc

Re: Moving forward with TDE

e two variables probably needs some scrutiny). It looks like the testcrypto executable will need substantial changes after the common/hex.h revert. --Jacob From eb4b55f5d03e362cf340f322c0cefbf95f53657a Mon Sep 17 00:00:00 2001 From: Jacob Champion Date: Mon, 14 Nov 2022 16:02:57 -0800 Subject: [PAT

Re: Moving forward with TDE

On Mon, Oct 24, 2022 at 9:29 AM David Christensen wrote: > I would love to open a discussion about how to move forward and get > some of these features built out. The historical threads here are > quite long and complicated; is there a "current state" other than the > wiki that reflects the

Re: [PoC] Let libpq reject unexpected authentication requests

On 11/11/22 22:57, Aleksander Alekseev wrote: > I did a little more research and I think you are right. What happens > according to the C standard: Thanks for confirming! (I personally prefer -1 to a *MAX macro, because it works regardless of the length of the type.) --Jacob

Re: libpq support for NegotiateProtocolVersion

On 11/13/22 01:21, Peter Eisentraut wrote: > On 11.11.22 23:28, Jacob Champion wrote: >> Put another way, why do we loop around and poll for more data when we >> hit the end of the connection buffer, if we've already checked at this >> point that we should have the entire mes

Re: [PoC] Let libpq reject unexpected authentication requests

ommunity. Thank you! I expect a maintainer will need to weigh in on the cost/benefit of 0003 either way. --Jacobcommit e71ea0d0356f5ef2fb4214fc978f835d9fa815f8 Author: Jacob Champion Date: Fri Nov 11 15:55:23 2022 -0800 squash! Add sslcertmode option for client certificates Improve docs, f

Re: libpq support for NegotiateProtocolVersion

On 11/11/22 07:13, Peter Eisentraut wrote: > On 09.11.22 00:08, Jacob Champion wrote: >> pqGetNegotiateProtocolVersion3() is still ignoring the message length, >> though; it won't necessarily stop at the message boundary. > > I don't follow. The calls to pqGetInt(),

Re: User functions for building SCRAM secrets

On Tue, Nov 8, 2022 at 9:28 PM Michael Paquier wrote: > On Tue, Nov 08, 2022 at 04:57:09PM -0800, Jacob Champion wrote: > > But I guess that wouldn't really help with ALTER ROLE ... PASSWORD, > > because you can't parameterize it. Hm... > > Yeah, and I'd like to think that th

Re: User functions for building SCRAM secrets

On 11/8/22 12:26, Peter Eisentraut wrote: > On 04.11.22 21:39, Jacob Champion wrote: >> I don't think it's helpful for me to try to block progress on this >> patchset behind the other one. But is there a way for me to help this >> proposal skate in the same general dir

Re: libpq support for NegotiateProtocolVersion

On 11/8/22 00:40, Peter Eisentraut wrote: > On 02.11.22 20:02, Jacob Champion wrote: >> This new code path doesn't go through the message length checks that are >> done for the 'R' and 'E' cases, and pqGetNegotiateProtocolVersion3() >> doesn't take the message length to know

Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

On Thu, Nov 3, 2022 at 4:39 PM Jacob Champion wrote: > There is an additional test failure with LibreSSL, which doesn't appear > to honor the SSL_CERT_FILE environment variable. This isn't a problem in > production -- if you're using LibreSSL, you'd presumably understand that > y

Re: User functions for building SCRAM secrets

On Tue, Nov 1, 2022 at 4:02 PM Jacob Champion wrote: > I guess I have fewer problems with this use case in theory, but I'm > wondering if better client-side support might also solve this one as > well, without the additional complication. Is there a reason it would > not

Re: Commit fest 2022-11

On 11/3/22 22:18, Ian Lawrence Barwick wrote: > 2022年11月4日(金) 10:23 Ian Lawrence Barwick >: >> 2022年11月4日(金) 9:43 Justin Pryzby >: >> > If I'm not wrong, Jacob used the CF app to bulk-mail people about >> > patches not applying and similar

Re: Add non-blocking version of PQcancel

On 10/5/22 06:23, Jelte Fennema wrote: > In my first version of this patch, this is exactly what I did. But then > I got this feedback from Jacob, so I changed it to reusing PGconn: > >> [snip] > > I changed it back to use PGcancelConn as per your suggestion and I > agree that the API got

Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

On Tue, Nov 1, 2022 at 10:55 AM Jacob Champion wrote: > On Tue, Nov 1, 2022 at 10:03 AM Jacob Champion > wrote: > > I'm not familiar with "unregistered scheme" in this context and will > > need to dig in. > > Unfortunately I can't reproduce with 3.0.0 on Ubunt

Re: libpq support for NegotiateProtocolVersion

A few notes: > + else if (beresp == 'v') > + { > + if > (pqGetNegotiateProtocolVersion3(conn)) > + { > + /* We'll come back

Re: User functions for building SCRAM secrets

On Mon, Oct 31, 2022 at 1:27 PM Jonathan S. Katz wrote: > Having a set of SCRAM secret building functions would help in a few areas: I have mixed-to-negative feelings about this. Orthogonality with other methods seems reasonable, except we don't really recommend that people use those other

Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

On Tue, Nov 1, 2022 at 10:03 AM Jacob Champion wrote: > I'm not familiar with "unregistered scheme" in this context and will > need to dig in. Unfortunately I can't reproduce with 3.0.0 on Ubuntu :( I'm suspicious that it may be related to [1], in which case the proble

Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

On Tue, Nov 1, 2022 at 5:30 AM wrote: > Sweet. I just created an account with username `habets`. Added! OpenSSL 3.0.0 doesn't get along with one of my new tests: # Failed test 'sslrootcert=system does not connect with private CA: matches' # at

Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

On Tue, Oct 25, 2022 at 1:20 PM Jacob Champion wrote: > I wanted to get feedback on the approach before wordsmithing too > much. I've added this to tomorrow's CF [1]. Thomas, if you get (or already have) a PG community username, I can add you as an author. Thanks, --Jacob [1]

Re: Commitfest documentation

On Mon, Oct 31, 2022 at 8:18 AM Jehan-Guillaume de Rorthais wrote: > However, I'm not strictly sure who is responsible to set these statuses. The > reviewer? The author? The commiter? The CF manager? I bet on the reviewer, but > it seems weird a random reviewer can reject a patch on its own

Re: Documentation for building with meson

On Thu, Oct 27, 2022 at 4:03 PM Andres Freund wrote: > Tests can have dependencies, and they're correctly built. The problem however > is that, for historical reasons if I understand correctly, dependencies of > tests are automatically included in the default 'all' target. Which means if > you

Re: Documentation for building with meson

On Thu, Oct 27, 2022 at 1:04 AM John Naylor wrote: > This does not work for me in a fresh install until running > > meson test --suite setup > > In fact, we see in > > https://wiki.postgresql.org/wiki/Meson > > meson test --suite setup --suite main (Is there a way to declare a dependency on the

Re: [PATCH] CF app: add "Returned: Needs more interest"

On Mon, Aug 8, 2022 at 8:45 AM Andres Freund wrote: > On 2022-08-08 08:37:41 -0700, Jacob Champion wrote: > > Agreed. This probably bleeds over into the other documentation thread > > a bit -- how do we want to communicate the subtle points to people in > > a CF? > > W

Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

On Tue, Oct 25, 2022 at 7:26 AM Andrew Dunstan wrote: > I don't find too much difficulty in having one option's default depend > on another's value, as long as it's documented. My patch is definitely missing the documentation for that part right now; I wanted to get feedback on the approach

Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

On Tue, Oct 25, 2022 at 4:01 AM wrote: > Yeah I agree that not forcing verify-full when using system CAs is a > giant foot-gun, and many will stop configuring just until it works. > > Is there any argument for not checking hostname when using a CA pool > for which literally anyone can create a

Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

goes all the way down to conninfo_add_defaults(). Maybe this is overly complex. Should I just make sslmode a derived option, via connectOptions2()? Thanks, --Jacob From 14311929a443f25f5064cdb01b57fae8d575e66d Mon Sep 17 00:00:00 2001 From: Jacob Champion Date: Mon, 24 Oct 2022 15:24:11 -0700 Subject:

Re: [PoC] Let libpq reject unexpected authentication requests

On Wed, Oct 12, 2022 at 9:40 AM Jacob Champion wrote: > On 10/5/22 06:33, Peter Eisentraut wrote: > > I think it would be good to put some provisions in place here, even if > > they are elementary. Otherwise, there will be a significant burden on > > the person who imp

Re: Support tls-exporter as channel binding for TLSv1.3

On Wed, Oct 12, 2022 at 11:01 PM Michael Paquier wrote: > One thing that would reduce the complexity of the equation is > to drop support for tls-server-end-point in the backend in PG >= 16 as > the versions of OpenSSL we still support on HEAD would cover > completely tls-exporter. Is the intent

Re: [PoC] Let libpq reject unexpected authentication requests

iption(areq)); - } + if (!reason) + reason = auth_description(areq); + + appendPQExpBuffer(>errorMessage, + libpq_gettext("auth method \"%s\" requirement failed:

Re: [PoC] Federated Authn/z with OAUTHBEARER

On Fri, Sep 30, 2022 at 7:47 AM Andrey Chudnovsky wrote: > > How should we communicate those pieces to a custom client when it's > > passing a token directly? The easiest way I can see is for the custom > > client to speak the OAUTHBEARER protocol directly (e.g. SASL plugin). > > If you had to

Re: [PATCH] Log details for client certificate failures

On Tue, Sep 27, 2022 at 6:14 PM Masahiko Sawada wrote: > No. Since cluster_name is PGC_POSTMATER, we leak a little postmaster > memory only once when starting up. application_name is PGC_USERSET but > since we normally allocate memory in PortalMemoryContext we eventually > can free it. Oh, I

Re: SYSTEM_USER reserved word implementation

On 9/26/22 06:29, Drouvot, Bertrand wrote: > Please find attached V4 taking care of Jacob's previous comments. > + /* > + * InitializeSystemUser should already be called once we are sure that > + * authn_id is not NULL (means auth_method is actually valid). > + * But keep the

Re: [PoC] Federated Authn/z with OAUTHBEARER

On Mon, Sep 26, 2022 at 6:39 PM Andrey Chudnovsky wrote: > For the providing token directly, that would be primarily used for > scenarios where the same party controls both the server and the client > side wrapper. > I.e. The client knows how to get a token for a particular principal > and

Re: [PATCH] Log details for client certificate failures

On Tue, Sep 27, 2022 at 1:51 AM Masahiko Sawada wrote: > I think we can fix it by the attached patch but I'd like to discuss > whether it's worth fixing it. Whoops. So every time it's changed, we leak a little postmaster memory? Your patch looks good to me and I see no reason not to fix it.

Re: [PoC] Federated Authn/z with OAUTHBEARER

On Fri, Mar 25, 2022 at 5:00 PM Jacob Champion wrote: > v4 rebases over the latest version of the pluggable auth patchset > (included as 0001-4). Note that there's a recent conflict as > of d4781d887; use an older commit as the base (or wait for the other > thread to be updated). He

Re: [PoC] Let libpq reject unexpected authentication requests

On Thu, Sep 22, 2022 at 4:52 AM Peter Eisentraut wrote: > On 22.09.22 01:37, Jacob Champion wrote: > > I think this is potentially > > dangerous, but it mirrors the current behavior of libpq and I'm not > > sure that we should change it as part of this patch. > >

Re: [EXTERNAL] Re: [PoC] Federated Authn/z with OAUTHBEARER

On 9/21/22 21:55, Andrey Chudnovsky wrote: > First, My message from corp email wasn't displayed in the thread, I see it on the public archives [1]. Your client is choosing some pretty confusing quoting tactics, though, which you may want to adjust. :D I have what I'll call some "skeptical

Re: [PoC] Let libpq reject unexpected authentication requests

On Wed, Sep 21, 2022 at 3:36 PM Peter Eisentraut wrote: > So let's look at the two TODO comments you have: > > * TODO: how should !auth_required interact with an incomplete > * SCRAM exchange? > > What specific combination of events are you thinking of here? Let's say the

Re: [EXTERNAL] Re: [PoC] Federated Authn/z with OAUTHBEARER

On Wed, Sep 21, 2022 at 3:10 PM Andrey Chudnovskiy wrote: > We can support both passing the token from an upstream client and libpq > implementing OAUTH2 protocol to obtaining one. Right, I agree that we could potentially do both. > Libpq passing toked directly from an upstream client is

Re: [PoC] Federated Authn/z with OAUTHBEARER

On Tue, Sep 20, 2022 at 4:19 PM Jacob Champion wrote: > > 2. Add support to pass on the OAuth bearer token. In this > > obtaining the bearer token is left to 3rd party application or user. > > > > ./psql -U -d 'dbname=postgres > > oauth_client_id= oaut

Re: [PoC] Let libpq reject unexpected authentication requests

On Fri, Sep 16, 2022 at 1:29 PM Jacob Champion wrote: > I'm happy to implement proofs of concept for that, or any other ideas, > given the importance of getting this "right enough" the first time. > Just let me know. v8 rebases over the postgres_fdw HINT changes; ther

Re: [PoC] Federated Authn/z with OAUTHBEARER

Hi Mahendrakar, thanks for your interest and for the patch! On Mon, Sep 19, 2022 at 10:03 PM mahendrakar s wrote: > The changes for each component are summarized below. > > 1. Provider-specific extension: > Each OAuth provider implements their own token validator as an > extension.

Re: Support tls-exporter as channel binding for TLSv1.3

On Tue, Sep 20, 2022 at 11:01 AM Jacob Champion wrote: > Well, I'm working on a next version, but it's ballooning in complexity > as I try to navigate the fix for OpenSSL 1.0.1 (which is currently > failing the tests, unsurprisingly). To be more specific: I think I'm hitting the case th

Re: Support tls-exporter as channel binding for TLSv1.3

On Mon, Sep 19, 2022 at 5:54 PM Michael Paquier wrote: > X509_get_signature_nid() has been introduced in 1.0.2. > SSL_export_keying_material() is older than that, being present since > 1.0.1. Considering the fact that we want to always have > tls-server-end-point as default, it seems to me that

Re: CFM Manager

On Thu, Sep 8, 2022 at 2:34 PM Jacob Champion wrote: > I still have yet to update the section "5 to 7 days before end of CF" > and onward. Well, I've saved the hardest part for last... Ibrar, Hamid, have the checklist rewrites been helpful so far? Are you planning on doing an (o

Re: Patch proposal: make use of regular expressions for the username in pg_hba.conf

On Mon, Sep 19, 2022 at 9:09 PM Tom Lane wrote: > You have to assume that somebody (a) has a role or DB name starting > with slash, (b) has an explicit reference to that name in their > pg_hba.conf, (c) doesn't read the release notes, and (d) doesn't > notice that things are misbehaving until

Re: Kerberos delegation support in libpq and postgres_fdw

On 9/19/22 10:05, Stephen Frost wrote: > This is coming across as if it's a surprise of some kind when it > certainly isn't.. If the delegated credentials are being used to > authenticate and establish the connection from that backend to another > system then, yes, naturally that means that the

Re: Support tls-exporter as channel binding for TLSv1.3

On Wed, Sep 7, 2022 at 10:03 AM Jacob Champion wrote: > Yeah, that should be fine. Requiring newer OpenSSLs for stronger > crypto will probably be uncontroversial. While looking into this I noticed that I left the following code in place: > #ifdef HAVE_BE_TLS_GET_CERTIFI

Re: [PoC] Let libpq reject unexpected authentication requests

On Fri, Sep 16, 2022 at 7:56 AM Peter Eisentraut wrote: > On 08.09.22 20:18, Jacob Champion wrote: > After thinking about this a bit more, I think it would be best if the > words used here match exactly with what is used in pg_hba.conf. That's > the only thing the user cares a

Re: Kerberos delegation support in libpq and postgres_fdw

On Thu, Jul 7, 2022 at 4:24 PM Jacob Champion wrote: > So my question is this: does substituting my credentials for the admin's > credentials let me weaken or break the transport encryption on the > backend connection, and grab the password that I'm not supposed to have > access to as

Re: [PATCH] Log details for client certificate failures

On Tue, Sep 13, 2022 at 7:11 AM Peter Eisentraut wrote: > This looks fine to me. Committed. Thanks! --Jacob

Re: Pluggable toaster

On Mon, Sep 12, 2022 at 11:45 PM Nikita Malakhov wrote: > It would be more clear for complex data types like JSONB, where developers > could > need some additional functionality to work with internal representation of > data type, > and its full potential is revealed in our JSONB toaster

Re: Pluggable toaster

On Wed, Aug 24, 2022 at 2:59 AM Nikita Malakhov wrote: > I've rebased actual branch onto the latest master and re-created patches. > Checked with git am, > all applied correctly. Please check the attached patches. > Rebased branch resides here: >

Re: Patch proposal: make use of regular expressions for the username in pg_hba.conf

On 8/19/22 01:12, Drouvot, Bertrand wrote: > + wstr = palloc((strlen(tok->string + 1) + 1) * sizeof(pg_wchar)); > > + wlen = pg_mb2wchar_with_len(tok->string + 1, > > + wstr, strlen(tok->string + 1)); The

Re: Patch proposal: make use of regular expressions for the username in pg_hba.conf

On Thu, Sep 8, 2022 at 5:46 PM Tom Lane wrote: > Jacob Champion writes: > > I think you're going to have to address backwards compatibility > > concerns. Today, I can create a role named "/a", and I can put that > > into the HBA without quoting it. I'd be unamus

Re: Patch proposal: make use of regular expressions for the username in pg_hba.conf

On Fri, Aug 19, 2022 at 1:13 AM Drouvot, Bertrand wrote: > This is why I think username filtering with regular expressions would > provide its own advantages. > > Thoughts? Looking forward to your feedback, I think your motivation for the feature is solid. It is killing me a bit that this is

Re: pg_upgrade failing for 200+ million Large Objects

On Thu, Sep 8, 2022 at 4:18 PM Nathan Bossart wrote: > IIUC the main benefit of this approach is that it isn't dependent on > binary-upgrade mode, which seems to be a goal based on the discussion > upthread [0]. To clarify, I agree that pg_dump should contain the core fix. What I'm questioning

Re: [PATCH] Log details for client certificate failures

On Thu, Jul 28, 2022 at 9:19 AM Jacob Champion wrote: > On Thu, Jul 21, 2022 at 4:29 PM Jacob Champion > wrote: > > v4 attempts to fix this by letting the check hooks pass > > MCXT_ALLOC_NO_OOM to pg_clean_ascii(). (It's ignored in the frontend, > > which just mallocs.)

Re: CFM Manager

On Tue, Aug 23, 2022 at 9:27 AM Jacob Champion wrote: > I have updated the CFM checklist through the "2 days before CF" > section. Let me know if you have questions/suggestions. I've additionally removed references to "shame emails" for non-reviewers; I don't think C

Re: [PoC] Let libpq reject unexpected authentication requests

On Thu, Sep 8, 2022 at 6:25 AM Peter Eisentraut wrote: > For example, before long someone is going to try putting "ldap" into > require_auth. The fact that the methods in pg_hba.conf are not what > libpq sees is not something that was really exposed to users until now. > "none" vs. "trust" takes

Re: SYSTEM_USER reserved word implementation

On Wed, Sep 7, 2022 at 6:17 PM Michael Paquier wrote: > >> + /* Initialize SystemUser now that MyClientConnectionInfo is > >> restored. */ > >> + InitializeSystemUser(MyClientConnectionInfo.authn_id, > >> + > >>

Re: pg_upgrade failing for 200+ million Large Objects

On 8/24/22 17:32, Nathan Bossart wrote: > I'd like to revive this thread, so I've created a commitfest entry [0] and > attached a hastily rebased patch that compiles and passes the tests. I am > aiming to spend some more time on this in the near future. Just to clarify, was Justin's statement

Re: Support tls-exporter as channel binding for TLSv1.3

On Wed, Aug 31, 2022 at 5:57 PM Michael Paquier wrote: > On Wed, Aug 31, 2022 at 04:16:29PM -0700, Jacob Champion wrote: > > OpenSSL should have an API for that (SSL_get_extms_support); I don't > > know when it was introduced. > > This is only available from 1.1.0, mea

Re: SYSTEM_USER reserved word implementation

On 9/7/22 07:46, Drouvot, Bertrand wrote: > Except the Nit above, that looks all good to me. A few additional comments: > +assigned a database role. It is represented as > +auth_method:identity or > +NULL if the user has not been authenticated (for > +example if

Re: Transparent column encryption

On Tue, Aug 30, 2022 at 4:53 AM Peter Eisentraut wrote: > I would be interested in learning more about such padding systems. I > have done a lot of reading for this development project, and I have > never come across a cryptographic approach to hide length differences by > padding. Of course,

Re: Support tls-exporter as channel binding for TLSv1.3

On Sun, Aug 28, 2022 at 11:02 PM Michael Paquier wrote: > RFC9266, that has been released not so long ago, has added > tls-exporter as a new channel binding type: > https://www.rfc-editor.org/rfc/rfc5929.html Hi Michael, thank you for sending this! > Note also that tls-exporter is aimed for >

Re: [PATCH] Expose port->authn_id to extensions and triggers

On 8/23/22 01:53, Drouvot, Bertrand wrote: > That sounds all good to me, except a typo for the author in the commit > message: s/Jocob/Jacob/ Thanks, I missed that on my readthrough! :D Patch looks good to me, too, with one question: > @@ -2688,6 +2689,7 @@ InitProcessGlobals(void)

Re: CFM Manager

On Mon, Aug 22, 2022 at 1:50 PM Ibrar Ahmed wrote: > This will help to complete the tasks. I start looking at that; I will let you > know how we both > manage to share the load I have updated the CFM checklist through the "2 days before CF" section. Let me know if you have

Re: CFM Manager

On Mon, Aug 22, 2022 at 9:40 AM Tom Lane wrote: > You attribute more organization to this than actually exists ;-) Ha, fair enough! > If Ibrar wants the job I think it's his. Excellent. Ibrar, I'll be updating the CFM checklist [1] over the next couple of weeks. I'll try to have sections of it

Re: CFM Manager

On Thu, Aug 11, 2022 at 3:14 AM Ibrar Ahmed wrote: > Is anybody else volunteer for that, if not I am ready to take that > resposibility. Hi Ibrar, I don't think I've seen anyone else volunteer. I'd wait for a committer to confirm that you've got the job, though. All: we're rapidly approaching

Re: [PATCH] Expose port->authn_id to extensions and triggers

On Mon, Aug 22, 2022 at 4:32 AM Michael Paquier wrote: > By the way, I have looked at the patch, tweaked a couple of things > with comments and the style, but overval that's fine. First, I have > intended to apply this stuff today but I have lacked the time to do > so. I should be able to get

Re: [PATCH] Expose port->authn_id to extensions and triggers

ClientConnectionInfo` - use an intermediate serialization struct - switch to length-"prefixing" for the string I do like the way this reads compared to before. Thanks, --Jacob commit 753c46352adc967a903a60ea65a3068252d685e6 Author: Jacob Champion Date: Tue Aug 16 09:14:58 2022 -0700

Re: SYSTEM_USER reserved word implementation

est SYSTEM_USER. --Jacob commit adaff75cb96ec842d15e15df2ee42dd4b3fa1349 Author: Jacob Champion Date: Tue Aug 16 09:32:45 2022 -0700 squash! SYSTEM_USER implementation Check the contents of SYSTEM_USER in the Kerberos tests, not just its existence. diff --git a/src/test/kerberos

Re: [PATCH] Expose port->authn_id to extensions and triggers

Hello, On Fri, Aug 12, 2022 at 6:34 AM Drouvot, Bertrand wrote: > +typedef struct > +{ > + /* > +* Authenticated identity. The meaning of this identifier is > dependent on > > has to be replaced by: > > +typedef struct ClientConnectionInfo > +{ > + /* > +*

Re: [PATCH] Expose port->authn_id to extensions and triggers

o copy the auth_method over as well. It "passes tests" but is otherwise unexercised. Thanks, --Jacob commit 69cacd5e0869b18d64ff4233ef6a73123c513496 Author: Jacob Champion Date: Thu Aug 11 15:16:15 2022 -0700 squash! Allow parallel workers to read authn_id Add a copy of

Re: [PATCH] Expose port->authn_id to extensions and triggers

b From a22ff3ba36f5eb93c582a957c7c2caca07ed21c5 Mon Sep 17 00:00:00 2001 From: Jacob Champion Date: Wed, 23 Mar 2022 15:07:05 -0700 Subject: [PATCH] Allow parallel workers to read authn_id Move authn_id into a new global, MyClientConnectionInfo, which is intended to hold all the client information that needs to be shared b

Re: [PATCH] CF app: add "Returned: Needs more interest"

On Thu, Aug 4, 2022 at 3:00 PM Andres Freund wrote: > On 2022-08-04 11:19:28 -0700, Jacob Champion wrote: > > My intention had not quite been for this to be a referendum on the > > decision for every patch -- we can do that if it helps, but I don't > > think we necessarily h

Re: Clarifying Commitfest policies

On Wed, Aug 3, 2022 at 2:05 PM Matthias van de Meent wrote: > On Wed, 3 Aug 2022 at 20:04, Jacob Champion wrote: > > Is that enough, or should we do more? > > "The CF Checklist" seems to refer to only the page that is (or seems > to be) intended for the CFM only. We

Re: [PATCH] CF app: add "Returned: Needs more interest"

Hi Andres, My intention had not quite been for this to be a referendum on the decision for every patch -- we can do that if it helps, but I don't think we necessarily have to have unanimity on the bucketing for every patch in order for the new state to be useful. On 8/3/22 12:46, Andres Freund

Re: [PATCH] CF app: add "Returned: Needs more interest"

On 8/3/22 11:41, Andres Freund wrote: > What patches are we concretely talking about?> > My impression is that a lot of the patches floating from CF to CF have gotten > sceptical feedback and at best a minor amount of work to address that has been > done. -

Clarifying Commitfest policies

[was: CF app: add "Returned: Needs more interest"] On Wed, Aug 3, 2022 at 10:09 AM Julien Rouhaud wrote: > I'm afraid that > patches will still be left alone to rot and there still be no clear rules on > what to do and when, reminder for CFM and such, and that this new status would > never be

Re: [PATCH] CF app: add "Returned: Needs more interest"

On Wed, Aug 3, 2022 at 10:09 AM Julien Rouhaud wrote: > First of all, I didn't want to imply that rejecting a patch should be > pleasant, > sorry if that sounded that way. No worries, I don't think it really sounded that way. :D > It's not that I'm opposed to adding that status, I just don't

Re: [PATCH] CF app: add "Returned: Needs more interest"

On Tue, Aug 2, 2022 at 8:00 PM Julien Rouhaud wrote: > I'm personally fine with the current statutes, as closing a patch with RwF > explaining that there was no interest is still a feedback, Hi Julien, Making that explanation each time we intend to close a patch "needs interest" takes a lot of

Re: [Commitfest 2022-07] is Done!

On 8/1/22 16:08, Jacob Champion wrote: > "Today" was slightly optimistic. I'm down to the final stretch of forty > patches; I'll come back to those tomorrow with fresh eyes. All right, every entry from July has been closed out or moved! Apologies for dropping entries from c

Re: [PROPOSAL] new diagnostic items for the dynamic sql

On 8/2/22 15:09, Jacob Champion wrote: > I've carried it forward, but it needs some help to keep from stalling > out. Definitely make sure it's rebased and up to date by the time the > next CF starts, to give it the best chance at getting additional review > (if you haven't

Re: [PROPOSAL] new diagnostic items for the dynamic sql

>From looking at this patch and its history [1, 2], I think momentum was probably lost during the January CF, where this patch was unregistered (presumably by accident). I've carried it forward, but it needs some help to keep from stalling out. Definitely make sure it's rebased and up to date by

<    1   2   3   4   5   6   7   8   9   >