Oolite Bulletins

This thought was prompted by something I read in the Discussion category...

Since Oolite is an online-only available game, would it be possible for the program to be able to update itself live from the source repositories?

I don't mean for the executable and such, but for things like scripts and plist files. It would be a useful thing to include since it would allow OXPs to be automatically updated, the main equipment, ships, HUDs and such to be updatable, and for sneaky little scripts to be included that might trigger a mission to the total surprise of the player.

Brilliant idea!! I don't know how much work this would entail, but it would be a fantastic idea! almost like an interactive story line to any oxp, that could be played as it developed. Almost like a nightly build. I think its a brilliant idea that would need some careful thought but could be an avenue not yet tapped in oolite. The idea of a group of individuals designated so to speak to certian Mission OXP which was added to daily or otherwise.

Hmm I'd be worried about the security aspect. It would also mean thorough testing of OXP's before letting them loose.

It actually wouldn't be that hard to do - I'm sure there are small, portable HTTP libraries that can be used to do the job. (And even if there are none, HTTP is so simple it would be trivial to implement one that does all we need, or even just use our own protocol. The beauty of using HTTP is that anyone could set up a mission repository using free or cheap hosting). The operation would consist of:

- On a new thread, Oolite periodically sends some commander data to the web server using an HTTP POST request. The sort of stuff you'd send is rating (number of kills) and amount of cash, current location, and what missions had been completed/are currently in progress. (This could be done by generating a GUID, and having the server remembering what it's sent to you by keeping track of GUIDs - however, this means the list of missions you've done are only kept track of per server. If the game instead sends the list of missions complete, this would work across different servers).
- the server looks at candidate mission or ship OXPs for the commander's current rating and location, and sends it in reply to the HTTP POST
- Oolite then saves it to AddOns and loads this OXP on the fly.

With a system like this, the player can choose any mission repository they like. Or possibly several. It's entirely up to the player.

On the server side, there'd almost have to be some kind of dependency system (such as don't make mission Y available till mission X is complete).

The security aspect is pretty much the same as downloading OXPs right now - you have to trust that the author isn't trying to break your Oolite installation! It wouldn't hurt to have the option of GPG signing OXPs though, and have 'official' mission servers that only put out missions and other OXPs that have been checked to be OK.

That's a cool idea! **approves**

Selezen wrote:

That would involve writing internet connectivity into Oolite. I that really necessary?

Having a list of the OXP's installed would be easy enough, seeing as the stderr.txt file lists the ones installed during startup.

https://bb.oolite.space/viewtopic.php?t=1128

Pardon me for switching bits I'm fiddling with -- but I think this will add more to the game than mucking with sound loops so I think I might go forth and network, and reserve mucking with sound loops for later.

I would be a bit wary of OXP updates unless you implement the feature where they ca be "signed" in some form that can only be done by certain trusted people.

If I choose to download an OXP, or a new version of one I have, and it breaks game, at least it was a concious decision. I'd hate to see everyone's games breaking due to an automatic update because an OXP wasn't tested properly or was deliberately malicious.

Updating the oolite exe and resources is a good idea, but again, as long as it isn't too easy for a troublemaker to drop in a new version that isn't "official".

I wouldn't do it in a thread though, I'd do the checking before the first "demo" page comes up, and only if a command line flag was present.

And it would be nice if you could do this in a way that works on Windows too...

TGHC wrote:

Hmm I'd be worried about the security aspect. It would also mean thorough testing of OXP's before letting them loose.

As Winston said, the security aspect would be minor, since Oolite is (I would hope) trusted software, and wouldn't be doing anything dodgy. If you have any worries about what it's doing, then look through the source code.

I don't know what risks there would be from third parties though - could a hacker use the Oolite connection to access a computer?

The OXP issue is a good one too - although any OXP writers should be thoroughly testing thier work anyway, right? Right?? However, maybe opening up Oolite to downloading every OXP automatically isn't the way to go - there should be a repository of OXPs that have been authorised as open to live update. Many players wouldn't want to have EVERY third party OXP installed, and may not want ANY installed!

Anyway, this is pretty exciting stuff - it opens Oolite to a much more interesting concept, that literally anything could happen at any time!

Also, so many other things could be done:

- there could be a plist file containing the Commander info of a good many of the players (excluding Jameson, of course) accessed through a file stored on the server. This file could have the name, ship, legal status and maybe current location of the player's last save. The player might then see these commanders show up in game (maybe a slight HUD mod to show the name when one of these ships is encountered).

- new ship skins could be added, and ship lists modded to include them on the fly.

- new equipment!!

- and so on.

Firstly, as I already mentioned, I plan to use GPG to sign OXPs. This means any OXP in the automatic system will have to be approved by someone - at least the owner of the server its coming from (and if it's not one of the servers listed in the game package that users download, the user would have to consicously get the GPG signing key for the new server). By default, dynamic updates (aka 'surprise OXPs') will be turned off.

Doing it on the fly (i.e. not waiting around for the user to restart the game) allows more potential for what can be done by the OXP. But that's a way off yet.

Firstly, I need to think up a specification (server/host communications). I also would want to do it in a way that the server can be used as a metaserver for Spooky's putative multiplayer Oolite, so not write anything too limiting.

I wouldn't worry about getting it to run on Windows - the code for getting the OXPs is likely to be extremely generic and would probably run on anything with a TCP/IP stack. Since Microsoft used the Berkeley TCP/IP stack, it's the one bit of Windows that actually works multi platform (they even implemented select() - pity it only works for TCP/IP). I'm going to start off by looking for suitable libraries for both GPG signing and HTTP requests in any case. For HTTP requests, if I find nothing suitable, then it's not really hard to roll our own. For GPG, if there is no suitable library, GPG itself is multiplatform and can be called externally (but I would want to avoid that if at all possible). Of course, licenses then may become an issue as GPG might be GPL - I don't know, I've not checked yet.

I’m pretty sure GPG is GPLed, although I can’t be buggered to check it right now. The library might be LGPL. Don’t get too attached to GPG, though; there is almost certainly a BSD or MIT-licensed assymetric crypto library out there. Also note that RSA is no longer patented.

libgcrypt is LGPL. I've not found an alternative library to libgcrypt (which is rather full featured - we only need to be able to check signatures - I was looking for a library which does only that. On the other hand the Linux shared library is only 900K and most of it wouldn't get paged into memory anyway).

is that crypto stuff still illegal in the US?

(not trolling or flamebaiting, me, just that I seem to remember that some crypto stuff can't be distributed there)

No, no. It was illegal to export[/] strong crypto from the US in computer-readable form. There also used to be patent issues regarding RSA and derived algorithms. AFAIAA neither is an issue now.

Even so, OpenBSD do their crypto development entirely outside the USA just to be certain they don't fall foul. But then again, the OpenBSD crowd are paranoid. But considering what most people use OpenBSD for, you WANT them to be paranoid! (Hmm...I wonder if OpenBSD has some signature checking code that can easily be lifted).