Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> ... We must remember how much data we encrypted
> >> and then discount that much of the caller's supplied data next time.
> >> There are hints in the existing comments that
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> ... We must remember how much data we encrypted
>> and then discount that much of the caller's supplied data next time.
>> There are hints in the existing comments that somebody understood
>> this at one point, but the code isn't
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > Here's a draft patch that cleans up all the logic errors I could find.
>
> So last night I was assuming that this problem just requires more careful
> attention to what to return in the error exit paths. In the light of
> morning,
Peter writes:
> With the first patch applied (as from Friday - applied only on the
> client side), the application did appear to work well.
> But then, when engaging bandwidth-limiting to some modem-speed, it did
> not work: psql would receive all (or most of) the data from a SELECT,
> but then
On Fri, Jan 10, 2020 at 10:51:50PM -0500, Tom Lane wrote:
! Here's a draft patch that cleans up all the logic errors I could find.
Okiee, thank You!
Let's see (was a bit busy yesterday trying to upgrade pgadmin3 -
difficult matter), now lets sort this out:
With the first patch applied (as from
I wrote:
> (Still doesn't touch the static-buffer issue, though.)
And here's a delta patch for that. This fixes an additional portability
hazard, which is that there were various places doing stuff like
input.length = ntohl(*(uint32 *) PqGSSRecvBuffer);
That's a SIGBUS hazard
I wrote:
> So last night I was assuming that this problem just requires more careful
> attention to what to return in the error exit paths. In the light of
> morning, though, I realize that the algorithms involved in
> be-secure-gssapi.c and fe-secure-gssapi.c are just fundamentally wrong:
I wrote:
> Here's a draft patch that cleans up all the logic errors I could find.
So last night I was assuming that this problem just requires more careful
attention to what to return in the error exit paths. In the light of
morning, though, I realize that the algorithms involved in
Here's a draft patch that cleans up all the logic errors I could find.
I also expanded the previous patch for the kerberos test so that it
verifies that we can upload a nontrivial amount of data to the server,
as well as download.
I also spent a fair amount of effort on removing cosmetic
On Fri, Jan 10, 2020 at 12:59:09PM -0500, Tom Lane wrote:
! [ redirecting to -hackers ]
! I modified the kerberos test so that it tries a query with a less
! negligible amount of data, and what I find is:
!
! * passes on Fedora 30, with either default or 1500 mtu
! * passes on FreeBSD 12.0 with
Greetings,
On Fri, Jan 10, 2020 at 15:58 Tom Lane wrote:
> Stephen Frost writes:
> > Ah-hah. Not sure if that was Robbie or myself (probably me, really,
> > since I rewrote a great deal of that code). I agree that the regression
> > tests don't test with very much data, but I tested pushing
Stephen Frost writes:
> Ah-hah. Not sure if that was Robbie or myself (probably me, really,
> since I rewrote a great deal of that code). I agree that the regression
> tests don't test with very much data, but I tested pushing quite a bit
> of data through and didn't see any issues with my
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > I haven't run it further to ground than that, but there's definitely
> > something fishy here. Based on just these results one would be hard
> > pressed to say if it's our bug or FreeBSD's, but your report that you
> > don't see
I wrote:
> I haven't run it further to ground than that, but there's definitely
> something fishy here. Based on just these results one would be hard
> pressed to say if it's our bug or FreeBSD's, but your report that you
> don't see the failure with PG 11 makes it sound like our problem.
Ah, I
[ redirecting to -hackers ]
Peter writes:
> But I just recognize something of interest (which I had taken for
> granted when importing the database): the flaw does NOT appear when
> accessing the database from the server's local system (with TCP and
> GSSAPI encryption active). Only from remote
15 matches
Mail list logo
