DoS issue in HTBound.c. See RH bug for details.
New HTBound.c was posted on the RH bug. text-markup herd: please bump with new file or advise.
solar/vapier/taviso/tigger any chance you could apply this. I guess we don't want to mask this one.
leonardop should have a look soon.
I have no problem committing a new patch including the new HTBound.c file. However, I would like to receive some confirmation that this new file has been audited and seems to be fine. From what I've seen, it hasn't made it to any RPM distributed by Fedora/RedHat and the RH bug report doesn't contain details about the code being inspected/approved, so I don't want to blindly commit a patch for a security bug. Maybe one of our security guys can check it out? https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=118820
vapier/solar/tigger/taviso please check.
scanned quickly, looks reasonable.
And the patch was checked and included in Debian security fix too, so it's probably safe to use here too. leonardop, please go ahead.
OK, thanks for the help. The patch has been committed with libwww-5.4.0-r4.ebuild.
Created attachment 71595 [details, diff] Slightly modified htbound patch The previous patch, likely when commited into CVS, had the $Id line from the original HTBound.c that was to be patched replaced with the appropriate $Id line for your patch. So when trying to patch the HTBound.c from the tarball downloadable at w3.org, it looks for the line: @(#) $Id: libwww-5.4.0-htbound.patch,v 1.1 2005/10/27 23:31:46 leonardop Exp $ but finds this line instead: ** @(#) $Id: HTBound.c,v 2.14 1999/02/22 22:10:10 frystyk Exp $ This causes the patching phase to fail and portage to exit. I've attached the slightly altered diff, but if this patch is to be stored in CVS, the same problem will likely occur again. Perhaps the change to the $Id line should be ommitted entirely as it doesn't really accomplish anything except complicate things.
It appears the patch for HTBound.c isn't working. Details in bug report #110662.
My bad; I didn't realise the inherent problem of including patches with CVS expansion strings on them. It should be fixed now.
Archs plz test and mark 5.4.0-r4 stable : Target KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 ppc-macos s390 sh sparc x86"
stable on ppc-macos
sparc stable.
Folks, I got the following while testing: checking for correct ltmain.sh version... no *** Gentoo sanity check failed! *** *** libtool.m4 and ltmain.sh have a version mismatch! *** *** (libtool.m4 = 1.5.18, ltmain.sh = 1.4.2a) *** Please run: libtoolize --copy --force if appropriate, please contact the maintainer of this package (or your distribution) for help. Would someone be willing to put this fix into the ebuild itself?
Fabian, 'elibtoolize' is not the same as 'libtoolize -c -f'. Please revert that change in the ebuild and adjust the logic for ppc-macos accordingly.
reverted elibtoolize change. b.t.w.: I tried compiling on ppc-macos without it at all, and that seemed to work out fine too.
amd64 stable
alpha done Cheers, Ferdy
x86 done
Stable on ppc and hppa.
Stable on ia64.
Marked ppc64 stable. Thanks
forgot to remove ppc64; sorry about the spam.
In fact I'm not sure this is worth a GLSA... It's a client crash trying to access to a malicious server... Denial of malicious service. We don't do browser crashes, and it sure looks like one.
I agree with Koon, this is not a security issue.
I agree about the no GLSA part.
Stable on mips.
