Neil, Robert:

"As for the "WAL recovery bug", AFAIK no such bug has been reported "in
the last few days". Exactly what issue are you referring to?"

That's my bug; I filed it on Wednesday.

However, it is not 100%; that is:
1) While Tom and I are pretty sure that the issue *could* cause the behavior 
reported, we're not completely certain that it *did*; i.e. in the two 
reported cases, one actually turned out to be something else, and the other 
could possibly be something else as well.

2) Nobody has tested that switching the order of those 2 lines in 7.2.3 
doesn't cause any problems, to date.

I'm not saying that it's not potentially a patchable bug.   We're just not 
ready to patch it yet.

But I do vote for a 7.2.4 just because I can't upgrade a lot of my clients to 
7.3.1 safely and there are a few easy patches for 7.2.3.   

Alternately, I would suggest an omnibus patch for the 7.2.3 source code so 
that we don't set a precedent for branching development.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


Sun, 19 Jan 2003 16:32:07 -0800
Josh Berkus <josh@agliodbs.com>
Re: Can we revisit the thought of PostgreSQL 7.2.4? 
Josh Berkus wrote:
> Neil, Robert:
> 
> "As for the "WAL recovery bug", AFAIK no such bug has been reported "in
> the last few days". Exactly what issue are you referring to?"
> 
> That's my bug; I filed it on Wednesday.
> 
> However, it is not 100%; that is:
> 1) While Tom and I are pretty sure that the issue *could* cause the behavior 
> reported, we're not completely certain that it *did*; i.e. in the two 
> reported cases, one actually turned out to be something else, and the other 
> could possibly be something else as well.
> 
> 2) Nobody has tested that switching the order of those 2 lines in 7.2.3 
> doesn't cause any problems, to date.
> 
> I'm not saying that it's not potentially a patchable bug.   We're just not 
> ready to patch it yet.

Ok, this might not be such an important fix after all then?  The wording 
of it at the time did make it sound important, but if it somehow has bad 
interactions we would be shooting ourselves in the foot with it.

Any guess-timates on it's safeness and whether it really would be 
beneficial?


> But I do vote for a 7.2.4 just because I can't upgrade a lot of my clients to 
> 7.3.1 safely and there are a few easy patches for 7.2.3.   
> 
> Alternately, I would suggest an omnibus patch for the 7.2.3 source code so 
> that we don't set a precedent for branching development.

An interesting thought here is to know if Red Hat fixed *all* of the 
known PostgreSQL security flaws for 7.2.3 with their latest security 
release.  It would be interesting to see their code if they did so, but 
from Tom's previous comments it would have meant a real lot of work.

It's probably better to put out a 7.2.4 than an omnibus patch though, as 
it gives a better foundation for everyone working on 7.2.x to safely 
move to.  From the viewpoint of "it takes more skill to patch than to 
compile".

Regards and best wishes,

Justin Clift

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi


Mon, 20 Jan 2003 13:46:25 +1030
Justin Clift <justin@postgresql.org>
Re: Can we revisit the thought of PostgreSQL 7.2.4?
On Sunday 19 January 2003 22:16, Justin Clift wrote:
> An interesting thought here is to know if Red Hat fixed *all* of the
> known PostgreSQL security flaws for 7.2.3 with their latest security
> release.  It would be interesting to see their code if they did so, but
> from Tom's previous comments it would have meant a real lot of work.

Judge for yourself.  Here's the text of the two Red Hat advisories (with the 
RPM listing and MD5 sums omitted):

[For older versions]

                   Red Hat, Inc. Red Hat Security Advisory

Synopsis:          Updated PostgreSQL packages fix buffer overrun 
vulnerabilities
Advisory ID:       RHSA-2003:010-10
Issue date:        2003-01-14
Updated on:        2003-01-14
Product:           Red Hat Linux
Keywords:          PostgreSQL datetime lpad rpad multibyte
Cross references:  RHSA-2002:301 RHSA-2003:001
Obsoletes:         
CVE Names:         CAN-2002-0972 CAN-2002-1397 CAN-2002-1398 CAN-2002-1400 
CAN-2002-1401 CAN-2002-1402
---------------------------------------------------------------------

1. Topic:

Updated PostgreSQL packages are available for Red Hat Linux 6.2, 7, 7.1,
and 7.2 where we have backported a number of security fixes.  A separate
advisory  deals with updated PostgreSQL packages for Red Hat Linux 7.3 and 
8.0.

2. Relevant releases/architectures:

Red Hat Linux 6.2 - i386
Red Hat Linux 7.0 - i386
Red Hat Linux 7.1 - i386
Red Hat Linux 7.2 - i386, ia64

3. Problem description:

PostgreSQL is an advanced Object-Relational database management system
(DBMS).  A number of security issues have been found that affect PostgreSQL
versions shipped with Red Hat Linux.  

Buffer overflows in PostgreSQL 7.2 allow attackers to cause a denial of
service and possibly execute arbitrary code via long arguments to the lpad
or rpad functions. CAN-2002-0972

Buffer overflow in the cash_words() function for PostgreSQL 7.2 and
earlier allows local users to cause a denial of service and possibly
execute arbitrary code via a malformed argument.  CAN-2002-1397

Buffer overflow in the date parser for PostgreSQL before 7.2.2 allows
attackers to cause a denial of service and possibly execute arbitrary
code via a long date string, also known as a vulnerability "in handling
long datetime input."  CAN-2002-1398

Heap-based buffer overflow in the repeat() function for PostgreSQL
before 7.2.2 allows attackers to execute arbitrary code by causing
repeat() to generate a large string.  CAN-2002-1400

Buffer overflows in circle_poly, path_encode and path_add allow attackers
to cause a denial of service and possibly execute arbitrary code.   Note
that these issues have been fixed in our packages and in PostgreSQL CVS,
but are not included in PostgreSQL version 7.2.2 or 7.2.3.  CAN-2002-1401

Buffer overflows in the TZ and SET TIME ZONE enivronment variables for
PostgreSQL 7.2.1 and earlier allow local users to cause a denial of service
and possibly execute arbitrary code.  CAN-2002-1402

Note that these vulnerabilities are only critical on open or shared systems
because connecting to the database is required before the vulnerabilities
can be exploited.

The PostgreSQL Global Development Team has released versions of PostgreSQL
that fixes these vulnerabilities, and these fixes have been isolated and
backported to the various versions of PostgreSQL that originally shipped
with each Red Hat Linux distribution.  All users of  PostgreSQL are advised
to install these updated packages.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

Please note that this update is available via Red Hat Network.  To use Red
Hat Network, launch the Red Hat Update Agent with the following command:

up2date

This will start an interactive process that will result in the appropriate
RPMs being upgraded on your system.

Note that no initdb will be necessary from previous PostgreSQL packages.

5. RPMs required:
[omitted]

[For recent versions]
                  Red Hat, Inc. Red Hat Security Advisory

Synopsis:          Updated PostgreSQL packages fix security issues and bugs
Advisory ID:       RHSA-2003:001-16
Issue date:        2003-01-14
Updated on:        2003-01-14
Product:           Red Hat Linux
Keywords:          PostgreSQL VACUUM pre-1970 spinlock
Cross references:  
Obsoletes:         
CVE Names:         CAN-2002-0972 CAN-2002-1397 CAN-2002-1398 CAN-2002-1400 
CAN-2002-1401 CAN-2002-1402
---------------------------------------------------------------------

1. Topic:

Updated PostgreSQL packages are available for Red Hat Linux 7.3 and 8.0.
These packages correct several security and other bugs.  A separate
advisory deals with updated PostgreSQL packages for Red Hat Linux 6.2, 7,
7.1, and 7.2.

2. Relevant releases/architectures:

Red Hat Linux 7.3 - i386
Red Hat Linux 8.0 - i386

3. Problem description:

PostgreSQL is an advanced Object-Relational database management system. 
Red Hat Linux 7.3 shipped with PostgreSQL version 7.2.1.  Red Hat Linux 8.0
shipped with PostgreSQL version 7.2.2.

PostgreSQL versions 7.2.1 and 7.2.2 contain a serious issue with the VACUUM
command when it is run by a non-superuser.  It is possible for the system
to prematurely remove old transaction log data (pg_clog files), which can
result in unrecoverable data loss.

A number of minor security issues affect the PostgreSQL 7.2.1 packages
shipped with Red Hat Linux 7.3 only:

1. Buffer overflows in PostgreSQL 7.2 allow attackers to cause a denial of
service and possibly execute arbitrary code via long arguments to the lpad
or rpad functions.   CAN-2002-0972
 
2. Buffer overflow in the cash_words() function allows local users to cause
a denial of service and possibly execute arbitrary code via a malformed
argument. CAN-2002-1397

3. Buffer overflow in the date parser allows attackers to cause a denial of
service and possibly execute arbitrary code via a long date string, also
known as a vulnerability "in handling long datetime input." CAN-2002-1398

4. Heap-based buffer overflow in the repeat() function allows attackers to
execute arbitrary code by causing repeat() to generate a large string.
CAN-2002-1400

5. Buffer overflows in the TZ and SET TIME ZONE enivronment variables allow
local users to cause a denial of service and possibly execute arbitrary
code. CAN-2002-1402

Additionally, buffer overflows in circle_poly, path_encode and path_add
allow attackers to cause a denial of service and possibly execute arbitrary
code. Note that these overflows have been fixed in our erratum packages and
in PostgreSQL CVS, but are not fixed in the released versions of PostgreSQL
version 7.2.3. CAN-2002-1401

The above vulnerabilities are only critical on open or shared systems
because connecting to the database is required before the vulnerabilities
can be exploited. 

This update also contains fixes for several other PostgreSQL bugs,
including handling of pre-1970 date values in newer versions of glibc,
possible server shutdown hangs, spinlock hangs on SMP PPC machines, and
pg_dump improperly dumping with the FULL JOIN USING clauses.

All users of PostgreSQL should upgrade to these errata packages containing
PostgreSQL 7.2.3 with additional patches to correct all these issues. Note
that running initdb is not necessary when upgrading from 7.2.1 or 7.2.2 to
the packages contained in this errata.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which are
not installed but included in the list will not be updated.  Note that you
can also use wildcards (*.rpm) if your current directory *only* contains
the desired RPMs.

Please note that this update is also available via Red Hat Network.  Many
people find this an easier way to apply updates.  To use Red Hat Network,
launch the Red Hat Update Agent with the following command:

up2date

This will start an interactive process that will result in the appropriate
RPMs being upgraded on your system.

5. RPMs required:
[omitted]
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Sun, 19 Jan 2003 22:44:49 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: Can we revisit the thought of PostgreSQL 7.2.4?