Please make a release

[smcv]

ioquake3 has had a lot of security fixes since 1.36 (2009), most recently today.

With ioquake3's current model of effectively only "releasing" automated builds from master, it is hard for users and distribution packagers to know what is a good time to update their ioquake3 clients or servers. Updating with every git commit to master is a lot of churn and risks regressions, and in practice nobody will (even if it is what "should officially be done", and likely still true even if the official ioquake3 launcher happens). Never updating is not an option (although I suspect many users and distributors do it anyway!) because 1.36 has multiple security vulnerabilities.

If the ioquake3 maintainers did occasional releases (anywhere between every few weeks and every few months, or any time a security bug is fixed, whichever is more frequent) of versions that have been tested more than random commits and are known to not have major regressions, then those releases would be a natural baseline for users and packagers to use.

There are many options for more elaborate release strategies, like having a development branch that gets the latest features, a stable branch that only gets serious bug fixes to minimize the risk of regressions, and periodically promoting a development release to be the new stable (examples everywhere, e.g. Linux and GNOME) - but any release strategy at all would be better than none.

With the ioquake3 version in Debian I'm effectively already labelling certain arbitrarily-chosen snapshots as pseudo-releases (by testing them a bit and uploading to Debian testing/unstable), and also labelling some arbitrarily-chosen ones of those pseudo-releases as supported with security and critical bug fixes for around 2 years (by them being the version that happens to have ended up in Debian stable, which has a time-based freeze). It would be great if I could choose these snapshots in a slightly more systematic way than "I have some spare time and I notice ioquake3 has updated" :-)

[smcv]

A "release" doesn't need to be anything dramatic or complicated, it could be as simple as copying the files that were output by Jenkins to a more friendly filename (e.g. copy release-linux-x86_64.zip to ioquake3-1.37-linux-x86_64.zip) and tagging the corresponding git commit.

[NuclearMonster]

Our primary target for users is on Windows. We need a build engineer to maintain installers for Windows, Mac, and Linux. It's more than a zip file.

[smcv]

If you're currently encouraging Windows users to download a particular artefact, then labelling intermittent versions of that artefact as an "official release" (even if it isn't the installer that you would like to have) seems better than leaving 1.36 as the latest thing-that-looks-like-a-release?

[Chomenor]

I don't think it would be so bad if modern zip files and instructions for how to use them (i.e. unzip into an existing valid install) were the first thing on the page when people click Download on ioquake3.org. A lot of the people running a classic game like Quake 3 and then looking for a patch like ioquake3 are tech savvy and will easily know what to do with it. The current download page with the out of date installers being the most prominent item is more confusing to everybody.

[smcv]

CVE-2017-6903 has been assigned for the vulnerabilities fixed in ioquake3, iortcw and openjk earlier today (just one CVE for all the engines because they're basically the same set of issues).

[ensiform]

I'd like to point out that only cl_renderer was at fault for OpenJK. Also, Q3 is still going to be more secure than RTCW/ET/JKA because they all use DLL/SO which can hook into memory anyway. Many mods do it for other things in the past when source was not open.

[smcv]

I'd like to point out that only cl_renderer was at fault for OpenJK

Right: for instance s_alDriver isn't a problem because OpenJK doesn't use OpenAL. It's possible that MITRE will want to split the CVE ID on the basis that some engines were only susceptible to a subset of the attacks, but I doubt it.

Also, Q3 is still going to be more secure than RTCW/ET/JKA because they all use DLL/SO which can hook into memory anyway.

Yes, if an engine is willing to execute arbitrary native code from auto-downloaded files then it clearly can't provide any sort of security boundary, whereas the bytecode interpreter might prevent a lot of attacks. I don't really trust the bytecode interpreter as a security boundary though (I don't think anyone has systematically audited all the "syscalls"), and I think the official policy from the ioquake3 maintainers is that executing arbitrary bytecode should be assumed to be arbitrary code execution, which is why I'm treating bytecode execution as dangerous in #130.

[NuclearMonster]

https://twitter.com/ioquake3/status/841806160751616000

Updated the generic help wanted ad and the blog post to note we need a release engineer as well.

[NuclearMonster]

I'm closing this issue because it is not actually an issue with the software as it is available in this repository, and the conversation is getting derailed. We don't use the github release mechanisms.

I agree that we need to get a release out, but we need engineering help. It's more than a zip file. Please feel free to hurl further commentary or encouragement at zachary@ioquake.org or on the forums or whatever. If you'd like to help find a build/release engineer, share the various messages with developers you know who are already doing it for other free software projects.