Package: iortcw / 1.51.c+dfsg1-3


Package Version Patches format
iortcw 1.51.c+dfsg1-3 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
All Rend2 Stub out USE_BOX_CUBEMAP_PARALLAX on GLSL 1.30.patch | (download)

MP/code/rend2/glsl/lightall_fp.glsl | 2 1 + 1 - 0 !
SP/code/rend2/glsl/lightall_fp.glsl | 2 1 + 1 - 0 !
2 files changed, 2 insertions(+), 2 deletions(-)

 all: rend2: stub out use_box_cubemap_parallax on glsl < 1.30

Part of r_cubemapping patch by smcv

build Link game cgame ui modules to LIBS.patch | (download)

MP/Makefile | 12 6 + 6 - 0 !
SP/Makefile | 12 6 + 6 - 0 !
2 files changed, 12 insertions(+), 12 deletions(-)

 build: link game, cgame, ui modules to $(libs)

All three modules call mathematical functions like atan2(). On glibc
systems, when compiled to native code with an ordinary C compiler
(as opposed to bytecode from q3lcc), they get the definition of those
functions from libm.

Until now, they were not explicitly linked to libm, and instead relied
on the fact that libm is linked into the main executable. However,
doing it this way defeats glibc's symbol-versioning mechanisms, and
can fail in some situations, in particular binaries built with
-ffast-math on a pre-2.31 version of glibc (where atan2() resolves to
__atan2_finite()), and used without recompilation on a post-2.31 version
of glibc (where __atan2_finite() has become a deprecated hidden symbol
that is only available as a versioned symbol).

When building shared libraries and loadable modules, it's most robust
to link them explicitly to their dependencies, as is done here.
$(LIBS) also includes -ldl, which is unnecessary but harmless.

debian/Disable client side auto download by default.patch | (download)

MP/code/client/cl_main.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 disable client-side auto-download by default

This feature is a security risk: it downloads executable bytecode.
The interpreter is sandboxed, but a reasonably determined attacker
can probably break out.

Upstream rejected changes in this direction, but we want them in Debian

debian/File access methods prevent overwriting DLLs CVE 201.patch | (download)

MP/code/qcommon/files.c | 12 8 + 4 - 0 !
SP/code/qcommon/files.c | 10 10 + 0 - 0 !
2 files changed, 18 insertions(+), 4 deletions(-)

 file access methods: prevent overwriting dlls (cve-2011-3012)

This is a known feature regression: it prevents mod DLLs from being
unpacked from PK3 files (FS_CL_ExtractFromPakFile), making it
considerably harder to install mods that contain arbitrary native
code (such as those designed for retail RTCW). The opposite
change, re-introducing the vulnerability, was made in commit
<> in order
to fix FS_CL_ExtractFromPakFile.

However, the feature that regresses here cannot be supported without
re-introducing Quake III engine vulnerability CVE-2011-3012, and
breaking some mods seems like a lesser evil than letting
auto-downloads execute arbitrary and potentially malicious native
code, either via a direct unpack of native code or via QVM code
being allowed to open and write a file with the platform's DLL

FS_CL_ExtractFromPakFile relies on the vulnerable behaviour and is
useless without it, so stub that out too.

Add the same checks in SP file-copying code, for completeness
(although in practice SP should never execute code not provided by
either the retail RTCW binaries, iortcw or a deliberately-installed
mod, because auto-downloading from a server is not applicable there).

Upstream rejected this change, but we want it in Debian anyway.

debian/Remove support for downloading executable updates.patch | (download)

MP/code/client/cl_main.c | 163 2 + 161 - 0 !
MP/code/qcommon/qcommon.h | 6 0 + 6 - 0 !
MP/code/sys/sys_unix.c | 20 0 + 20 - 0 !
3 files changed, 2 insertions(+), 187 deletions(-)

 remove support for downloading executable updates

This was off by default, which is good, because downloading
and running unauthenticated code is a serious security issue.

Upstream rejected changes in this direction, but we want them
in Debian anyway.