On Wed, Apr 23, 2025 at 10:46 AM Jacob Champion
wrote:
> Are there any readers who feel like an internal ABI version for
> `struct pg_conn`, bumped during breaking backports, would be
> acceptable? (More definitively: are there any readers who would veto
> that?)
To keep things movi
On Fri, Apr 25, 2025 at 2:03 AM Christoph Berg wrote:
> My point is that we should be trying to change the ABI-as-coded-in-the-
> filename as rarely as possible.
I agree, but I'm also trying to say I can't unilaterally declare
pieces of our internal structs to be covered by an ABI guarantee.
Mayb
On Thu, Apr 24, 2025 at 3:16 PM Jelte Fennema-Nio wrote:
> Why is this dangerous? As long as we'd validate that the provided cert
> by the server is for example.com
I can't help but read this as "as long as everyone mitigates the
danger, what's the danger?" We won't be the only implementers of an
On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut wrote:
> Another detail to think about is how this affects psql -h localhost. In
> principle, this should require full SSL, but you're probably not going
> to have certificates that allow "localhost". And connections to
> localhost are the default
On Wed, Apr 23, 2025 at 8:47 AM George MacKerron wrote:
> I’d suggest two new special sslrootcert values:
>
> (1) sslrootcert=openssl
>
> This does exactly what sslrootcert=system does now, but is less confusingly
> named for Windows users. sslrootcert=system becomes a deprecated synonym for
> t
On Wed, Apr 23, 2025 at 1:13 PM Christoph Berg wrote:
> Uhm, so far the plan was to have one "libpq-oauth" package, not several.
I think the system is overconstrained at that point. If you want to
support clients that delay-load the ABI they're compiled against,
_and_ have them continue to work s
On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut wrote:
> I'm generally in favor of making sslmode=verify-full the effective
> default somehow.
+many
On Thu, Apr 24, 2025 at 3:53 AM Christoph Berg wrote:
> For
> postgresql://-style strings, we would ideally have something like http://
> vs http
On Thu, Apr 24, 2025 at 7:59 AM Tom Lane wrote:
> I'm still content with the idea of deciding that 3.6 is now our
> cutoff.
Seems like no one is pushing hard for an earlier version, yet, so
here's a patch with your suggested wording from upthread. I'm not sure
if this meets Peter's request for pr
On Wed, Apr 23, 2025 at 2:11 AM Jelte Fennema-Nio wrote:
> I'm confused. Are you intending to backport new test infra to PG18?
Not particularly (though, if the barriers were low enough, wouldn't
that be nice?). I'm talking about hazards in oauth_server.py here.
> Given the purpose and pretty sma
On Wed, Apr 23, 2025 at 4:24 AM Devrim Gündüz wrote:
> psycopg is included in RHEL 8, but PGDG packages are up2date (2.7.5 vs
> 2.9.5) so they override OS packages. That is why things will break.
Thanks, this is super helpful!
--Jacob
On Tue, Apr 22, 2025 at 12:45 PM Jacob Champion
wrote:
> Great, thanks for the quick review!
And pushed. Thanks everyone!
--Jacob
On Wed, Apr 23, 2025 at 9:38 AM Christoph Berg wrote:
> > We could all agree to bump the second number in the filename whenever
> > there's an internal ABI change. That works from a technical
> > perspective, but it's hard to test and enforce and... just not forget.
>
> It's hopefully not harder t
On Wed, Apr 23, 2025 at 8:39 AM Christoph Berg wrote:
> This will cause problems when programs are running while packages are
> updated on disk. That program then tries to dlopen 18-0.so when there
> is already 18-1.so installed. Relevant when the first oauth connection
> is made way after startup
On Tue, Apr 22, 2025 at 3:10 AM Daniel Gustafsson wrote:
> My preference is that no operation can silently work on a failed object, but
> it's not a hill (even more so given where we are in the cycle).
Hm, okay. Something to talk about with Andrew and Peter, maybe.
> The attached
> v3 allocates
On Tue, Apr 22, 2025 at 3:02 AM Daniel Gustafsson wrote:
> + if oauth_flow_supported
> +cdata.set('USE_LIBCURL', 1)
> + elif libcurlopt.enabled()
> +error('client OAuth is not supported on this platform')
> + endif
> We already know that libcurlopt.enabled() is true here so maybe just d
On Tue, Apr 22, 2025 at 3:17 PM Jelte Fennema-Nio wrote:
> The way you replaced this does not have the same behaviour in the case
> where the prefix/suffix is not part of the string. removeprefix/suffix
> will not remove any characters in that case, but your code will always
> remove the number of
On Tue, Apr 22, 2025 at 3:04 PM Tom Lane wrote:
> The fact that Jacob was able to fix
> oauth_server.py without (it seemed like) very much work seems to
> bear out that opinion.
I think my ability to do it should not be used as evidence of "ease".
I knew where to download 3.6, that I should buil
On Tue, Apr 22, 2025 at 2:43 PM Renan Alves Fonseca
wrote:
> I did a quick test on 3.5.
Thanks!
> It seems to work after removing
> f-strings... At this point, I would be really happy with 3.6.
Ah, makes sense. Well, I'm starting with the 3.6 fix regardless, since
it's preventing RHEL8 testing.
On Tue, Apr 22, 2025 at 2:28 PM Jelte Fennema-Nio wrote:
> I'm pretty sure most users of RHEL expect most modern software not to
> compile/work completely effortlessly on their distros without some
> effort on their part or on the part of RHEL packagers. That's kinda
> what you're signing up for i
On Tue, Apr 22, 2025 at 12:36 PM Tom Lane wrote:
> Thanks! I confirm this works for me on RHEL8 with 3.6.8.
Great, thanks for the quick review!
I'm considering committing this myself. Do you mind if it takes a day
or so to get this in, while I quadruple-check everything, or are you
blocked on t
On Tue, Apr 22, 2025 at 12:09 PM Renan Alves Fonseca
wrote:
> The oldest non EOL version is 3.9 right now. My suggestion is to follow
> the official supported releases.
I think this policy is too aggressive. Many operating systems we
support are going to ship Python versions past their EOL date (
On Tue, Apr 22, 2025 at 8:29 AM Jacob Champion
wrote:
> On Tue, Apr 22, 2025 at 8:05 AM Tom Lane wrote:
> > The first problem is that this Python version seems not to
> > like assignments embedded in if statements: [...]
> >
> > I was able to work around that w
On Tue, Apr 22, 2025 at 9:04 AM Tom Lane wrote:
> I'm also not excited by the idea that an incidental
> test script gets to dictate what the cutoff is.
I agree, and I don't intend for the script to dictate that.
> Maybe it's sufficient to make a documentation change here, and
> say we support Py
On Tue, Apr 22, 2025 at 8:05 AM Tom Lane wrote:
> The first problem is that this Python version seems not to
> like assignments embedded in if statements: [...]
>
> I was able to work around that with the attached quick hack.
> But then I get [...]
Thanks, I'll put a patch together. Sorry -- IIRC
: libpq = declare_dependency(
+ # libpq-oauth needs libcurl. Put both into *.private.
+ private_deps += [
+libpq_oauth_deps,
-+'-lpq-oauth-@0@'.format(pg_version_major),
++'-lpq-oauth',
+ ]
+endif
+
@@ src/test/modules/oauth_val
On Mon, Apr 21, 2025 at 11:46 AM Daniel Gustafsson wrote:
> We do, but with the current coding we call setJsonLexContextOwnsTokens
> immediately after creation which derefences the pointer without checkinf for
> allocation failure.
Right. (The flag does nothing on the OOM sentinel.)
> This means
On Mon, Apr 21, 2025 at 11:20 AM Daniel Gustafsson wrote:
> Sure, but I fear we'll get an endless stream of static analysis reports for
> the
> allocation leaking if we don't free it.
But we do free it, in freeJsonLexContext(). That usage of the API goes
back to 2023, with 1c99cde2f344. Or am I
On Sun, Apr 20, 2025 at 10:12 AM Ivan Kush wrote:
> I'm testing OAuth Device Flow implementation on Google. Met several
> problems.
Hi Ivan, thank you for testing and reporting! Unfortunately, yeah,
Google is a known problem [1]. They've taken several liberties with
the spec, as you point out.
W
On Sat, Apr 19, 2025 at 2:15 PM Daniel Gustafsson wrote:
> Since there is no way to determine if the allocation succeeded from outside of
> the JSON api it might be better to keep the calloc and explicitly free it?
I don't think so; pg_parse_json() will error out quickly, so I don't
see much adva
On Tue, Apr 15, 2025 at 11:11 PM Jelte Fennema-Nio wrote:
> On Wed, 16 Apr 2025 at 02:03, Jacob Champion
> wrote:
> > Thank you for saying something; I'd hallucinated that srvoptions was
> > limited to the server owner, and that's not true. It's pg_user_ma
On Fri, Apr 18, 2025 at 12:46 PM Tom Lane wrote:
> * The commented-out tests in 001_ssltests.pl contained hard-wired
> expectations as to certificate serial numbers, which are obsolete now.
> I just replaced them with "\d+", but if anyone feels like that's not
> good enough, we could continue to c
On Tue, Apr 15, 2025 at 2:38 PM Jelte Fennema-Nio wrote:
> libpq_append_conn_error(conn, "no custom OAuth flows are available,
> and libpq-oauth could not be loaded library could not be loaded. Try
> installing the libpq-oauth package from the same source that you
> installed libpq from");
Thanks
On Thu, Apr 17, 2025 at 5:47 PM Jacob Champion
wrote:
> With those, I have no more TODOs and I believe this is ready for a
> final review round.
Some ABI self-review. These references to conn->errorMessage also need
the indirection treatment, which I'm working on now:
>
On Thu, Apr 17, 2025 at 8:20 AM Tom Lane wrote:
> I confirm this silences those warnings on my Fedora 41 box.
Instead of doing
lex = calloc(...);
/* (error out on NULL return) */
makeJsonLexContextCstringLen(lex, ...);
we need to do
lex = makeJsonLexContextCstringLen(NULL, ...)
On Wed, Apr 16, 2025 at 4:04 PM Tom Lane wrote:
> Looking through all of the callers of freeJsonLexContext, quite
> a lot of them use local JsonLexContext structs, and probably some
> of them are more performance-critical than these. So that raises
> the question of why are we seeing warnings for
On Tue, Apr 15, 2025 at 3:25 PM Jelte Fennema-Nio wrote:
> I don't understand why it should be a server option instead of a user
> mapping option. Having it be a server option means that *any* Postgres
> user can read its contents.
Thank you for saying something; I'd hallucinated that srvoptions
On Tue, Apr 15, 2025 at 1:48 PM Noah Misch wrote:
> If we think oauth_client_secret should get dispchar="*" UI treatment yet be a
> postgres_fdw server option, postgres_fdw code can make it so. postgres_fdw
> already has explicit code to reclassify the "user" option.
Agreed, I will add an open i
On Tue, Apr 15, 2025 at 12:14 PM Noah Misch wrote:
> I suspect this should use .dispchar="*" to encourage UIs to display
> oauth_client_secret like a password field. Thoughts?
Hmm, from a UI perspective I agree. (The builtin flow targets "public
clients", where secrets are discouraged and/or und
On Tue, Apr 15, 2025 at 12:21 PM Robert Haas wrote:
> I also don't mind being wrong, of course. But I think it's better to
> bet on making this like other things and then change strategy if that
> doesn't work out, rather than starting out by making this different
> from other things.
Works for m
On Tue, Apr 15, 2025 at 11:57 AM Christoph Berg wrote:
> What made me reconsider was Peter saying that what defines the blast
> radius of some feature is usually the extra dependency pulled in. If
> you don't like tracking OpenSSL problems, build without it. If you
> don't like libcurl, build with
On Tue, Apr 15, 2025 at 8:34 AM Christoph Berg wrote:
> I agree with this reasoning and retract my suggestion to rename the option.
(Thank you for chiming in; having the packager feedback has been
extremely helpful.)
While I have you, may I ask whether you're okay (from the packager
perspective)
On Tue, Apr 15, 2025 at 5:31 AM Peter Eisentraut wrote:
> On 10.04.25 01:08, Jacob Champion wrote:
> > Christoph noted that this was also confusing from the packaging side,
> > earlier,
Since Christoph has withdrawn the request, I will drop -0002.
However, I'll go ahea
On Mon, Apr 14, 2025 at 1:17 PM Jacob Champion
wrote:
> I believe so. I'm in the middle of the .pc stuff right now; v6 should
> have the fixes as long as I don't get stuck.
Done in v6-0001. I think this is now architecturally complete, so if
reviewers are happy I can work on doc
On Mon, Apr 14, 2025 at 1:16 PM Daniel Gustafsson wrote:
> Just to close the loop, this was done yesterday as 2970c75dd982.
Thanks!
--Jacob
On Mon, Apr 14, 2025 at 12:46 PM Wolfgang Walther
wrote:
> But that means we'd need a -lpq-oauth-18 or something like that in
> Libs.private in libpq.pc, right?
I believe so. I'm in the middle of the .pc stuff right now; v6 should
have the fixes as long as I don't get stuck.
Thanks,
--Jacob
On Mon, Apr 14, 2025 at 11:27 AM Wolfgang Walther
wrote:
>src/interfaces/libpq-oauth/meson.build:18:22: ERROR: File
> oauth-curl.c does not exist.
>
> This.. clears it up, because that file is indeed missing for me on disk.
Aha! Okay, glad I don't need to track that down.
> libpq.a
> libpq-o
On Fri, Apr 11, 2025 at 9:21 AM Wolfgang Walther
wrote:
> I tried to apply this patch to nixpkgs' libpq build [1]. First, I pinned
> a recent commit from master (one where the v5 patch will apply cleanly
> later) and enabled --with-libcurl [2].
(The [2] link is missing, I think.)
> 2. The static
On Wed, Apr 9, 2025 at 4:48 AM Daniel Gustafsson wrote:
> -extern const pg_be_sasl_mech pg_be_oauth_mech;
> +extern PGDLLIMPORT const pg_be_sasl_mech pg_be_oauth_mech;
> +1 on this.
LGTM, too.
Thanks!
--Jacob
On Wed, Apr 9, 2025 at 4:42 PM Jelte Fennema-Nio wrote:
> I think your suggestion of not using any .so files would best there (from w
> user perspective). I'd be quite surprised if a static build still resulted in
> me having to manage shared library files anyway.
Done this way in v5. I had pla
On Wed, Apr 9, 2025 at 1:14 AM Christoph Berg wrote:
> One design goal could be reproducible builds-alike, that is, have
> libpq configured with or without libcurl be completely identical, and
> the feature being present is simply the libpq-oauth.so file existing
> or not. That might make using pl
On Tue, Apr 8, 2025 at 9:02 AM Wolfgang Walther wrote:
> How does the proposal with a loadable module affect a static libpq.a?
The currently proposed patch would have you package and install a
separate .so module implementing OAuth, which the staticlib would load
once when needed. Similarly to ho
On Tue, Apr 8, 2025 at 2:32 PM Jacob Champion
wrote:
> I think the module should be using
> libpq's libpq_gettext(). (Which we could do, again through the magic
> of dependency injection.)
To illustrate what I mean, v3 introduces an initialization function
that names the
On Mon, Apr 7, 2025 at 10:05 AM Andres Freund wrote:
> On 2025-04-07 09:41:25 -0700, Jacob Champion wrote:
> > Ah, you mean if the RPATH'd build doesn't have a flow, but the
> > globally installed one (with a different ABI) does? Yeah, that would
> > be a problem.
> Maybe it would also make sense to make libpq-oauth a subdirectory of the
> libpq directory instead of a peer.
Works for me.
On Mon, Apr 7, 2025 at 7:21 AM Andres Freund wrote:
> On 2025-04-04 17:27:46 -0700, Jacob Champion wrote:
> > +This module ABI is an internal implementat
On Thu, Apr 10, 2025 at 7:41 AM Dave Cramer wrote:
> Done in new patch attached
I think this patch splices a sentence:
> + not equal to the version the server supports.
> message.
+1 for clarifying the message description; it has vaguely bothered me
for a while [1]. :)
--Jaco
On Wed, Apr 9, 2025 at 10:44 AM Christoph Berg wrote:
>
> Re: Jacob Champion
> > > How about ifdef-ing away the dlopen call if --with-libcurl is not
> > > specified.
> >
> > This sounds like a pretty decent, simple way to go. Christoph, does
> > that
Hello,
On Thu, Apr 3, 2025 at 8:51 AM Daniel Gustafsson wrote:
> Committed, after another round of testing and looking.
I think we may want to consider marking sslkeylogfile as a debug
option (that is, opt->dispchar = "D") in fe-connect.c. Besides being a
true "debug option", this would also pre
On Mon, Apr 7, 2025 at 2:58 PM Christoph Berg wrote:
> Why is this module worse? (I guess the answer is internal data
> structures... but does it have to be worse?)
It doesn't have to be, in general, and the coupling surface is small
enough (libpq_append_conn_error) that we have a relatively easy
On Mon, Apr 7, 2025 at 9:41 AM Jacob Champion
wrote:
> > Not sure, the code looks correct at first glance. However, you could
> > also just keep the libpq-oauth strings in the libpq catalog. There
> > isn't really a need to make a separate one, since the versions you en
On Tue, Apr 8, 2025 at 3:34 AM Daniel Gustafsson wrote:
> > On 8 Apr 2025, at 04:10, Jacob Champion
> > wrote:
> > Hm, one immediate consequence of hardcoding pkglibdir is that we can
> > no longer rely on LD_LIBRARY_PATH for pre-installation testing.
> > (Cont
On Tue, Apr 8, 2025 at 11:25 AM Bruce Momjian wrote:
> However, is this
> true for libpq libraries or database server libraries. Does it matter?
The dependency on Curl is through libpq. We have some server-side
features that pull in libpq and would transitively depend on Curl. But
for Curl to be
On Tue, Apr 8, 2025 at 10:36 AM Jacob Champion
wrote:
> Yeah, but it's one of those things that feels like it must have been
> solved by the others in the space. Once it's installed, the concern
> goes away (unless you demand absolute relocatability without
> recompilation
On Tue, Apr 8, 2025 at 10:10 AM Wolfgang Walther
wrote:
> And if that means making libpq modular at run-time, then this should be
> planned and built with all deps, and other use-cases (like static linking) in
> mind - and not like it is right now.
I think that'd be neat in concept, but specifi
On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther wrote:
> This means that shipping another .so file will not happen with this approach.
> Assuming OAuth will be picked up by some of the bigger providers, that
> would... make me feel quite bad about it, actually.
It occurs to me that I didn't res
On Tue, Apr 8, 2025 at 10:15 AM Bruce Momjian wrote:
> Well, if we think we are going to do that, it seems we would need a
> different architecture than the one being proposed for PG 18, which
> could lead to a lot of user/developer API churn.
A major goal of the current patch proposal is to expl
On Tue, Apr 8, 2025 at 9:57 AM Wolfgang Walther wrote:
> if it's really the case that cURL is that much worse
(it is not, but I am sympathetic to the argument that if you don't use
it, you don't need it in the process space)
> However, if the other deps are considered problematic as well, then t
On Tue, Apr 8, 2025 at 9:49 AM Bruce Momjian wrote:
> On Tue, Apr 8, 2025 at 09:43:01AM -0700, Jacob Champion wrote:
> > By adding the new .so to a different package. For example, RPM specs
> > would just let you say "hey, this .so I just built doesn't go into the
&g
On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther wrote:
> And that should also not be a problem for distributions - they could offer a
> libpq and a libpq_oauth package, where only one of them can be installed at
> the same time, I guess? *
My outsider understanding is that maintaining this sort
On Tue, Apr 8, 2025 at 9:33 AM Bruce Momjian wrote:
> On Tue, Apr 8, 2025 at 09:17:03AM -0700, Jacob Champion wrote:
> > It allows packagers to ship the OAuth library separately, so end users
> > that don't want the additional exposure don't have to install it at
> &
On Tue, Apr 8, 2025 at 9:14 AM Bruce Momjian wrote:
> How does this patch help us avoid having to handle curl CVEs and its
> curl's additional dependencies? As I understand the patch, it makes
> libpq _not_ have additional dependencies but moves the dependencies to a
> special loadable library th
On Tue, Apr 8, 2025 at 7:32 AM Bruce Momjian wrote:
> Uh, where are we on the inclusion of curl in our build? Maybe it was
> explained but I have not seen it.
The above is discussing a patch to split this into its own loadable
module. Andres and Christoph's feedback has been shaping where we put
On Mon, Apr 7, 2025 at 3:26 PM Jacob Champion
wrote:
> Sounds good. Any opinions from the gallery on what a "libpq plugin
> subdirectory" in pkglibdir should be called? ("client", "modules",
> "plugins"...?)
Hm, one immediate consequence of hard
On Mon, Apr 7, 2025 at 11:47 AM Christoph Berg wrote:
> Mmmmh. Since we are currently only talking about 3 symbols, it doesn't
> sound very likely that we'd have to bump this in a major branch.
The ABI extends to the pointers we're using, though. This module uses
PGconn* internals and libpq-int.h
On Tue, Mar 18, 2025 at 9:09 PM Thomas Munro wrote:
> All pushed (wasn't sure if Daniel was going to but once I got tangled
> up in all that kqueue stuff he probably quite reasonably assumed that
> I would :-)).
Attached are two more followups, separate from the libcurl split:
- 0001 is a patch o
On Mon, Mar 31, 2025 at 4:09 PM Jacob Champion
wrote:
> I don't have hurd-amd64 to test, but I'm working on a patch that will
> build and pass tests if I manually munge pg_config.h. We were skipping
> the useless tests via a $windows_os check; I think I should use
> che
On Wed, Apr 2, 2025 at 7:15 AM George MacKerron wrote:
> > But happily, I don’t think we need to choose. Can’t we just use the Windows
> > system store if neither of the relevant environment variables is set?
>
> Thinking about this a little more, I guess the remaining concern is about
> people
On Thu, Apr 3, 2025 at 12:50 PM Daniel Gustafsson wrote:
> Thanks, both LGTM so pushed.
Thank you!
On Tue, Apr 1, 2025 at 3:40 PM Jacob Champion
wrote:
> Maybe a better idea would be to ship an SONAME of
> `libpq-oauth.so.0.`, without any symlinks, so that there's
> never an
On Mon, Mar 31, 2025 at 9:01 AM Seth Robertson
wrote:
> Third, the only real use case where this feature would be critical is
> a client which needs to have connections to two different PostgreSQL
> servers at the same time. Those applications are likely fairly rare
> and doing custom programming
eems
like it'd be kind of nice in theory. I'm not sure how many people
would notice, though.
On Wed, Mar 26, 2025 at 12:09 PM Jacob Champion
wrote:
> Right
> now we have an SO version of 1; maybe we want to remove the SO version
> entirely to better indicate that it shouldn&
On Tue, Apr 1, 2025 at 2:05 PM George MacKerron wrote:
>
> I was very pleased to see the sslrootcert=system connection option added in
> Postgres 16 (I even blogged about it:
> https://neon.tech/blog/avoid-mitm-attacks-with-psql-postgres-16). But
> sslrootcert=system has not been widely support
On Tue, Apr 1, 2025 at 6:12 AM Daniel Gustafsson wrote:
>
> > On 1 Apr 2025, at 15:03, Christoph Berg wrote:
>
> > With the libpq-oauth split, this makes even more sense because
> > building a library that always throws an error isn't very useful.
> > (Don't build that file at all if the feature
On Mon, Mar 31, 2025 at 2:54 PM Christoph Berg wrote:
>
> > Add support for OAUTHBEARER SASL mechanism
>
> Debian still has this experimental port with a GNU userland and a
> FreeBSD kernel called kfreebsd. I don't expect anyone to particularly
> care about it, but it found an actual bug:
>
> /bui
On Fri, Mar 21, 2025 at 11:02 AM Daniel Gustafsson wrote:
> >> How about we provide the current libpq.so without linking to curl and also
> >> a
> >> libpq-oauth.so that has curl support? If we do it right libpq-oauth.so
> >> would
> >> itself link to libpq.so, making libpq-oauth.so a fairly sma
Great, thank you! Looking over v10, I think I've run out of feedback
at this point. Marked Ready for Committer.
--Jacob
On Thu, Mar 20, 2025 at 12:54 PM Matheus Alcantara
wrote:
> Since the security checks are defined I'm attaching 0003 which include
> the fix of security checks for postgres_fdw. It implements the
> validations very similar to what are being implemented on dblink.
Comments on 0003:
> +
Hi all,
With the understanding that the patchset is no longer just "my" baby...
= Dependencies =
I like seeing risk/reward discussions. I agonized over the choice of
HTTP dependency, and I transitioned from an "easier" OAuth library
over to Curl early on because of the same tradeoffs.
That said
On Thu, Mar 20, 2025 at 6:11 AM Jelte Fennema-Nio wrote:
> I'm not saying there's no attack possible here (although I cannot
> think of one), but we allow configuring every other SSL option using
> an env var^1. So if there is an attack possible, why would that only
> apply to being able to contro
On Thu, Mar 20, 2025 at 3:58 AM Heikki Linnakangas wrote:
>
> I'm not sure if openssl has some locking on it,
OpenSSL leaves it up to the application (us). OpenSSL 3.5 will
apparently add a builtin implementation, which from a quick skim does
use locking. As another datapoint, libcurl's implement
On Tue, Mar 18, 2025 at 12:32 PM Peter Eisentraut wrote:
> Yeah, I think option (2) is enough for now. If someone wants to enable
> the kinds of things you describe, they can always come back and
> implement option (1) later.
Sounds good to me.
--
Notes on v8:
- The following documentation pi
On Tue, Mar 18, 2025 at 5:43 AM Daniel Gustafsson wrote:
> Personally I think this feature has enough value even without the env var to
> not postpone it, especially since adding an env var in 19 will still be
> backwards compatible. I would go for option 1 to stay on the safe side and
> allow ti
On Tue, Mar 18, 2025 at 9:35 AM Peter Eisentraut wrote:
> So the way I understand this is that the options are:
>
> (1) We add a libpq function like PQconnectionUsedScramKeys() in the
> style of PQconnectionUsedPassword() and call that function during the
> checks.
>
> (2) We make use_scram_passth
On Thu, Mar 13, 2025 at 2:41 PM Daniel Gustafsson wrote:
> OpenSSL 3.4 also doesn't like it and AFAICT neither does the upcoming 3.5,
> just
> haven't had the cycles yet to ship out a new patch with all the time-consuming
> testing it requires =)
Here is a squash fix to change the capitalization
On Mon, Mar 17, 2025 at 11:54 AM Matheus Alcantara
wrote:
> > If the check functions aren't going to check those because it's
> > unnecessary, then that's fine, but then the comments should be
> > adjusted.
> >
> Ok, now I get all of your points. I've misinterpreted your comments,
> sorry about th
On Thu, Mar 13, 2025 at 10:56 AM Andres Freund wrote:
> > Given the choice between a usually-working PAM module with known
> > architectural flaws, and not having PAM at all, I think many users
> > would rather continue using what's working for them.
>
> authentication_timeout currently doesn't re
On Thu, Mar 13, 2025 at 2:38 PM Matheus Alcantara
wrote:
> I thought about this; The problem is that at this point, the scram keys
> on connection options are base64 encoded (see appendSCRAMKeysInfo), so
> we can't compare with the values stored on MyProcPort.
I don't think that's necessary -- th
On Sun, Mar 16, 2025 at 6:14 AM vignesh C wrote:
> @Jacob, could you find some time to wrap this up? This will help us
> assess whether it can be refined into a committable state soon.
This is a bug report that likely requires backpatching; feature freeze
should not be an issue here.
Thanks,
--J
On Sun, Mar 16, 2025 at 6:49 AM Daniel Gustafsson wrote:
> IIRC the reasoning has been that if a rogue user can inject an environment
> variable into your session and read your files it's probably game over
> anyways.
(Personally I'm no longer as convinced by this line of argument as I
once was.
On Mon, Mar 17, 2025 at 4:37 AM Nazir Bilal Yavuz wrote:
>
> Hi,
>
> I just wanted to report that the 'oauth_validator/t/001_server.pl'
> test failed on FreeBSD in one of my local CI runs [1]. I looked at the
> thread but could not find the same error report; if this is already
> known, please exc
On Tue, Mar 4, 2025 at 4:05 PM Daniel Gustafsson wrote:
> > On 4 Mar 2025, at 20:19, Daniel Gustafsson wrote:
> > Thanks for the reminder, this is sitting on my must-have TODO for 18 and I
> > agree that we should add x25519 to the default set.
>
> And to add some code for that proposal, the atta
On Thu, Mar 13, 2025 at 2:41 PM Daniel Gustafsson wrote:
> OpenSSL 3.4 also doesn't like it and AFAICT neither does the upcoming 3.5
Hm. FWIW, I have no issues locally with 3.4 or 3.5-alpha. Only with LibreSSL.
--Jacob
1 - 100 of 1152 matches
Mail list logo
