Branches for Hoary

Name Status Last Modified Last Commit
lp://staging/ubuntu/hoary/postgresql 1 Development 2009-09-28 22:09:54 UTC
3. debian/postgresql.init: Create socket...

Author: Martin Pitt
Revision Date: 2005-02-17 14:24:55 UTC

debian/postgresql.init: Create socket directory /var/run/postgresql if it
does not exist. This happens if /var/run is mounted on a tmpfs.
(Ubuntu #6168)

lp://staging/ubuntu/hoary-security/postgresql 1 Development 2009-08-15 09:39:26 UTC
6. * SECURITY UPDATE: Remote SQL injecti...

Author: Martin Pitt
Revision Date: 2006-05-24 17:33:01 UTC

* SECURITY UPDATE: Remote SQL injection.
* Add debian/patches/54reject-invalid-encoding.patch:
  - Change the backend to reject strings containing invalidly-encoded
    multibyte characters in all cases. Formerly we mostly just threw warnings
    for invalid input, and failed to detect it at all if no encoding
    conversion was required. The tighter check is needed to defend
    against SQL-injection attacks.
  - Also, fix a few longstanding errors in little-used encoding conversion
    routines: win1251_to_iso, win866_to_iso, euc_tw_to_big5, euc_tw_to_mic,
    mic_to_euc_tw were all broken to varying extents.
  - Patch backported from 8.0.8.
  - CVE-2006-2313
* Add debian/patches/55backslash_quote-guc.patch:
  - Add a new GUC parameter backslash_quote, which determines whether the
    SQL parser will allow "\'" to be used to represent a literal quote mark.
    The "\'" representation has been deprecated for some time in favor of the
    SQL-standard representation "''" (two single quote marks), but it has been
    used often enough that just disallowing it immediately won't do. Hence
    backslash_quote allows the settings "on", "off", and "safe_encoding", the
    last meaning to allow "\'" only if client_encoding is a valid server
    encoding. That is now the default, and the reason is that in encodings
    such as SJIS that allow 0x5c (ASCII backslash) to be the last byte of a
    multibyte character, accepting "\'" allows SQL-injection attacks.
  - The "on" setting is available for backward compatibility, but it must
    not be used with clients that are exposed to untrusted input.
  - Patch backported from 8.0.8.
  - CVE-2006-2314
* Add debian/patches/56quote-escaping.patch:
  - Change escaping from \' to '' throughout the code (in client programs
    and contrib modules).
  - Patch backported from 8.0.8.
* Add debian/patches/57libpq-string-escaping.patch:
  - Modify libpq's string-escaping routines to be aware of encoding
    considerations 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.
  - 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.
  - Patch backported from 8.0.8.
* Add debian/patches/58indexscan-duplicate-tuples.patch:
  - Fix nasty bug in nodeIndexscan.c's detection of duplicate tuples during
    a multiple (OR'ed) indexscan. It was checking for duplicate
    tuple->t_data->t_ctid, when what it should be checking is tuple->t_self.
  - Patch backported from 8.0.8.

12 of 2 results