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
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 this is related to the fact that libpq does not provide
a function to escape st
20 matches
Mail list logo
