Bugzilla Bug 134168

folks, please refer here http://www.postgresql.org/about/news.561 for the
recent urgent security release from Postgres on all the streams. New versions
releasd are 8.1.4, 8.0.8, 7.4.13 and 7.3.15.

its also on Slashdot. I could find ebuilds to upgrade to above versions, I did
search here as well, alas, no avail. Hence this bug report.

regards

Shirish

I can support this request. This is urgent because the slashdot article
describes possible exploits...

Definitely urgent, it's all over the news.

Hi PGSQL team,

please take care of it, and please update the metadata file with a
pgsql-bugs@gentoo.org mention. (herd is postgresql and postgresql@gentoo.org
doesn't exist)

(little cleanup, was forced to specify a comment by bugzie)

Wrong category

Created an attachment (id=87591) [details]
overlay for postgresql-8.1.4

ebuild and patches for 8.1.4

Created an attachment (id=87594) [details]
8.1.4 ebuild

Created an attachment (id=87595) [details]
8.1.4 gentoo patch

Created an attachment (id=87596) [details]
8.1.4 init

Created an attachment (id=87597) [details]
8.1.4 spinlock patch

Created an attachment (id=87598) [details]
8.1.4 conf

Created an attachment (id=87599) [details]
libpq-8.1.4 ebuild

Created an attachment (id=87600) [details]
libpq-8.1.4 patch

whats up here?!

ok, libpq/postgresql - 8.1.4, 8.0.8, 7.4.13, 7.3.15 committed in portage.
8.1.4 stresstested on two machines (x86/amd64), other's are only known to
compile and start.

Arches, a lot of work coming up: please test and stable versions 8.1.4, 8.0.8,
7.4.13, 7.3.15, libpq should be stabled in sync.

Last arch that goes stable, please remove old vulnerable cruft from the tree,
thanks

Also thanks to voxus for bumping.

Do we really wanna stable 8.1.x in this run? (no previous 8.1.x is stable)

(In reply to comment #17)
> Do we really wanna stable 8.1.x in this run? (no previous 8.1.x is stable)

Crap I'm sorry, my fault. 8.1.x does not need to be stabled

7.4.13 and 8.0.8 stable on ppc64.

(7.3.x has no stable ppc64 keyword)

I noticed the "threads" USE flag was added to 8.1.4. From what I was able to
glean from developers in #postgresql on freenode, this USE flag does absolutely
nothing for postgresql server, as it's not threaded. This USE flag is meant
only for libpq. It should be removed from the postgresql ebuild.

My 2

I noticed the "threads" USE flag was added to 8.1.4. From what I was able to
glean from developers in #postgresql on freenode, this USE flag does absolutely
nothing for postgresql server, as it's not threaded. This USE flag is meant
only for libpq. It should be removed from the postgresql ebuild.

My 2¢.

Daniel

The threads USE flag was introduced in 8.1.3...whether it has any real bearing
is another question, from the configure (line 16202):

#
# Pthreads
#
# For each platform, we need to know about any special compile and link
# libraries, and whether the normal C function names are thread-safe.
# See the comment at the top of src/port/thread.c for more information.
#

For the lazy src/port/thread.c:
[snip]
/*
 *      Threading sometimes requires specially-named versions of functions
 *      that return data in static buffers, like strerror_r() instead of
 *      strerror().  Other operating systems use pthread_setspecific()
 *      and pthread_getspecific() internally to allow standard library
 *      functions to return static data to threaded applications. And some
 *      operating systems have neither.
[/snip]

Macros for thread safety of threaded applications which use the threaded
libraries.

[clarification] Thread safety was added in 8.1.3, the USE flag was added in
8.1.3-r1

{postgres,libpq}-{7.4.13,8.0.8} stable on alpha.

7.3.15 doesn't compile. I'll file a bug for it and make this bug depend on it.

7.4.13 and 8.0.8 sparc stable.
7.3.15 is br0ke for us too.

{postgres,libpq}-{7.4.13,8.0.8} stable on ppc.

7.3.15 also doesn't compile on ppc, I added us to that bug.

^^what all of those guys said :)

7.4.13 & 8.0.8 done on x86

Stable on hppa. Forgot to comment this on this bug. 7.3.15 doesn't build on
hppa, too. Added us to that bug.

{postgres,libpq}-{7.4.13,8.0.8} stable on amd64.

7.3.15 doesn't compile, I added us to bug #135187.

this bug is rather old. Shouldn't we consider sending a GLSA mentionning that
the 1.3.x branch is still vulnerable ?

> the 1.3.x branch is still vulnerable ?

not 1.3.x, but 7.3.x, of course, you have already corrected me.

removing x86 as we've stablized the packages requested and don't see a need to
be on the bug anymore. If this is not the case and we're still on it for a
reason feel free to readd us.

Since 7.3.15 seems broken on most arches we should consider masking the 7.3
branch, since the bug is aging and we should get the GLSA out.

Jaervosz?

@pqsql-bugs: what do you think about masking?

@arches please test and mark stable or comment. We're quite late on this one.

sparc has everything stable except 7.3.15

(In reply to comment #33)
> @arches please test and mark stable or comment. We're quite late on this one.

As I stated in comment #28, alpha has everything stable except 7.3.15, see Bug
#135187.

I think I can safely remove ppc from this bug as all mentioned ebuilds (beside
7.3.15) are stable.

Ok, we'll release a GLSA without a fix for 7.3 (which could be masked)

GLSA 200607-04

*** Bug 151482 has been marked as a duplicate of this bug. ***