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 attachment 87591 [details] overlay for postgresql-8.1.4 ebuild and patches for 8.1.4
Created attachment 87594 [details] 8.1.4 ebuild
Created attachment 87595 [details, diff] 8.1.4 gentoo patch
Created attachment 87596 [details] 8.1.4 init
Created attachment 87597 [details, diff] 8.1.4 spinlock patch
Created attachment 87598 [details] 8.1.4 conf
Created attachment 87599 [details] libpq-8.1.4 ebuild
Created attachment 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. ***