I think we need this patch. Bytea encoding will be changed to accept
\000 rather than \0 for the same reason. I also agree that the libpq
enescaping of a C string doesn't need to deal with NULL like bytea does.
Your patch has been added to the PostgreSQL unapplied patches list at:
htt
"Joe Conway" <[EMAIL PROTECTED]> writes:
> I found a problem with PQescapeString (I think). Since it escapes
> null bytes to be literally '\0', the following can happen:
> 1. User inputs string value as "##" where ## are digits in the
> range of 0 to 7.
> 2. PQescapeString converts this to "\0##"
> Patch applied. Thanks.
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
> > > Patch removed at the request of the author. Author will resubmit.
> >
> > I've attached the fixed version of the patch below. After the
> > discussion on pgsql-hackers (especially the frightening memory dump in
>
Patch applied. Thanks.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Patch removed at the request of the author. Author will resubmit.
>
> I've attached the fixed version of the patch below. After the
> discussion on pgsql-hackers (especially the frightening memory dump in
> <[EMAIL PRO
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Patch removed at the request of the author. Author will resubmit.
>
> I
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Patch removed at the request of the author. Author will resubmit.
I've attached the fixed version of the patch below. After the
discussion on pgsql-hackers (especially the frightening memory dump in
<[EMAIL PROTECTED]>), we decided that it is best no
Patch removed at the request of the author. Author will resubmit.
> It has come to our attention that many applications which use libpq
> are vulnerable to code insertion attacks in strings and identifiers
> passed to these applications. We have collected some evidence which
> suggests that th
I am going to apply this patch with the change that the function name
will be PQ* not PG*.
> It has come to our attention that many applications which use libpq
> are vulnerable to code insertion attacks in strings and identifiers
> passed to these applications. We have collected some evidence w
For consistency with the rest of the libpq API, the function should be
called PQescapeString, not PGescapeString.
Bruce Momjian writes:
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://candle.pha.pa.us/cgi-bin/pgpatches
>
> I will try to apply it within
Barry Lind wrote:
>
> I agree with Hannu, that:
>
> * make SQL changes to allow PREPARE/EXECUTE in main session, not only
> in SPI
A more ambitious project would be
* develop an ANSI standard SQL/CLI compatible postgreSQL client library,
change wire protocol and SQL language as needed ;)
I agree with Hannu, that:
* make SQL changes to allow PREPARE/EXECUTE in main session, not only
in SPI
is an important feature to expose out to the client. My primary reason
is a perfomance one. Allowing the client to parse a SQL statement once
and then supplying bind values for arguments
Bruce Momjian wrote:
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://candle.pha.pa.us/cgi-bin/pgpatches
>
> I will try to apply it within the next 48 hours.
>
> > It has come to our attention that many applications which use libpq
> > are vulnerabl
ot; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 7:32 PM
Subject: Re: [HACKERS] Escaping strings for inclusion into SQL queries
> It is. Application is responsible to call PGescapeString (included in the
> patch in question) to escape command that may
"Mitch Vincent" <[EMAIL PROTECTED]> writes:
> Perhaps I'm not thinking correctly but isn't it the job of the application
> that's using the libpq library to escape special characters?
Yes, it is.
> I guess I don't see a down side though, if it's implemented
> correctly to check and see if chara
Weimer" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, August 30, 2001 6:43 PM
> Subject: Re: [HACKERS] Escaping strings for inclusion into SQL queries
>
>
> > > Florian Weimer <[EMAIL PROTECTED]> writes:
> > >
> > > >
t;[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 6:43 PM
Subject: Re: [HACKERS] Escaping strings for inclusion into SQL queries
> > Florian Weimer <[EMAIL PROTECTED]> writes:
> >
> > > We therefore suggest that a string escaping func
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
> It has come to our attention that many applications which use libpq
> are vulnerable to code insertion attacks in strings
> Florian Weimer <[EMAIL PROTECTED]> writes:
>
> > We therefore suggest that a string escaping function is included in a
> > future version of PostgreSQL and libpq. A sample implementation is
> > provided below, along with documentation.
>
> We have now released a description of the problems wh
Florian Weimer <[EMAIL PROTECTED]> writes:
> We therefore suggest that a string escaping function is included in a
> future version of PostgreSQL and libpq. A sample implementation is
> provided below, along with documentation.
We have now released a description of the problems which occur when
19 matches
Mail list logo
