According to the modssl-homepage, there has been a security-related bug been fixed, so I suggest updating the mod_ssl dependency. From mod_ssl-CHANGES: *) Fix ssl_log() related format string vulnerability in mod_proxy hook functions.
this is what GLSA 200407-18 was about. People with apache installed would upgrade their mod_ssl. There apparently is a problem because apache-1.3.* ebuilds require a specific version of mod_ssl, and affected versions are still in the tree. People installing apache now would get an vulnerable mod_ssl, and would need reapplying the GLSA to get protected. zul : could you please look into it and correct the dependency ?
zul is apparantly away. Stuart will you look into this?
I'll look into this as soon as possible on Friday. Best regards, Stu
zul is away and stuart is away from anything resembling apache 1.3 so this is will take a bit longer than first expected.
Created attachment 37550 [details, diff] Patch to update apache-1.3.31-r2's mod_ssl dependencie. The change seems quite simple.I just bumped mod_ssl_ver to 2.8.19 . then I emerged both apache-1.3.31 and mod_ssl.from the logs ,the good versions are installed : [Tue Aug 17 21:33:09 2004] [notice] Apache/1.3.31 (Unix) (Gentoo/Linux) mod_ssl/2.8.19 OpenSSL/0.9.7d configured -- resuming normal operations
apache-1.31-r3 is now in Portage, and needs marking stable on all arches. Big thanks to magnet for testing this for me. Best regards, Stu
Arches please mark stable.
fixed on ppc
stable on alpha and ia64
Stable on mips
Stable on sparc.
Removed amd64@g.o from CC
amd64 please mark 1.3.31-r3 stable
Stable on hppa.
***bump*** amd64 please mark stable ***bump***
This will require a GLSA erratum (when ready).
Afaik the only thing used from the vulnerable mod_ssl version is: # setup eapi... myssl=${WORKDIR}/mod_ssl-${mod_ssl_ver}-${PV} cp ${myssl}/pkg.eapi/*.h src/include cp ${myssl}/pkg.eapi/*.c src/ap epatch ${myssl}/pkg.eapi/eapi.patch || die "eapi" $ diff mod_ssl-2.8.19-1.3.31/pkg.eapi/eapi.patch mod_ssl-2.8.18-1.3.31/pkg.eapi/eapi.patch 10c10 < ## Created on: 16-Jul-2004 --- > ## Created on: 27-May-2004 All other files in the directory are unchanged so I really think this is a minor issue and that we should not do anything GLSA wise.
...why would amd64 mark stable something it doesnt have a keyword for? !!! All ebuilds that could satisfy "mod_ssl" have been masked. !!! One of the following masked packages is required to complete your request: - net-www/mod_ssl-2.8.18 (masked by: missing keyword) - net-www/mod_ssl-2.8.17 (masked by: missing keyword) - net-www/mod_ssl-2.8.19 (masked by: missing keyword)
Because apache-1.3.31-r2.ebuild lists: SRC_URI="http://www.apache.org/dist/httpd/apache_${PV}.tar.gz ftp://ftp.modssl.org/source/mod_ssl-${mod_ssl_ver}-${PV}.tar.gz" and DEPEND="dev-lang/perl <=sys-libs/db-4.1 >=dev-libs/mm-1.1.3 >=sys-libs/gdbm-1.8 >=dev-libs/expat-1.95.2 >=sys-apps/sed-4 =sys-libs/db-1.85-r1 selinux? ( sec-policy/selinux-apache )" So it has nothing to do with net-www/mod_ssl-2.8.18.ebuild It's really a minor issue but I don't see why this minor fix cannot be marked stable? # diff apache-1.3.31-r2.ebuild apache-1.3.31-r3.ebuild 3c3 < # $Header: /var/cvsroot/gentoo-x86/net-www/apache/apache-1.3.31-r2.ebuild,v 1.12 2004/08/30 19:37:02 solar Exp $ --- > # $Header: /var/cvsroot/gentoo-x86/net-www/apache/apache-1.3.31-r3.ebuild,v 1.9 2004/08/30 19:37:02 solar Exp $ 9c9 < mod_ssl_ver=2.8.18 --- > mod_ssl_ver=2.8.19 15c15 < KEYWORDS="x86 ppc sparc alpha hppa amd64 ia64 mips" --- > KEYWORDS="x86 ppc sparc alpha hppa ~amd64 ia64 mips" 46c46 < epatch ${FILESDIR}/patches/${PVR}/00_gentoo_suexec_pam.patch --- > epatch ${FILESDIR}/patches/${PATCH_LEVEL}/00_gentoo_suexec_pam.patch
ahh... well dont i feel silly. stable on amd64.
Closing without GLSA.
