| Age | Commit message (Collapse) | Author |
|
which was already updated.
|
|
missing X509_free() calls. Per a request from a Red Hat customer;
seems silly for Red Hat to be shipping a patch that's not in upstream.
|
|
|
|
and standard_conforming_strings. The encoding changes are needed for proper
escaping in multibyte encodings, as per the SQL-injection vulnerabilities
noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied
to the server to ensure that it rejects queries that may have been corrupted
by attempted SQL injection, but this merely guarantees that unpatched clients
will fail rather than allow injection. An actual fix requires changing the
client-side code. While at it we have also fixed these routines to understand
about standard_conforming_strings, so that the upcoming changeover to SQL-spec
string syntax can be somewhat transparent to client code.
Since the existing API of PQescapeString and PQescapeBytea provides no way to
inform them which settings are in use, these functions are now deprecated in
favor of new functions PQescapeStringConn and PQescapeByteaConn. The new
functions take the PGconn to which the string will be sent as an additional
parameter, and look inside the connection structure to determine what to do.
So as to provide some functionality for clients using the old functions,
libpq stores the latest encoding and standard_conforming_strings values
received from the backend in static variables, and the old functions consult
these variables. This will work reliably in clients using only one Postgres
connection at a time, or even multiple connections if they all use the same
encoding and string syntax settings; which should cover many practical
scenarios.
Clients that use homebrew escaping methods, such as PHP's addslashes()
function or even hardwired regexp substitution, will require extra effort
to fix :-(. It is strongly recommended that such code be replaced by use of
PQescapeStringConn/PQescapeByteaConn if at all feasible.
|
|
and 8.0. Later releases already patched.
|
|
routine, but perhaps some applications do. Found by Martijn van Oosterhout
using Coverity.
|
|
|
|
|
|
variable-definition error on recent FreeBSDen (evidently, that platform
also HAS_STRUCT_CMSGCRED). Backport of 7.4 fix dated 2003-10-25.
|
|
|
|
|
|
|
|
freeing all transient state of the PGconn object.
|
|
Also, back-patch fix into back branches.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
octal escape all octets outside the range 0x20 to 0x7e. This fixes
the problem pointed out by Sergey Yatskevich here:
http://archives.postgresql.org/pgsql-bugs/2003-11/msg00140.php
|
|
7.3.5 will build out-of-the-box on Solaris.
|
|
at all, it just means 'no data available yet'.
|
|
vulnerability. This fix completely removes the ability (hack) of being able
to bind a list of values in an in clause. It was demonstrated that by allowing
that functionality you open up the possibility for certain types of
sql injection attacks. The previous fix attempts all focused on preventing
the insertion of additional sql statements (the semi-colon problem:
xxx; any new sql statement here). But that still left the ability to
change the where clause on the current statement or perform a subselect
which can circumvent applicaiton security logic and/or allow you to call
any stored function.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/Driver.java.in
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
|
|
|
|
and Dmitry Tkach
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/Driver.java.in
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
|
|
|
|
where the Object is a String and the type is numeric (i.e. INTEGER,LONG,etc).
The fix applies the standard escaping for these values.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/Driver.java.in
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
|
|
|
|
Modified Files:
Tag: REL7_3_STABLE
Driver.java.in
|
|
|
|
fixing an order by problem for index metadata results.
Also includes removing some unused code as well as a fix to the toString
method on statement.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
|
|
|
|
|
|
subsequent updates patch from Shawn Green, slightly modified
|
|
two columns in a table are both foreign keys to another table. From Peter Royal proyal@pace2020.com
|
|
subsequent updates patch from Shawn Green
|
|
|
|
table owner has privs)
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
|
|
following: select 1; commit; set autocommit true;
If this is submitted in one call to the server (the select 1 doesn't start a
new transaction like it should), however if the select 1 is sent as a separate
call then it works correctly.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
|
|
Modified Files:
Tag: REL7_3_STABLE
errors_zh_TW.properties
|
|
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java
|
|
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/errors.properties
jdbc/org/postgresql/jdbc2/AbstractJdbc2Statement.java
jdbc/org/postgresql/util/PSQLException.java
|
|
absolute() and NPE when logging enabled)
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java
jdbc/org/postgresql/util/PSQLException.java
|
|
|
|
This backports part of the fix made in version 1.11.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java
|
|
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/errors_zh_TW.properties
|
|
datatype problem.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
|
|
against 7.1 servers.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
|