remove the URL functionality, which is a security hole that allows "rm -rf /"

the engine permits modules to write files to the game directory. it also provides /setenv and /openurl.

as part of /setenv, CL_Setenv_f() attempts to use putenv(), however, it does so WRONGly: it hands a stack-based variable to putenv(), meaning that the variable's memory is likely to be garbled by stack operations later. Sys_SetEnv() is not used.

as part of /openurl, Sys_OpenUrl() launches the given URL in a browser. if the BROWSER environment variable is set, then the function tries to run the program specified by BROWSER, as the browser. as a fallback mechanism, other common browser names are also tried. Sys_OpenUrl() is called by CL_OpenUrl_f(). Sys_OpenUrl() uses Sys_Fork() on UNIX-like systems.

Sys_Fork() takes a program path, tries to set the program's executable bit on the filesystem, and then tries to run the program.

an auto-downloaded ui module can act maliciously to execute "rm -rf /", or any other shell script desired. to do this (the description is given for only UNIX-like systems): first, the module should write the desired shell script to a newly created file; the system-path of the file can be determined by examining the fs_homepath and fs_game cvars. using /setenv, the module should then set the BROWSER environment variable to the system-path of the file. finally, the module can launch the "newly installed browser" using /openurl (with an arbitrary argument), which will set the executable bit of the said shell script file, and the script will be executed.

there is actually some additional trickery required to make these steps work. the bug in /setenv, described above, requires the ui module to call /setenv using EXEC_NOW, while being deep in the stack (for example, a sequence of nested, recursive function calls can be used), to place the said stack variable where its memory will likely survive. there is actually another bug in /setenv, which forces a space character to be appended to the given value, and thus the module has to choose, for the shell script, a file name that has a space at the end.

the engine also has additional support for opening a URL in a browser, in the form of a ui module callback.

on UNIX-like systems, the intended behavior is the following: the ui module open-URL callback translates to an invocation of the user-supplied "openurl.sh" script, if the script is found to be executable; the following directories are searched, in order: the current working directory, the homepath, and the basepath. excluding bugs and bad configurations on the user's side, the engine cannot place an openurl.sh script to these places. however, if such a script is placed by the user, the ui module can execute shell code as part of the system call to the openurl.sh script, with the use of shell-special characters. however, due to a bug, the callback translates to roughly a no-op (see the UNIX-like version of Sys_StartProcess() below).

on Windows, the callback translates to a system call. to exploit this, batch files can be written and then executed.

(note: Sys_OpenURL is not to be confused with Sys_OpenUrl, and vice versa.)

as part of the open-URL callback functionality, the Sys_OpenURL() implements the said intended behaviors. on UNIX-like systems, the subfunctions used are Sys_StartProcess() and Sys_DoStartProcess(). this Sys_StartProcess(), in the only way it is ever invoked, stores a command line in the static exit_cmdline string, and then shuts down the engine; nothing else uses exit_cmdline. thus, Sys_StartProcess() does not work at all on UNIX-like systems. the Windows version of Sys_StartProcess() is unused. Sys_OpenURL() is called by CL_OpenURL().

yet another obscure feature allows the server to direct a client to any URL, when the client tries to download a file from the server.

the feature is hit when DL_FLAG_URL is used by the server (although, as of recent times, the server never does so). when used, the client calls Sys_OpenURL() with the server-specified URL.

to close this security hole, the full set of the URL opening functionalities, along with the buggy environment variable setting functionality, is removed. such functionalities don't belong in the game engine anyway. in historic times, their existence and lack of security was permissible only because the engine only supported native libraries as modules, which is an all-encompassing security hole. the following are removed: /setenv, /openurl, CL_Setenv_f(), Sys_SetEnv(), Q_putenv(), CL_OpenUrl_f(), CL_OpenUrl(), CL_OpenURL(), Sys_OpenUrl(), Sys_OpenURL(), trap_openURL(), DL_FLAG_URL, Sys_Fork(), Sys_StartProcess(), Sys_DoStartProcess(), exit_cmdline, and some code in CL_ParseDownload().

even with this security hole fixed, it is estimated that this project still has supercardinally infinite open security holes.

the UI_OPENURL constant, etc. are actually not removed, to retain the ABI. these are to be removed later.
remove some remaining code related to temporary paths and PIDs

this is a prologue to the "Remove insecure pid file code. (ref. CVE-2012-3345)" commit
remove/simplify a bunch of path-related functions

installPath is only written, by Sys_SetDefaultInstallPath(), and is never read. these can be removed. the only use of Sys_SetDefaultInstallPath() is ``Sys_SetDefaultInstallPath( DEFAULT_BASEDIR );'', which is to be removed. the DEFAULT_BASEDIR macro can actually resolve to calls to Sys_StripAppBundle() and Sys_BinaryPath(), but these calls do not have side-effects. DEFAULT_BASEDIR and Sys_StripAppBundle() are left unused, and thus can also be removed. The only use of Sys_BinaryPath() can be inlined.

Sys_SetDefaultLibPath() is not used, and thus libPath always remains the empty string. these can be removed, and Sys_DefaultLibPath() can be simplified. Sys_DefaultBasePath() is a bogus, droppable declaration.

after the above steps, no functions of the form Sys_SetDefault<which>Path() exist. it makes sense to have a Sys_Default<which>Path() function for each <which> in {Base, Home, Lib, App}. however, Sys_SetDefaultBasePath() is instead called Sys_SetDefaultInstallPath(). the latter is renamed to the former.
remove some remnants of dushbag's backdoors
remove Sys_Chmod()

this function is unused, and doesn't belong to the engine anyway
remove the useless s_khz cvar

stolen from ioq3
remove a bunch of unused variables
when invoking kdialog, add a "--" argument before the message argument, just in case the message starts with "--"

something similar should be done with xmessage, but xmessage doesn't have support for that
constize AllocDebug()-like function arguments
tweak G_UpdateBuildableRangeMarkers() to add clarity

this is actually the PROPER(TM) version of 1d562fc08009a02b66aaad92d6d04c43350e247a.
silence some compiler warnings
drop some useless "./" path substrings
remove double ';'s
fix up some whitespace
various grammar/wording/spelling/etc. fixes
do not sink in liquid

when none of the up/down/left/right/forward/backward controls were held, the player started to sink in liquid. that wasn't really logical (swim down if you want to move down).

now, players float (and drift slightly) in water/lava/slime/etc..
fix the location where buildable bounding boxes are drawn

a bounding box should always be drawn where the player's movement collides with the box, not "around the graphical model".

the breakage was introduced by 5bf0cdfe6a74d48c33ef11ffc003d3e467b49d63. also, that commit should have had the following wording:

    draw bounding boxes with dimensions based the on values from the buildable property tables (currently implemented as configuration files: configs/buildables/*.cfg), instead of relying on the dimensions transmitted by the server.

    transmitted bounding box dimensions are limited to being XY-symmetric and having a square base. objects that have other bounding box dimensions will cause prediction errors and incorrect drawing of the bounding boxes.

    note: the (local player prediction) physics are still based on the server-transmitted values. that is, this change this doesn't cause physics to obey the dimensions in the buildable property tables.
do not position buildables too far away from their game-specified origin; display buildables even in air

- a bad design decision was: the cgame displayed buildables at a position depending on 2 traces: a box trace and a capsule trace. the end-position of the capsule trace was used if it didn't differ too much from the end-position of the box trace, and otherwise the end-position of the box trace was used.
- a bug was: the cgame displayed only stationary buildables, not ones in air.

ideally, for gameplay reasons, the graphical model should be displayed at exactly the game-specified origin, to best depict the hit-region of the object. but then, however, the graphical model may appear to float above the ground (this would happen on non-axial surfaces), and for aesthetic reasons, the graphical model could be somewhat displaced towards the ground, but not too much. also, graphical-model-displacement makes no sense when the object is in air.

now, only a capsule trace is done (no box trace). also, buildables are displayed in air.
fix shader remapping involving not-so-short shader names

a text buffer was WRONGly made too short some time ago (in d387e94973207991cdc9fb40278e219cd5a1bc2c)
in R_RemapShader(), use LIGHTMAP_NONE instead of 0 when registering shaders

using the map's first lightmap (#0) for remapped shaders is obviously WRONG, and causes flickering textures in some cases. the bogus 0 should have been LIGHTMAP_NONE or similar. LIGHTMAP_NONE will be used.

the effects of this change are not clear.

discussed with: gimhael