Distributing user-developed Linux software and licensing issues.

Tim ignored_mailbox at yahoo.com.au
Wed Jan 18 12:11:11 UTC 2006


On Wed, 2006-01-18 at 01:03 -0600, Kirk Black wrote:

> 1.  How do I protect my customers from receiving a modified version of the
> game client that is not authorized or recognized by my company?

Digitally signed packages that users can check against signatures
available from your website to check that the packet is unmodified.
This can be part of the installation process (i.e. automatic).

This frees you from having to serve out large wads of data for everyone
to download the software.  They can get it from anywhere, but verify it
against you (that's only a small amount of data traffic).

RPM can do this sort of thing already, it's not something knew that you
have to invent.


> While I'm sure copyrights and trademarks come into play, customers
> will make their decision in a matter of minutes that no amount of
> post-litigation can repair.

Surely it's going to be thieves who try to avoid paying for the
software, not genuine customers?  Such people are used to cracked
software being dodgy and causing problems.

Distribute your software, yourself, to the major download sites that
people will use.

Be very sure that your method of confirming paying customers playing the
game over a network isn't dependent on the potentially modifiable client
software.  Such verification has to be done on your servers, whatever
client software is being used.

> 2.  How do I protect the security of my MMO servers from malicious attacks
> arising from the abuse of having the full source code of my game client?

You have to do that anyway.  Even with closed source applications,
hackers wangle their way into servers.  They snoop the data being
transmitted and received, the decompile programs, etc.

You've got to be strict with the data that you pass between your
applications and servers, i.e. only ever have your applications do
precisely what they're supposed to do, don't fall for the "this'll do"
attitude, and likewise with your server.  If you program your software
so it only transmits exactly what it should according to your rules, you
can make the server so it only responds exactly how it should (i.e. make
no allowances and second guesses for errors that might be exploited,
treat such errors as exploits/attacks and outright disallow them).

On the other hand, if you play fast and loose, letting applications and
servers get away with not quite doing things right, you're opening up
all sorts of extra conditions that might be exploitable, because you've
not been able to test for all the possible things that might happen.

In a nutshell, this means making your software *good*, something that
you should be doing anyway.  I have no sympathy for any programmer who
thinks that they should be lazy and get away with it.

> 3.  Aside from server security, there is the matter of account password
> security.  How can I fathom giving away the full source code and thus giving
> anyone the ability to network snoop and easily grab customer
> account/password data?

Web servers are open source, and so are some browsers, they're both
capable of secure data transmissions.  Being open source isn't a
problem.  You've just got to use secure data transmissions, and that's
it.

What data you store on your server, keep your server secure, and only
transfer data securely.  What data the client keeps for itself, store it
in a way that's secure from remote exploits.

-- 
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.




More information about the fedora-list mailing list