There's a double free error in openssl 1.0.0a, it seems it does not affect 0.9.*. See: http://marc.info/?t=128118169100001&r=1&w=2 Patch is at http://marc.info/?l=openssl-dev&m=128128256314328&w=2 No upstream update yet.
+*openssl-1.0.0a-r1 (10 Aug 2010) + + 10 Aug 2010; Samuli Suominen <ssuominen@gentoo.org> + +openssl-1.0.0a-r1.ebuild, +files/openssl-1.0.0a-fix-double-free.patch, + +files/openssl-1.0.0a-ldflags.patch: + Use environment LDFLAGS wrt #327421 by Olivier Huber. Fix double free wrt + #332027 by Hanno Boeck. Since it's only ~arch, close as FIXED ?
yes, security does not track ~arch
Just fixing the whiteboard…
According to a post on oss-security, this is also an issue in 0.9.8: http://article.gmane.org/gmane.comp.security.oss.general/3298
ive added the patch to openssl-0.9.8o-r2, so that i imagine should see some testing and a stable push (if someone wants to update the whiteboard)
CVE-2010-2939 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-2939): Double free vulnerability in the ssl3_get_key_exchange function in the OpenSSL client (ssl/s3_clnt.c) in OpenSSL 1.0.0a, 0.9.8, 0.9.7, and possibly other versions, when using ECDH, allows context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code via a crafted private key with an invalid prime. NOTE: some sources refer to this as a use-after-free issue.
Sorry about the delay. Arches, please test and mark stable: =dev-libs/openssl-0.9.8o-r2 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
How much work has been put into making sure that OpenSSL 1.0.0 works with the stable tree? Samuli, I think you invested most time into this thingie.
(In reply to comment #8) > How much work has been put into making sure that OpenSSL 1.0.0 works with the > stable tree? Samuli, I think you invested most time into this thingie. Forget about this comment. But: This blocker is somehow fatal, as an unmerge of the old OpenSSL leads to wget not working anymore, which makes an update impossible. Is there a known workaround? I tried porting to EAPI 2 for the new blocker syntax, but that did not work out here. USE="gmp kerberos sse2" gatt -w 332027 =dev-libs/openssl-0.9.8o-r2 +m+ resolving masked dependencies... +m+ executing 'FEATURES="collision-protect test" /usr/bin/emerge -pq =dev-libs/openssl-0.9.8o-r2 --ignore-default-opts'... +m+ waiting for "FEATURES="collision-protect test" /usr/bin/emerge -pq =dev-libs/openssl-0.9.8o-r2 --ignore-default-opts"... [ebuild NS ] dev-libs/openssl-0.9.8o-r2 [0.9.8o] [blocks B ] =dev-libs/openssl-0.9.8*:0 ("=dev-libs/openssl-0.9.8*:0" is blocking dev-libs/openssl-0.9.8o-r2) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. ('installed', '/', 'dev-libs/openssl-0.9.8o', 'nomerge') pulled in by >=dev-libs/openssl-0.9.7i:0 required by ('installed', '/', 'dev-db/virtuoso-server-6.1.1', 'nomerge') >=dev-libs/openssl-0.9.7i:0 required by ('installed', '/', 'dev-db/virtuoso-odbc-6.1.1', 'nomerge') ('ebuild', '/', 'dev-libs/openssl-0.9.8o-r2', 'merge') pulled in by dev-libs/openssl required by ('installed', '/', 'media-video/gpac-0.4.5-r1', 'nomerge') dev-libs/openssl required by ('installed', '/', 'net-fs/netatalk-2.0.5-r1', 'nomerge') dev-libs/openssl required by ('installed', '/', 'dev-lang/python-3.1.2-r4', 'nomerge')
encfs-1.7.2 fails to configure with 0.9.8o-r2 but it works with 0.9.8o. I wonder if there are more packages that fail with this version of openssl.
SLOT="0.9.8" of openssl-0.9.8* is not ready yet. SLOT="0" of openssl-1.0.0* is not ready yet. I don't know why arch's are in CC here, I don't see anything that's ready to be stabilized from this bug yet. Bug 330437 tracks the future OpenSSL 1.0.0 stabilization, arch's are not CCd in there yet for a purpose.
The stabilization is now proceeding in bug 330437.
Adding arch's back so they know this is a security issue: See bug 330437 for stabilization.
Stable for HPPA PPC.
arm/ia64/m68k/s390/sh/sparc stable
x86 stable, last arch. Updated whiteboard to GLSA request.
This will get a GLSA together with #303739 #308011 and #322575.
This issue was resolved and addressed in 201110-01 at http://security.gentoo.org/glsa/glsa-201110-01.xml by GLSA coordinator Tobias Heinlein (keytoaster).
