CVE-2009-4034 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-4034): PostgreSQL 7.4.x before 7.4.27, 8.0.x before 8.0.23, 8.1.x before 8.1.19, 8.2.x before 8.2.15, 8.3.x before 8.3.9, and 8.4.x before 8.4.2 does not properly handle a '\0' character in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which (1) allows man-in-the-middle attackers to spoof arbitrary SSL-based PostgreSQL servers via a crafted server certificate issued by a legitimate Certification Authority, and (2) allows remote attackers to bypass intended client-hostname restrictions via a crafted client certificate issued by a legitimate Certification Authority, a related issue to CVE-2009-2408.
CVE-2009-4136 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-4136): PostgreSQL 7.4.x before 7.4.27, 8.0.x before 8.0.23, 8.1.x before 8.1.19, 8.2.x before 8.2.15, 8.3.x before 8.3.9, and 8.4.x before 8.4.2 does not properly manage session-local state during execution of an index function by a database superuser, which allows remote authenticated users to gain privileges via a table with crafted index functions, as demonstrated by functions that modify (1) search_path or (2) a prepared statement, a related issue to CVE-2007-6600 and CVE-2009-3230.
All ebuilds except for 7.4.27 are in-tree. (That one fails on autotools thingies again)
7.4.27 committed, so all ebuilds are available.
There seems to be no 8.1.19 ebuild avaialble?
(In reply to comment #4) > There seems to be no 8.1.19 ebuild avaialble? > There is.
I did emerge --sync just now and have these two 8.1 series: postgresql-8.1.11.ebuild postgresql-8.1.18.ebuild Nothing else matching *8.1.*
(In reply to comment #6) > I did emerge --sync just now and have these two 8.1 series: > > postgresql-8.1.11.ebuild > postgresql-8.1.18.ebuild > > Nothing else matching *8.1.* > Can confirm 8.1.19 is there.
Vote: NO.
Either I'm completely missing the point here, or something else is up a creek. I've had a look around on about 10 different machines, all nicely sync'ed up as recently as a few days back, and there is *no* 8.1.19 in the /usr/portage/dev-db/postgresql directory.
I got: * dev-db/postgresql-server Available versions: (7.3) 7.3.21 (7.4) 7.4.26 7.4.27 (8.0) 8.0.22 8.0.23 (8.1) 8.1.18 8.1.19 (8.2) 8.2.14 8.2.15 (8.3) 8.3.8 8.3.9 (8.4) 8.4.1!t 8.4.1-r1!t 8.4.2!t 8.4.2-r1!t (8.5) [M]~8.5_alpha3!t (9.0) [M]~9.0_alpha4!t
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-db/postgresql/ This is what I see. -A
There is a dev-db/postgresql-*server* package 8.1.19, but no dev-db/postgresql 8.1.19. pgsql-bugs: Please explain what the difference between postgresql and postgresql-server is. GLSA vote: YES
(In reply to comment #12) > There is a dev-db/postgresql-*server* package 8.1.19, but no dev-db/postgresql > 8.1.19. > > pgsql-bugs: Please explain what the difference between postgresql and > postgresql-server is. > > GLSA vote: YES > Simply put, dev-db/postgresql doesn't do slotting the way dev-db/postgresql-server does it. And, using dev-db/postgresql-{docs,base,server} is much more descriptives than the older ones. Most importantly: dev-db/postgresql-{docs,base,server} are the only packages that will and are maintained.
[quote] Most importantly: dev-db/postgresql-{docs,base,server} are the only packages that will and are maintained. [/quote] So why are the whole dev-db/postgresql hiearchy still kept in portage? -A
(In reply to comment #14) > [quote] > Most importantly: dev-db/postgresql-{docs,base,server} are the only packages > that will and are maintained. > [/quote] > > So why are the whole dev-db/postgresql hiearchy still kept in portage? > > -A > We've been trying to mask and get rid of them for a while. But, other packages in the tree have required them, and we need the new packages to be stabilized across the board.
dev-db/postgresql has been masked. postgresql-{base,server} are now the only relevant ebuilds. Stabilization requested in #320967 should also fix this bug.
GLSA request filed.
This issue was resolved and addressed in GLSA 201110-22 at http://security.gentoo.org/glsa/glsa-201110-22.xml by GLSA coordinator Alex Legler (a3li).