I found this ebuild on http://www.trem-servers.com/ which adds support for 64 bit machines.
I have been testing it and have no complains about it.
The original link to the ebuild is http://dl.trem-servers.com/tremulous-1.1.0-r5.ebuild
Created attachment 153143 [details]
ebuild of tremulous 1.1.0-r5 with 64 bit support
*** Bug 147302 has been marked as a duplicate of this bug. ***
Created attachment 159624 [details]
Don't compile game libraries because they're not used
Current Tremulous version in Portage has several security issues - bug 132377 (remapShader command buffer overflow) and multiple server DoS weaknesses. This update fixes all of them and adds some new features (fast downloads using libcurl, new server and client side game features etc.).
This updated ebuild disables compilation of game QVM libraries because they're not used. Most servers require use of precompiled QVM libraries which are included in the source zip file.
Martin, thank you for the comment. Can you base your statement about security with an advisory, upstream channgelog or code analysis?
Yes, remapShader vulnerability has been fixed in ioQuake3 engine on revision 765 (http://svn.icculus.org/quake3?view=rev&revision=765). The fix has been merged to Tremulous on revision 778 (http://svn.icculus.org/tremulous?view=rev&revision=778). Current Tremulous version in Gentoo is based on revision 755 with no feature/bug patches which means it's still affected. For further detail, compare src/renderer/tr_shader.c from Tremulous source package on Gentoo mirrors with tr_shader.c from SVN revisions 755 and 778.
Any chance of the most recent ebuild getting into portage and obsoleting the vulnerable ones? Thanks.
Re-assigning to security as this should probably be handled like another vulnerability.
Created attachment 160215 [details]
Now with debugging support.
Added USE=debug support.
remapShader issue seems to be CVE-2006-2236. So other quake3 CVEs may apply as well, see also: https://bugzilla.redhat.com/show_bug.cgi?id=455458
(In reply to comment #9)
> remapShader issue seems to be CVE-2006-2236. So other quake3 CVEs may apply as
> well, see also: https://bugzilla.redhat.com/show_bug.cgi?id=455458
The updated ebuild is based on Tremulous SVN revision 971 which is based on ioQuake3 SVN revision 1133. CVEs listed in the link above are all fixed in this revision.
Hello?! Are you going to fix it already or are you going to leave the security hole open for another 2 years?
As there is no new release and we have to rely on patching, this mainly means that we have to get rid of games-fps/tremulous-bin (which has no stable versions anyway).
Trying to get some action into this...
I masked both packages until it's fixed in portage.
I think tremulous-bin was around for amd64 users because tremulous-1.1.0 compiled on amd64 was incredibly slow (QVM bytecode compiler was not available at the time so the QVM code was interpreted instead). This ebuild has full support for amd64 so tremulous-bin is not needed anymore.
the ebuild from trem-servers also includes the 971 patch (and so fixes the security issue right ?), maybe it should be pushed in portage, shouldn't it ?
You have globally masked tremulous and tremulous-bin, maybe you should just mask >=tremulous-1.1.0-r1 and >=tremulous-bin-1.1.0, so people who want to have a fixed version (like tremulous-1.1.0-r5 here) in their local portage overlay won't have to unmask it.
Patches are in 1.1.0-r2
Arches, please test and mark stable:
Target keywords : "amd64 ppc x86"
What about -bin, is comment #14 right? In that case it could be punted from the tree, I think.
tremulous-bin is gone.
x86 stable, all arches done
If we agree on B1, then this needs a GLSA, including a notice about -bin removal.
GLSA request filed by keytoaster.
All versions of games-fps/tremulous are still masked. Shouldn't the 1.1.0-r2 be unmasked already?