On Thu, Mar 28, 2024 at 3:34 PM Daniel Gustafsson wrote:
> In jsonapi.c, makeJsonLexContextCstringLen initialize a JsonLexContext with
> palloc0 which would need to be ported over to use ALLOC for frontend code.
Seems reasonable (but see below, too).
> On
> that note, the errorhandling in
On Thu, Feb 29, 2024 at 1:08 PM Daniel Gustafsson wrote:
> + /* TODO */
> + CHECK_SETOPT(actx, CURLOPT_WRITEDATA, stderr);
> I might be missing something, but what this is intended for in
> setup_curl_handles()?
Ah, that's cruft left over from early debugging, just so that I could
see what
On Wed, Feb 28, 2024 at 9:40 AM Daniel Gustafsson wrote:
> +#define ALLOC(size) malloc(size)
> I wonder if we should use pg_malloc_extended(size, MCXT_ALLOC_NO_OOM) instead
> to self document the code. We clearly don't want feature-parity with server-
> side palloc here. I know we use malloc in
> On 27 Feb 2024, at 20:20, Jacob Champion
> wrote:
>
> On Fri, Feb 23, 2024 at 5:01 PM Jacob Champion
> wrote:
>> The
>> patchset is now carrying a lot of squash-cruft, and I plan to flatten
>> it in the next version.
>
> This is done in v17, which is also now based on the two patches pulled
[re-adding the CC list I dropped earlier]
On Wed, Feb 28, 2024 at 1:52 PM Daniel Gustafsson wrote:
>
> > On 28 Feb 2024, at 22:50, Andrew Dunstan wrote:
> > Can you give some more details about what this python gadget would buy us?
> > I note that there are a couple of CPAN modules that
> On 28 Feb 2024, at 22:50, Andrew Dunstan wrote:
>
> On 2024-02-28 We 09:05, Jacob Champion wrote:
>>
>> Daniel and I discussed trying a Python version of the test server,
>> since the standard library there should give us more goodies to work
>> with. A proof of concept is in 0009. I think
On 2024-02-28 We 09:05, Jacob Champion wrote:
Daniel and I discussed trying a Python version of the test server,
since the standard library there should give us more goodies to work
with. A proof of concept is in 0009. I think the big question I have
for it is, how would we communicate what
> On 28 Feb 2024, at 15:05, Jacob Champion
> wrote:
>
> [Trying again, with all patches unzipped and the CC list temporarily
> removed to avoid flooding people's inboxes. Original message follows.]
>
> On Fri, Feb 23, 2024 at 5:01 PM Jacob Champion
> wrote:
>> The
>> patchset is now carrying
On Tue, Feb 27, 2024 at 11:20 AM Jacob Champion
wrote:
> This is done in v17, which is also now based on the two patches pulled
> out by Daniel in [1].
It looks like my patchset has been eaten by a malware scanner:
550 Message content failed content scanning
Hi all,
v14 rebases over latest and fixes a warning when assertions are
disabled. 0006 is temporary and hacks past a couple of issues I have
not yet root caused -- one of which makes me wonder if 0001 needs to
be considered alongside the recent pg_combinebackup and incremental
JSON work...?
On Tue, Dec 5, 2023 at 1:44 AM Daniel Gustafsson wrote:
>
> > On 8 Nov 2023, at 20:00, Jacob Champion wrote:
>
> > Unfortunately the configure/Makefile build of libpq now seems to be
> > pulling in an `exit()` dependency in a way that Meson does not.
>
> I believe this comes from the libcurl and
> On 8 Nov 2023, at 20:00, Jacob Champion wrote:
> Unfortunately the configure/Makefile build of libpq now seems to be
> pulling in an `exit()` dependency in a way that Meson does not.
I believe this comes from the libcurl and specifically the ntlm_wb support
which is often enabled in system
On Thu, Nov 9, 2023 at 5:43 PM Andrey Chudnovsky wrote:
> Do you plan to support adding an extension hook to validate the token?
>
> It would allow a more efficient integration, then spinning a separate process.
I think an API in the style of archive modules might probably be a
good way to go,
Hi Jacob,
Wanted to follow up on one of the topics discussed here in the past:
Do you plan to support adding an extension hook to validate the token?
It would allow a more efficient integration, then spinning a separate
process.
Thanks!
Andrey.
On Wed, Nov 8, 2023 at 11:00 AM Jacob Champion
On Fri, Nov 3, 2023 at 5:28 AM Shlok Kyal wrote:
> Just want to make sure you are aware of these failures.
Thanks for the nudge! Looks like I need to reconcile with the changes
to JsonLexContext in 1c99cde2. I should be able to get to that next
week; in the meantime I'll mark it Waiting on
Hi,
On Fri, 3 Nov 2023 at 17:14, Jacob Champion wrote:
>
> v12 implements a first draft of a client hook, so applications can
> replace either the device prompt or the entire OAuth flow. (Andrey and
> Mahendrakar: hopefully this is close to what you need.) It also cleans
> up some of the JSON
v11 is a quick rebase over the recent Cirrus changes, and I've dropped
0006 now that psycopg2 can build against BSD/Meson setups (thanks Daniele!).
--Jacob1: 0278c7ba90 = 1: 36409a76ce common/jsonapi: support FRONTEND clients
2: bb3ce4b6a9 = 2: 1356b729db libpq: add OAUTHBEARER SASL mechanism
On Tue, Jul 18, 2023 at 4:04 PM Thomas Munro wrote:
> On Tue, Jul 18, 2023 at 11:55 AM Jacob Champion
> wrote:
> +1 for EV_RECEIPT ("just tell me about errors, don't drain any
> events").
Sounds good.
> While comparing the cousin OSs' man pages just now, I noticed that
> it's not only macOS
On Tue, Jul 18, 2023 at 11:55 AM Jacob Champion wrote:
> We're not setting EV_RECEIPT for these -- is that because none of the
> filters we're using are EV_CLEAR, and so it doesn't matter if we
> accidentally pull pending events off the queue during the kevent() call?
+1 for EV_RECEIPT ("just
> > - Parameters are strings, so callback is not provided yet.
> > 2. Client gets PgConn from PQconnectStart return value and updates
> > conn->async_auth to its own callback.
>
> This is where some sort of official authn callback registration (see
> above reply to Daniele) would probably come
On Wed, Jul 12, 2023 at 5:50 AM Jacob Champion wrote:
> Oh, whoops, it's just the missed CLOEXEC flag in the final patch. (If
> the write side of the pipe gets copied around, it hangs open and the
> validator never sees the "end" of the token.) I'll switch the logic
> around to set the flag on
On Mon, Jul 10, 2023 at 4:50 PM Jacob Champion wrote:
> I don't understand why the
> server-side tests are failing on FreeBSD, but they shouldn't be using
> the libpq code at all, so I think your kqueue implementation is in the
> clear.
Oh, whoops, it's just the missed CLOEXEC flag in the final
On Fri, Jul 7, 2023 at 6:01 PM Thomas Munro wrote:
>
> On Fri, Jul 7, 2023 at 4:57 AM Jacob Champion wrote:
> > On Wed, Jul 5, 2023 at 3:07 PM Thomas Munro wrote:
> > > BTW I will happily do the epoll->kqueue port work if necessary.
> >
> > And I will happily take you up on that; thanks!
>
>
On Fri, Jul 7, 2023 at 2:16 PM Andrey Chudnovsky wrote:
> Please confirm my understanding of the flow is correct:
> 1. Client calls PQconnectStart.
> - The client doesn't know yet what is the issuer and the scope.
Right. (Strictly speaking it doesn't even know that OAuth will be used
for the
On Fri, Jul 7, 2023 at 4:57 AM Jacob Champion wrote:
> On Wed, Jul 5, 2023 at 3:07 PM Thomas Munro wrote:
> > BTW I will happily do the epoll->kqueue port work if necessary.
>
> And I will happily take you up on that; thanks!
Some initial hacking, about 2 coffees' worth:
Thanks Jacob for making progress on this.
> 3) Is the current conn->async_auth() entry point sufficient for an
> application to implement the Microsoft flows discussed upthread?
Please confirm my understanding of the flow is correct:
1. Client calls PQconnectStart.
- The client doesn't know
On Thu, Jul 6, 2023 at 1:48 PM Thomas Munro wrote:
> On Fri, Jul 7, 2023 at 4:57 AM Jacob Champion wrote:
> > Something analogous to libcurl's socket and timeout callbacks [1],
> > then? Or is there an existing libpq API you were thinking about using?
>
> Yeah. Libpq already has an event
On Fri, Jul 7, 2023 at 4:57 AM Jacob Champion wrote:
> On Wed, Jul 5, 2023 at 3:07 PM Thomas Munro wrote:
> > 2. Convert those events into new libpq events like 'I want you to
> > call me back in 100ms', and 'call me back when socket #42 has data',
> > and let clients handle that by managing
On Wed, Jul 5, 2023 at 3:07 PM Thomas Munro wrote:
> I guess there are a couple of ways to do it if we give up the goal of
> no-code-change-for-the-client:
>
> 1. Generalised PQsocket(), that so that a client can call something like:
>
> int PQpollset(const PGConn *conn, struct pollfd fds[], int
On Thu, Jul 6, 2023 at 9:00 AM Jacob Champion wrote:
> My goal is to maintain compatibility with existing PQconnectPoll()
> applications, where the only way we get to communicate with the client
> is through the PQsocket() for the connection. Ideally, you shouldn't
> have to completely rewrite
On Fri, Jun 30, 2023 at 9:29 PM Thomas Munro wrote:
>
> On Sat, May 20, 2023 at 10:01 AM Jacob Champion
> wrote:
> > - The client implementation is currently epoll-/Linux-specific. I think
> > kqueue shouldn't be too much trouble for the BSDs, but it's even more
> > code to maintain.
>
> I
On Sat, May 20, 2023 at 10:01 AM Jacob Champion wrote:
> - The client implementation is currently epoll-/Linux-specific. I think
> kqueue shouldn't be too much trouble for the BSDs, but it's even more
> code to maintain.
I guess you also need a fallback that uses plain old POSIX poll()? I
see
On 5/19/23 15:01, Jacob Champion wrote:
> But I don't want to
> gold-plate it if this overall approach is unacceptable. So, questions
> for the gallery:
>
> 1) Would starting up a background thread (pooled or not) be acceptable
> on Windows? Alternatively, does anyone know enough Winsock deep
On Tue, May 23, 2023 at 4:22 AM Daniele Varrazzo
wrote:
> On Sat, 20 May 2023 at 00:01, Jacob Champion wrote:
> > - Some clients in the wild (psycopg2/psycopg) suppress all notifications
> > during PQconnectPoll().
>
> If there is anything we can improve in psycopg please reach out.
Will do,
On Sat, 20 May 2023 at 00:01, Jacob Champion wrote:
> - Some clients in the wild (psycopg2/psycopg) suppress all notifications
> during PQconnectPoll().
If there is anything we can improve in psycopg please reach out.
-- Daniele
On Fri, Sep 23, 2022 at 3:39 PM Jacob Champion wrote:
> Here's a newly rebased v5. (They're all zipped now, which I probably
> should have done a while back, sorry.)
To keep this current, v7 is rebased over latest, without the pluggable
authentication patches. This doesn't yet address the
Greetings,
* Andrey Chudnovsky (achudnovs...@gmail.com) wrote:
> > This really doesn't feel like a great area to try and do hooks or
> > similar in, not the least because that approach has been tried and tried
> > again (PAM, GSSAPI, SASL would all be examples..) and frankly none of
> > them has
> This really doesn't feel like a great area to try and do hooks or
> similar in, not the least because that approach has been tried and tried
> again (PAM, GSSAPI, SASL would all be examples..) and frankly none of
> them has turned out great (which is why we can't just tell people "well,
>
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
> On Mon, Feb 20, 2023 at 2:35 PM Stephen Frost wrote:
> > Having skimmed back through this thread again, I still feel that the
> > direction that was originally being taken (actually support something in
> > libpq and the backend, be
Thanks for the feedback,
> Having skimmed back through this thread again, I still feel that the
> direction that was originally being taken (actually support something in
> libpq and the backend, be it with libiddawc or something else or even
> our own code, and not just throw hooks in various
On Mon, Feb 20, 2023 at 2:35 PM Stephen Frost wrote:
> Having skimmed back through this thread again, I still feel that the
> direction that was originally being taken (actually support something in
> libpq and the backend, be it with libiddawc or something else or even
> our own code, and not
Greetings,
* mahendrakar s (mahendrakarfo...@gmail.com) wrote:
> The "issuer" field has been removed to align with the RFC
> implementation - https://www.rfc-editor.org/rfc/rfc7628.
> This patch "v6" is a single patch to support the OAUTH BEARER token
> through psql connection string.
> Below
Hi All,
The "issuer" field has been removed to align with the RFC
implementation - https://www.rfc-editor.org/rfc/rfc7628.
This patch "v6" is a single patch to support the OAUTH BEARER token
through psql connection string.
Below flow is supported. Added the documentation in the commit messages.
> All of this points at a bigger question to the community: if we choose
> not to provide a flow implementation in libpq, is adding OAUTHBEARER
> worth the additional maintenance cost?
> My personal vote would be "no". I think the hook-only approach proposed
> here would ensure that only larger
On Sun, Jan 15, 2023 at 12:03 PM Andrey Chudnovsky
wrote:
> 2. Removed Device Code implementation in libpq. Several reasons:
>- Reduce scope and focus on the protocol first.
>- Device code implementation uses iddawc dependency. Taking this
> dependency is a controversial step which
More information on the latest patch.
1. We aligned the implementation with the barebone SASL for OAUTH
described here - https://www.rfc-editor.org/rfc/rfc7628
The flow can be explained in the diagram below:
+--+ +--+
|
Hi All,
Changes added to Jacob's patch(v2) as per the discussion in the thread.
The changes allow the customer to send the OAUTH BEARER token through psql
connection string.
Example:
psql -U u...@example.com -d 'dbname=postgres oauth_bearer_token=abc'
To configure OAUTH, the pg_hba.conf line
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
> The server hook is the right place to check the scopes, yes, but I think
> the DBA should be able to specify what those scopes are to begin with.
> The provider of the extension shouldn't be expected by the architecture
> to hardcode those decisions, even if Azure AD chooses to short-circuit
>
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
That being said, the Diagram 2 would look like this with our proposal:
+--+ +--+
| +---+ | Postgres |
| PQconnect ->| |
> 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 architectural violation: why does an OAuth resource server need
> to know
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
Jacob,
Thanks for your feedback.
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 spec. As well as details of usage
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.
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
Hi Jacob,
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.
Thanks,
Mahendrakar.
On Thu, 24 Nov
> How does this differ from the previous proposal? The OAUTHBEARER SASL
> mechanism already relies on OIDC for discovery. (I think that decision
> is confusing from an architectural and naming standpoint, but I don't
> think they really had an alternative...)
Mostly terminology questions here.
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
Hi,
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.
Also validated with OAuth provider Github.
We propose using OpenID Connect (OIDC) as
> I think we can probably prototype a callback hook for approach (1)
> pretty quickly. (2) is a lot more work and investigation, but it's
> work that I'm interested in doing (when I get the time). I think there
> are other very good reasons to consider a third-party SASL library,
> and some good
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
> The most concrete example I can see is with the OAUTHBEARER error
> response. If you want to eventually handle differing scopes per role,
> or different error statuses (which the proof-of-concept currently
> hardcodes as `invalid_token`), then the client can't assume it knows
> what the server
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
>>> Libpq passing toked directly from an upstream client is useful in other
>>> scenarios:
>>> 1. Enterprise clients, built with .Net / Java and using provider-specific
>>> authentication libraries, like MSAL for AAD. Those can also support more
>>> advanced provider-specific token acquisition
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).
Here's a newly
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
-hack...@postgresql.org; smilingsa...@gmail.com; and...@anarazel.de;
Andrey Chudnovskiy ; Mahendrakar Srinivasarao
Subject: [EXTERNAL] Re: [PoC] Federated Authn/z with OAUTHBEARER
[You don't often get email from jchamp...@timescale.com. Learn why this is
important at https://aka.ms
First, My message from corp email wasn't displayed in the thread,
That is what Jacob replied to, let me post it here for context:
> We can support both passing the token from an upstream client and libpq
> implementing OAUTH2 protocol to obtain one.
>
> Libpq implementing OAUTHBEARER is needed
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
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= oauth_bearer_token=
>
> This hurts,
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.
Hi Hackers,
We are trying to implement AAD(Azure AD) support in PostgreSQL and it
can be achieved with support of the OAuth method. To support AAD on
top of OAuth in a generic fashion (i.e for all other OAuth providers),
we are proposing this patch. It basically exposes two new hooks (one
for
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
Hi Jacob,
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.
(a) What specifically do the client side changes
On Fri, 2021-08-27 at 11:32 +0900, Michael Paquier wrote:
> Now if you'd really wish to
> stress that without relying on the backend, one simple way is to use
> pgbench -C -n with a mostly-empty script (one meta-command) coupled
> with some profiling.
Ah, thanks! I'll add that to the toolbox.
On Thu, Aug 26, 2021 at 04:13:08PM +, Jacob Champion wrote:
> Do you mean heap-based? i.e. destroyJsonLexContext() does an
> unnecessary copy before free? Yeah, in that case it's not super useful,
> but I think I'd want some evidence that the performance hit matters
> before optimizing it.
As
On Thu, Aug 26, 2021 at 9:13 AM Jacob Champion wrote:
> On Wed, 2021-08-25 at 15:25 -0700, Zhihong Yu wrote:
> >
> > Hi,
> > For v2-0001-common-jsonapi-support-FRONTEND-clients.patch :
> >
> > + /* Clean up. */
> > + termJsonLexContext();
> >
> > At the end of termJsonLexContext(), empty is
On Wed, 2021-08-25 at 15:25 -0700, Zhihong Yu wrote:
>
> Hi,
> For v2-0001-common-jsonapi-support-FRONTEND-clients.patch :
>
> + /* Clean up. */
> + termJsonLexContext();
>
> At the end of termJsonLexContext(), empty is copied to lex. For stack
> based JsonLexContext, the copy seems
On Wed, Aug 25, 2021 at 3:25 PM Zhihong Yu wrote:
>
>
> On Wed, Aug 25, 2021 at 11:42 AM Jacob Champion
> wrote:
>
>> On Tue, 2021-06-22 at 23:22 +, Jacob Champion wrote:
>> > On Fri, 2021-06-18 at 11:31 +0300, Heikki Linnakangas wrote:
>> > >
>> > > A few small things caught my eye in the
On Wed, Aug 25, 2021 at 11:42 AM Jacob Champion
wrote:
> On Tue, 2021-06-22 at 23:22 +, Jacob Champion wrote:
> > On Fri, 2021-06-18 at 11:31 +0300, Heikki Linnakangas wrote:
> > >
> > > A few small things caught my eye in the backend oauth_exchange
> function:
> > >
> > > > + /*
On Tue, Jun 22, 2021 at 11:26:03PM +, Jacob Champion wrote:
> Done [1, 2]. I've copied your comments into those threads with my
> responses, and I'll have them registered in commitfest shortly.
Thanks!
--
Michael
signature.asc
Description: PGP signature
On Fri, 2021-06-18 at 13:07 +0900, Michael Paquier wrote:
> On Tue, Jun 08, 2021 at 04:37:46PM +, Jacob Champion wrote:
> > 1. Prep
> >
> > 0001 decouples the SASL code from the SCRAM implementation.
> > 0002 makes it possible to use common/jsonapi from the frontend.
> > 0003 lets the
On Fri, 2021-06-18 at 11:31 +0300, Heikki Linnakangas wrote:
> On 08/06/2021 19:37, Jacob Champion wrote:
> > We've been working on ways to expand the list of third-party auth
> > methods that Postgres provides. Some example use cases might be "I want
> > to let anyone with a Google account read
On 08/06/2021 19:37, Jacob Champion wrote:
We've been working on ways to expand the list of third-party auth
methods that Postgres provides. Some example use cases might be "I want
to let anyone with a Google account read this table" or "let anyone who
belongs to this GitHub organization connect
On Tue, Jun 08, 2021 at 04:37:46PM +, Jacob Champion wrote:
> 1. Prep
>
> 0001 decouples the SASL code from the SCRAM implementation.
> 0002 makes it possible to use common/jsonapi from the frontend.
> 0003 lets the json_errdetail() result be freed, to avoid leaks.
>
> The first three
86 matches
Mail list logo
