Bug#523323: missing source code

[Bruno Kleinert]

Am Samstag, den 24.10.2009, 15:28 +0100 schrieb Simon McVittie:
> On Sat, 01 Aug 2009 at 14:20:40 +0100, Simon McVittie wrote:
> > If you believe that suitable source code for OpenArena game data is not
> > provided, that would be a bug in openarena-data (a separate source package).
> 
> Unfortunately, it appears that this is correct:
> 
> * openarena-data contains .pk3 files (zip files)
> * of those, pak0.pk3 contains .qvm files (the "cgame", "game" and "ui"
>   modules), which are bytecode for a VM built in to the Quake 3 engine
> * the .qvm files are compiled from C in http://www.openarena.ws/svn/source/
>   using a non-free compiler (lcc)
Yes, 100% absolutely correct! :)


> Using gcc (main)
> ================
> 
> It should also possible to compile the cgame, game and ui modules as
> native code, by copying them into the openarena source package and defining
> BUILD_GAME_SO. I don't know how portable these modules are (the current
> packaging dodges that issue by having them as platform-independent bytecode,
> that was (presumably) compiled on i386), so this may cause build failures on
> 64-bit or big-endian architectures.
> 
> This would mean that openarena-data could be made suitable for main by
> removing the sourceless QVM files - but see below for compatibility.
> 
> Using lcc (contrib)
> ===================
> 
> openarena-data could be made suitable for contrib by working out what the
> corresponding source code is, providing it in the source package, and requiring
> that an external q3lcc be used to build it; however, see "Compatibility"
> below. This would also demote openarena (the binaries) to contrib.
> 
> (If doing this, it would be convenient if the required version of lcc was
> uploaded to non-free.)
I'm quite unhappy if we had to stuff OpenArena in contrib/non-free, so
I'd prefer trying to get the game logic compiled by gcc as shared
objects. ATM I'm wondering why upstream doesn't take that way and
instead ships precompiled stuff and keeps relying on a non-free build
tool..?!


> Compatibility
> =============
> 
> Confusing things further, the Quake 3 network protocol checks for
> compatibility by applying a simple checksum to the PK3 files. The checksum
> is based on the CRC32s of the unzipped *contents* of the PK3 file, so just
> unzipping and re-compressing the PK3 file shouldn't be a problem, but
> recompiling the VMs would be, as far as I can tell - unless Debian has the
> same "blessed" QVM files that are in upstream's svn, Debian openarena will be
> incompatible.
> 
> Since we're building Openarena from source anyway, we control the source
> code that computes the checksum, so it should be possible to have our
> Openarena cheat, and claim to other platforms' Openarena builds that its QVMs
> match the "blessed" upstream ones, even if they actually don't exist.
> 
> The best way to do this would probably be to include some sort of datafile
> containing the desired fake checksums in openarena-data, and patch
> openarena to look for them.
> 
> The checksums in question are:
> 
> * normal checksum: a checksum over the CRC32s of the zip file members
> * pure-server checksum: a checksum over the "checksum feed" (an integer
>   representing the ordered sequence of PK3s the server is using?) followed
>   by the CRC32s of the zip file members
> 
> so the fake checksum data would have to be a list of CRC32s of zipfile members
> to pretend to have. The checksumming expects them to be 4-byte little-endian,
> so the file could just consist of the raw bytes of the CRCs, in LE order. I
> have some untested code for this if you're interested in this approach.
I'd prefer this cheating way. Or maybe we can convince upstream to make
the engine check for network protocol versions only instead of doing the
whole checksum procedure. As you say, doing all this anti-cheat stuff in
free (!!) software is senseless anyway... or did I miss something?

Ok, for now I'll check out if I can make the engine compile the game
logic as shared objects in the hope we can get rid of any non-free build
tools.

Thank you very much for your helpful comments and work! - Fuddl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20091029/beff6dbf/attachment.pgp>