On Thu, Jun 13, 2024 at 12:20 PM Robert Haas wrote:
> I interpreted Jacob's original email as articulating a goal ("For the
> v18 cycle, I would like to try to get pytest [1] in as a supported
> test driver, in addition to the current offerings") rather than a
> plan.
That's the first part of it.
On Thu, Jun 13, 2024 at 11:11 AM Robert Haas wrote:
> I feel like I already agreed to this in a previous email and you're
> continuing to argue with me as if I were disagreeing.
I also think that maybe arguments are starting to sail past each
other, and the temperature is starting to climb. (And
On Thu, Jun 13, 2024 at 1:04 PM Robert Haas wrote:
> One caveat here,
> perhaps, is that the focus of the work you've done up until now and
> the things that I and other community members may want as a condition
> of merging stuff may be somewhat distinct. You will have naturally
> been focused on
On Thu, Jun 13, 2024 at 1:27 PM Robert Haas wrote:
>
> On Thu, Jun 13, 2024 at 4:06 PM Jacob Champion
> wrote:
> > There was a four-step plan sketch at the end of that email, titled "A
> > Plan". That was not intended to be "the final detailed plan", bec
On Mon, Apr 29, 2024 at 8:24 AM Heikki Linnakangas wrote:
> I was mostly worried about the refactoring of the
> retry logic in libpq (and about the pre-existing logic too to be honest,
> it was complicated before these changes already).
Some changes in the v17 negotiation fallback order caught my
On Mon, Jun 17, 2024 at 8:24 AM Heikki Linnakangas wrote:
> By "negotiation", which part of the protocol are we talking about
> exactly? In the middle of the TLS handshake? After sending the startup
> packet?
By "negotiation" I mean the server's response to the startup packet.
I.e. "supported"/"n
On Mon, Jun 17, 2024 at 10:01 AM Andres Freund wrote:
> On 2024-06-17 12:00:30 +0200, Daniel Gustafsson wrote:
> > To set the specified curve in ssl_ecdh_curve we have to don't we?
>
> Sure, but it's not obvious to me why we actually want to override openssl's
> defaults here. There's not even a p
(slowly catching up from the weekend email backlog)
On Fri, Jun 14, 2024 at 5:10 AM Robert Haas wrote:
> I mean, both Perl and Python are Turing-complete.
Tom responded to this better than I could have, but I don't think this
is a helpful statement. In fact I opened the unconference session with
On Fri, Jun 14, 2024 at 8:49 AM Tom Lane wrote:
> I think that's an oversimplified analysis. Sure, the languages are
> both Turing-complete, but for our purposes here they are both simply
> glue languages around some set of testing facilities. Some of those
> facilities will be provided by the b
On Mon, Jun 17, 2024 at 9:23 AM Jacob Champion
wrote:
> > I think the behavior with v2 and v3 errors should be the same. And I
> > think an immediate failure is appropriate on any v2/v3 error during
> > negotiation, assuming we don't use those errors for things like "T
On Thu, Jun 20, 2024 at 4:13 PM Heikki Linnakangas wrote:
> > By "negotiation" I mean the server's response to the startup packet.
> > I.e. "supported"/"not supported"/"error".
>
> Ok, I'm still a little confused, probably a terminology issue. The
> server doesn't respond with "supported" or "not
On Thu, Jun 20, 2024 at 4:32 PM Jacob Champion
wrote:
> Thanks,
> --Jacob
Hey Heikki,
[sending this to the list in case it's not just me]
I cannot for the life of me get GMail to deliver your latest message,
even though I see it on postgresql.org. It's not in spam; it's j
On Tue, Jun 25, 2024 at 7:20 AM Dave Cramer wrote:
>
> On Tue, 25 Jun 2024 at 09:37, Vladimir Sitnikov
> wrote:
>>
>> "SSL". Technically, the proper term is TLS, and even the document refers to
>> "IANA TLS ALPN Protocol IDs" (TLS, not SSL).
>> I would not die on that hill, however, going for t
On Sun, Jun 30, 2024 at 10:48 AM Noah Misch wrote:
> That looks like a reasonable user experience. Is any field newly-nullable?
Technically I think the answer is no, since backends such as walwriter
already have null database and user fields. It's new for a client
backend to have nulls there, th
On Fri, Jun 28, 2024 at 12:11 AM Peter Eisentraut wrote:
> This appears to imply that specifying ldapurl is only applicable for
> search+bind. Maybe that whole message should be simplified to something
> like
>
> "configuration mixes arguments for simple bind and search+bind"
>
> (The old wording
On Fri, Jul 12, 2024 at 7:59 AM Mohab Yaser
wrote:
>
> So if anyone faced the same problem please let me know.
I agree that it's rough at the moment. I don't pretend to have any
solutions, but you might check the Bug Fixes section of the current
Commitfest, to help review:
https://commitfest
On Mon, Jul 10, 2023 at 10:19 AM Reid Thompson wrote:
> I made a another pass through the separated patches, it looks good to
> me.
LGTM too. (Thanks Tom for the clarification on ECPG.)
Marked RfC.
--Jacob
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 co
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
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 misse
Thanks for the reviews, both of you!
On Fri, Jul 14, 2023 at 5:04 AM Andrew Dunstan wrote:
> Seems reasonable at first glance. Isn't it going to save some work anyway
> later on, so the performance hit could end up negative?
Theoretically it could, if the OID list sent during getPolicies()
shri
Hello,
Thanks for working on this! We're interested in RPR as well, and I've
been trying to get up to speed with the specs, to maybe make myself
useful.
On 6/27/23 17:58, Tatsuo Ishii wrote:
> Yes. (I think the standard calls the window frame as "full window
> frame" in context of RPR to make a c
sure how to
choose a threshold.
It would also be neat if `COUNT(col)` could push down
SK_SEARCHNOTNULL, but I think that would require a new support
function to rewrite the plan for an aggregate.
Am I on the right track?
Thanks,
--Jacob
From 45ed1948b6aac4fc8a268a77211327786fd4315f Mon Sep 17 00:00:
Hi Ishii-san,
On 7/19/23 22:15, Tatsuo Ishii wrote:
> Currently my patch has a limitation for the sake of simple
> implementation: a pattern like "A+" is parsed and analyzed in the raw
> parser. This makes subsequent process much easier because the pattern
> element variable (in this case "A") and
On 7/20/23 17:07, Vik Fearing wrote:
> On 7/21/23 01:36, Jacob Champion wrote:
>> (I've attached two failing tests against v2, to hopefully better
>> illustrate, along with what I_think_ should be the correct results.)
>
> Almost. You are matching 07-01-2023 but the
On 7/20/23 23:16, Tatsuo Ishii wrote:
> I don't know at this point. I think context-free is not enough to be
> repsented in Bison. The grammer also needs to be LALR(1). Moreover,
> adding the grammer to existing parser may generate shift/reduce
> errors.
Ah. It's been too long since my compilers
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
On Tue, Aug 1, 2023 at 9:31 AM Bharath Rupireddy
wrote:
> Thanks. Finally, I started to spend time on this. Just curious - may
> I know the discussion in/for which this patch is referenced? What was
> the motive? Is it captured somewhere?
It may not have been the only place, but we at least touc
On Tue, Aug 1, 2023 at 9:00 AM Nathan Bossart wrote:
> >> On 1 Aug 2023, at 09:45, Peter Eisentraut wrote:
> >> But who would use that, other than, you know, you, right now?
/me raises hand
Or at least, me back when I was hacking on pg_upgrade performance.
This, or something like it, would have
void *arg)
}
+/*
-+ * getTablesWithPolicies TODO
++ * getTablesWithPolicies
++ * retrieve the IDs of all tables with pg_policy entries
+ */
+void
+getTablesWithPolicies(Archive *fout)
From 637393950006c3752c6db3ca64f84b18fcaa4896 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Dat
On Tue, Aug 15, 2023 at 3:24 PM Michael Paquier wrote:
> The first message from Jacob outlines the idea behind the handling of
> trust. We could perhaps add one extra set_authn_id() for the uaTrust
> case (not uaCert!) if that's more helpful.
I'm not super comfortable with saying "connection aut
ction", especially in
combination with the existing "connection authenticated" lines.
(I'm reminded that we're reflecting an unauthenticated username as-is
into the logs, but I also don't think this makes things any worse than
they are today with the "authorized&qu
On Thu, Aug 17, 2023 at 9:01 AM Stephen Frost wrote:
> That doesn't seem quite right ... admittedly, 'trust' isn't performing
> authentication but there can certainly be an argument made that the
> basic 'matched a line in pg_hba.conf' is a form of authentication
I'm not personally on board with
On Thu, Aug 17, 2023 at 9:46 AM Stephen Frost wrote:
> Don't like 'skipped' but that feels closer.
>
> How about 'connection bypassed authentication'?
Works for me; see v2.
Thanks!
--Jacob
From 5404c28391d2faae8a306e4e21c2ddfe1b70b53e Mon Sep 17 00:00:00 2001
F
On Sun, Aug 20, 2023 at 4:58 PM Michael Paquier wrote:
> Attached is a v3 to do these two things, with adjustments for two SSL
> tests. Any objections about it?
(Sorry for the long weekend delay.) No objections; you may want to
adjust the comment above the test block in t/001_password.pl, as wel
On Mon, Aug 21, 2023 at 4:22 PM Michael Paquier wrote:
> There are additionally two more comments in the SSL tests that could
> be removed, I guess. Here's a v4, with Robert's latest suggestion
> added.
LGTM.
> I am not sure that we need to change this historic term, TBH. Perhaps
> it would be
On Mon, Aug 21, 2023 at 10:39 PM Michael Paquier wrote:
> 0002 and 0003 make this stuff fail, but isn't there a risk that this
> breaks applications that relied on these accidental behaviors?
> Assuming that this is OK makes me nervous.
I wouldn't argue for backpatching, for sure, but I guess I s
On Tue, Aug 22, 2023 at 1:07 AM Peter Eisentraut wrote:
> I have attached two patches, one to update the generation rules, and one
> where I have converted the existing test files. (I didn't generate them
> from scratch, so for example
> src/test/modules/ssl_passphrase_callback/server.crt that co
On Wed, Aug 23, 2023 at 6:23 AM Daniel Gustafsson wrote:
> This has the smell of a theoretical problem, I can't really imagine a
> certificate where which would produce this. Have you been able to trigger it?
>
> Wouldn't a better fix be to error out on len == -1 as in the attached, maybe
> with
On Thu, Aug 24, 2023 at 6:25 PM Michael Paquier wrote:
> LD_PRELOAD is the only thing I can think about, but that's very fancy.
> Even with that, having a certificate with a NULL peer_cn could prove
> to be useful in the SSL suite to stress more patterns around it?
+1. Last we tried it, OpenSSL d
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
> On 19/04/2024 08:06, Michael Paquier wrote:
> > Since 91044ae4baea (require ALPN for direct SSL connections) and
> > d39a49c1e459 (direct hanshake), direct SSL connections are supported
> > (yeah!), still the thread where this has been di
On Fri, Apr 19, 2024 at 2:43 PM Heikki Linnakangas wrote:
>
> On 19/04/2024 19:48, Jacob Champion wrote:
> > On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
> >> With direct SSL negotiation, we always require ALPN.
> >
> > (As an aside: I haven&#x
On Mon, Apr 22, 2024 at 10:42 PM Michael Paquier wrote:
>
> On Mon, Apr 22, 2024 at 10:47:51AM +0300, Heikki Linnakangas wrote:
> > On 22/04/2024 10:19, Michael Paquier wrote:
> >> As a whole, I can get behind a unique GUC that forces the use of
> >> direct. Or, we could extend the existing "ssl"
On Mon, Apr 22, 2024 at 2:20 PM Jelte Fennema-Nio wrote:
> 1. I strongly believe minor protocol version bumps after the initial
> 3.1 one can be made painless for clients/poolers (so the ones to
> 3.2/3.3/etc). Similar to how TLS 1.3 can be safely introduced, and not
> having to worry about breaki
On Tue, Apr 23, 2024 at 10:43 AM Robert Haas wrote:
> I've not followed this thread closely enough to understand the comment
> about requiredirect maybe not actually requiring direct, but if that
> were true it seems like it might be concerning.
It may be my misunderstanding. This seems to imply
On Tue, Apr 23, 2024 at 8:13 PM Tatsuo Ishii wrote:
> SELECT v.a, count(*) OVER w
> FROM (VALUES ('A'),('B'),('B'),('C')) AS v (a)
> WINDOW w AS (
> ORDER BY v.a
> ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
> PATTERN (B+)
> DEFINE B AS a = 'B'
> )
> a | count
> ---+---
> A |
On Wed, Apr 24, 2024 at 1:57 PM Peter Eisentraut wrote:
> I'm concerned that there appears to be some confusion over whether ALPN
> is a performance feature or a security feature. RFC 7301 appears to be
> pretty clear that it's for performance, not for security.
It was also designed to give bene
On Tue, Apr 23, 2024 at 2:20 PM Heikki Linnakangas wrote:
>
> Attached patch tries to fix and clarify those.
s/negotiatied/negotiated/ in the attached patch, but other than that
this seems like a definite improvement. Thanks!
> (Note that the client will only attempt GSSAPI encryption if it can
On Thu, Apr 25, 2024 at 9:17 AM Robert Haas wrote:
>
> It is difficult to imagine a world in which we have both requiredirect
> and forcedirect and people are not confused.
Yeah... Any thoughts on a better scheme? require_auth was meant to
lock down overly general authentication; maybe a require_
On Thu, Apr 25, 2024 at 10:35 AM Robert Haas wrote:
> Maybe I'm missing something here, but why doesn't sslnegotiation
> override sslmode completely? Or alternatively, why not remove
> sslnegotiation entirely and just have more sslmode values? I mean
> maybe this shouldn't happen categorically, bu
On Thu, Apr 25, 2024 at 2:50 PM Heikki Linnakangas wrote:
> > I think that comes down to the debate upthread, and whether you think
> > it's a performance tweak or a security feature. My take on it is,
> > `direct` mode is performance, and `requiredirect` is security.
>
> Agreed, although the the
On Fri, Apr 26, 2024 at 4:54 AM Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
Congratulations!!
--Jacob
On Fri, Apr 26, 2024 at 3:51 PM Heikki Linnakangas wrote:
> I finally understood what you mean. So if the client supports ALPN, but
> the list of protocols that it provides does not include 'postgresql',
> the server should reject the connection with 'no_applicaton_protocol'
> alert.
Right. (And
On Mon, Apr 29, 2024 at 1:38 AM Heikki Linnakangas wrote:
> Sure, we'd try to fix them ASAP. But we've had the SSLRequest
> negotiation since time immemorial. If a new vulnerability is found, it's
> unlikely that we'd need to disable the SSLRequest negotiation altogether
> to fix it. We'd be in se
On Mon, Apr 29, 2024 at 11:43 AM Heikki Linnakangas wrote:
> Note that if the client does not request ALPN at all, the callback is
> not called, and the connection is accepted. Old clients still work
> because they do not request ALPN.
Ugh, sorry for the noise -- I couldn't figure out why all my
On Mon, Apr 29, 2024 at 12:06 PM Heikki Linnakangas wrote:
> On 29/04/2024 21:43, Jacob Champion wrote:
> > But if you're in that situation, what does the use of directonly give
> > you over `sslnegotiation=direct`? You already know that servers
> > support direct
On Mon, Apr 29, 2024 at 12:32 PM Jacob Champion
wrote:
>
> On Mon, Apr 29, 2024 at 12:06 PM Heikki Linnakangas wrote:
> > On 29/04/2024 21:43, Jacob Champion wrote:
> > > But if you're in that situation, what does the use of directonly give
> > > you over `
Hi all,
When json_lex_string() hits certain types of invalid input, it calls
pg_encoding_mblen_bounded(), which assumes that its input is
null-terminated and calls strnlen(). But the JSON lexer is constructed
with an explicit string length, and we don't ensure that the string is
null-terminated in
Hi,
When a client of our JSON parser registers semantic action callbacks,
the parser will allocate copies of the lexed tokens to pass into those
callbacks. The intent is for the callbacks to always take ownership of
the copied memory, and if they don't want it then they can pfree() it.
However, i
On Tue, Apr 30, 2024 at 2:41 PM Thomas Spear wrote:
> The full details can be found at github.com/pgjdbc/pgjdbc/discussions/3236 -
> in summary, both jdbc-postgres and the psql cli seem to be affected by an
> issue validating the certificate chain up to a publicly trusted root
> certificate tha
On Wed, May 1, 2024 at 6:48 AM Thomas Spear wrote:
> I dumped out the certificates presented by the server using openssl, and the
> chain that gets output includes "Microsoft Azure RSA TLS Issuing CA 08".
> On https://www.microsoft.com/pkiops/docs/repository.htm the page says that
> that cert wa
On Wed, May 1, 2024 at 8:17 AM Thomas Spear wrote:
> Circling back to my original question, why is there a difference in behavior?
>
> What I believe should be happening isn't what's happening:
> 1. If ~/.postgresql/root.crt contains the MS root, and I don't specify
> sslrootcert= -- successful v
On Wed, May 1, 2024 at 11:57 AM Thomas Spear wrote:
> It does fail to validate for case 4 after all. I must have had a copy/paste
> error during past tests.
Okay, good. Glad it's behaving as expected!
> So then it sounds like putting the MS root in root.crt (as we have done to
> fix this) is t
On Tue, Apr 30, 2024 at 11:09 PM Michael Paquier wrote:
> Not sure to like much the fact that this advances token_terminator
> first. Wouldn't it be better to calculate pg_encoding_mblen() first,
> then save token_terminator? I feel a bit uneasy about saving a value
> in token_terminator past th
On Wed, May 1, 2024 at 8:40 PM Michael Paquier wrote:
>
> On Thu, May 02, 2024 at 11:23:13AM +0900, Michael Paquier wrote:
> > About the fact that we may finish by printing unfinished UTF-8
> > sequences, I'd be curious to hear your thoughts. Now, the information
> > provided about the partial by
On Fri, May 3, 2024 at 4:54 AM Peter Eisentraut wrote:
>
> On 30.04.24 19:39, Jacob Champion wrote:
> > Tangentially: Should we maybe rethink pieces of the json_lex_string
> > error handling? For example, do we really want to echo an incomplete
> > multibyte sequence once
Hi all,
Recently I dealt with a server where PAM had hung a connection
indefinitely, suppressing our authentication timeout and preventing a
clean shutdown. Worse, the xmin that was pinned by the opening
transaction cascaded to replicas and started messing things up
downstream.
The DBAs didn't kn
On Mon, May 6, 2024 at 8:43 PM Michael Paquier wrote:
> On Fri, May 03, 2024 at 07:05:38AM -0700, Jacob Champion wrote:
> > We could port something like that to src/common. IMO that'd be more
> > suited for an actual conversion routine, though, as opposed to a
> > par
On Tue, May 7, 2024 at 10:31 PM Michael Paquier wrote:
> But looking closer, I can see that in the JSON_INVALID_TOKEN case,
> when !tok_done, we set token_terminator to point to the end of the
> token, and that would include an incomplete byte sequence like in your
> case. :/
Ah, I see what you'
On Wed, May 8, 2024 at 9:27 PM Michael Paquier wrote:
> This is a bit mitigated by the fact that d6607016c738 is recent, but
> this is incorrect since v13 so backpatched down to that.
Thank you!
--Jacob
(There's, uh, a lot to respond to above and I'm trying to figure out
how best to type up all of it.)
On Mon, May 13, 2024 at 9:13 AM Robert Haas wrote:
> However,
> I disagree with Jacob's assertion that sslmode=require has no security
> benefits over sslmode=prefer.
For the record, I didn't say
[soapbox thread, so I've changed the Subject]
On Mon, May 13, 2024 at 4:08 AM Heikki Linnakangas wrote:
> "channel_binding=require sslmode=require" also protects from MITM attacks.
This isn't true in the same way that "standard" TLS protects against
MITM. I know you know that, but for the benefi
On Mon, May 13, 2024 at 9:13 AM Robert Haas wrote:
> I find this idea to be a massive improvement over the status quo,
+1
> and
> I didn't spot any major problems when I read through the patch,
> either.
Definitely not a major problem, but I think
select_next_encryption_method() has gone stale,
[this should probably belong to a different thread, but I'm not sure
what to title it]
On Mon, May 13, 2024 at 4:08 AM Heikki Linnakangas wrote:
> I think these options should be designed from the user's point of view,
> so that the user can specify the risks they're willing to accept, and
> the
On Mon, Apr 29, 2024 at 11:04 AM Jacob Champion
wrote:
> On Fri, Apr 26, 2024 at 3:51 PM Heikki Linnakangas wrote:
> > Unfortunately the error message you got in the client with that was
> > horrible (I modified the server to not accept the 'postgresql' protocol):
>
On Tue, May 14, 2024 at 11:15 PM Peter Eisentraut wrote:
>
> On 15.05.24 02:00, Michael Paquier wrote:
> > Is that a recent regression? I have some blurry memories from
> > working on these areas that changing src/common/ reflected on the
> > compiled pieces effectively at some point.
>
> One ins
On Wed, May 15, 2024 at 6:33 AM Heikki Linnakangas wrote:
> Ok, yeah, I can see that now. Here's a new version to address that. I
> merged ENC_SSL_NEGOTIATED_SSL and ENC_SSL_DIRECT_SSL to a single method,
> ENC_SSL. The places that need to distinguish between them now check
> conn-sslnegotiation.
On Thu, May 16, 2024 at 12:14 PM David G. Johnston
wrote:
> Those likely never get out of the new WIP slot discussed above. Your patch
> tracker basically. And there should be less angst in moving something in the
> bimonthly into WIP rather than dropping it outright. There is discussion to
On Thu, May 16, 2024 at 1:46 PM Melanie Plageman
wrote:
> I should probably simply
> withdraw and re-register them. My justification was that I'll lose
> them if I don't keep them in the commitfest app. But, I could just,
> you know, save them somewhere myself instead of polluting the
> commitfest
On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote:
> Maybe we should just make it a policy that *nothing* gets moved forward
> from commitfest-to-commitfest and therefore the author needs to care
> enough to register for the next one?
I think that's going to severely disadvantage anyone who doesn'
On Thu, May 16, 2024 at 2:06 PM Joe Conway wrote:
> Maybe the word "care" was a poor choice, but forcing authors to think
> about and decide if they have the "time to shepherd a patch" for the
> *next CF* is exactly the point. If they don't, why clutter the CF with it.
Because the community regul
On Thu, May 16, 2024 at 2:29 PM Joe Conway wrote:
> If no one, including the author (new or otherwise) is interested in
> shepherding a particular patch, what chance does it have of ever getting
> committed?
That's a very different thing from what I think will actually happen, which is
- new aut
On Thu, May 16, 2024 at 2:04 PM Tom Lane wrote:
> Oh, that's an independent pet peeve of mine. Usually, if I'm
> looking over the CF list for a patch to review, I skip over ones
> that already show an assigned reviewer, because I don't want to
> step on that person's toes. But it seems very comm
On Fri, May 17, 2024 at 7:40 AM Robert Haas wrote:
>
> On Fri, May 17, 2024 at 10:31 AM Tom Lane wrote:
> > To my mind, the point of the time-boxed commitfests is to provide
> > a structure wherein people will (hopefully) pay some actual attention
> > to other peoples' patches. Conversely, the f
On Fri, May 17, 2024 at 1:53 PM Jacob Burroughs
wrote:
> New proposal, predicated on the assumption that if you enable
> compression you are ok with the client picking whatever level they
> want. At least with the currently enabled algorithms I don't think
> any of them are so insane that they wo
On Fri, May 17, 2024 at 4:03 PM Jelte Fennema-Nio wrote:
>
> On Fri, 17 May 2024 at 23:10, Jacob Champion
> wrote:
> > We're talking about a transport-level option, though -- I thought the
> > proposal enabled compression before authentication completed? Or has
> &
On Mon, May 20, 2024 at 8:29 AM Robert Haas wrote:
> It does occur to me that if some compression algorithm has a buffer
> overrun bug, restricting its use until after authentication might
> reduce the score of the resulting CVE, because now you have to be able
> to authenticate to make an exploit
On Mon, May 20, 2024 at 10:01 AM Robert Haas wrote:
> I really hope that you can't poke big enough holes to kill the feature
> entirely, though. Because that sounds sad.
Even if there are holes, I don't think the situation's going to be bad
enough to tank everything; otherwise no one would be abl
On Mon, May 20, 2024 at 11:05 AM Andrey M. Borodin wrote:
> > So, the data would be compressed first, with framing around that, and
> > then transport encryption would happen afterwards. I don't see how
> > that would leak your password, but I have a feeling that might be a
> > sign that I'm about
On Mon, May 20, 2024 at 11:37 AM Robert Haas wrote:
> But if that's a practical
> attack, preventing compression prior to the authentication exchange
> probably isn't good enough
I mean... you said it, not me. I'm trying not to rain on the parade
too much, because compression is clearly very valu
On Tue, May 21, 2024 at 8:23 AM Jacob Burroughs
wrote:
> As currently implemented, the compression only applies to
> CopyData/DataRow/Query messages, none of which should be involved in
> authentication, unless I've really missed something in my
> understanding.
Right, but Robert has argued that
On Tue, May 21, 2024 at 9:14 AM Jacob Burroughs
wrote:
> On Tue, May 21, 2024 at 10:43 AM Jelte Fennema-Nio wrote:
> > To help get everyone on the same page I wanted to list all the
> > security concerns in one place:
> >
> > 1. Triggering excessive CPU usage before authentication, by asking for
On Tue, May 21, 2024 at 12:08 PM Jacob Burroughs
wrote:
> I think I thought I was writing about something else when I wrote that
> :sigh:. I think what I really should have written was a version of
> the part below, which is that we use streaming decompression, only
> decompress 8kb at a time, an
On Thu, May 23, 2024 at 11:12 AM Tom Lane wrote:
> If a reader doesn't recognize a particular
> chunk code, it can still tell whether the chunk is "critical" or not,
> and thereby decide if it must give up or can proceed while ignoring
> that chunk.)
Would it be good to expand on that idea of cri
On Tue, Apr 30, 2024 at 2:29 PM Jacob Champion
wrote:
> Attached is a draft patch to illustrate what I mean, but it's
> incomplete: it only solves the problem for scalar values.
(Attached is a v2 of that patch; in solving a frontend leak I should
probably not introduce a backe
Hi all,
Our documentation implies that the ldapurl setting in pg_hba is used
for search+bind mode only. It was pointed out to me recently that this
is not true, and if you're dealing with simple bind on a non-standard
scheme or port, then ldapurl makes the HBA easier to read:
... ldap ldapurl
On Mon, Jun 3, 2024 at 9:32 PM Kyotaro Horiguchi
wrote:
>
> Hi,
Thanks for the review!
> I understand that the part enclosed in parentheses refers to the "if
> (ptr) pfree(ptr)" structure. I believe we rely on the behavior of
> free(NULL), which safely does nothing. (I couldn't find the related
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
> +{
> + /*
> +* Authenticat
bled to fully test 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/sr
t 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 -070
701 - 800 of 1337 matches
Mail list logo
