[crossfire] SVN revions in version

[Christian Hujer]

On Friday 13 October 2006 19:15 Brendan Lally wrote:
> On 10/13/06, Alex Schultz <alex_sch at telus.net> wrote:
> > A few times, tracking the svn revision instead of the $Id strings has
> > been brought up. IMHO this should be done, both in the client and
> > server. I propose we implement it as follows in both:
> >
> >  ....
> >
> > This version would both be used in the client for outputing to the
> > console instead of the rcs-id values, and the server will use this
> > version for reporting to the metaserver as well as console output. Does
> > this model make sense to everyone?
>
> I'm not sure it is such a great idea to send the revision number to
> the metaserver, certainly not if the metaserver is going to push that
> information out to clients, in that case, someone who wished to be
> annoying could look for servers with revisions predating certain bug
> fixes or balance tweaks and abuse or exploit them.
Oh really? Yeah, there's so many different crossfire servers out there that I 
really need this information to choose the right ones to attack, otherwise 
the chances of finding a bogus one are hopeless ;-) (I hope it was obvious 
that I was ironic ;-)

> If you are talking about sending the revision as a seperate field to
> the metaserver, that isn't for propagation to clients. then that is a
> different issue altogether, and could provide useful information about
> things like how quickly updates are made available in practice.
>
> Likewise, although the clients need only open a connection to the
> metaserver to recieve the server list, having the official clients
> send their revision numbers by default would give some indication as
> to which versions of the clients are in use. (assuming the metaserver
> were suitably modified to read that information from the socket).
Oh that would make it easy for a bogus server to abuse or exploit known client 
bugs to hack client machines.

If balancing protecting clients from abuse vs. protecting servers from abuse, 
I'd say protecting clients is more important for several reasons:
* There are more clients than servers (yes, even for crossfire ;-)
* A typical client user puts blind trust in client software.
* A typical server admins knows of the dangers of running public services.

I definitely vote for including the server's revision in the meta server in 
public. This allows players to tell the mapset and set of bugfixes a server's 
most likely to be using. You could always make this field optional so anxious 
server admins can exclude that field from the metaserver information.

I know that Brendan might have talked about game balance issues, not security 
concerns, yet I'm pro eventually optionally) including the server's revision 
in the metaserver.

My 2 cents


Cher :)
-- 
Christian Hujer
Free software developer
mailto:cher at riedquat.de
http://www.riedquat.de/
PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061013/4fbd2d1e/attachment.pgp