From yann.chachkoff at myrealbox.com Sat Apr 1 05:06:46 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat, 01 Apr 2006 13:06:46 +0200 Subject: [crossfire] Invitation for developers to a vacation. The CF party Message-ID: <1143889606.c7cb73bcyann.chachkoff@myrealbox.com> Gabriele Dini Ciacci a ?crit : >> I write this mail to invite all cf developers to my Lake house for >> a week end. >> >> Date is from friday 28 april (arrival) to sunday 30 of april (or >> monday 1 of may, I'm very frlexible, your leaving just depends on >> the day you find a cheap fligth) >> >> The week end can take various form, for example as a round table >> talking about 2.0 release, as a way to gather photos of us all >> togheder for the site, as a vacation to the wonderful place as >> "Lake D'Orta" (for free), or as an occasion to just meet people you >> talk from years. >>Do i bring my roleplay books? :D > We are to few players and we have by FAR many thigns to see :) (and to eat...) Eating is compatible with roleplaying :). Do I bring my RPG *and* cooking books ? :D >> >> The invitation is open to all developers of cf, or contributors or >> people that has come in contact with me and interacted in some >> pacific way over irc, this exclude flamers and nasty poster, cause >> I fear they would flame in real life too, but, if they promise to >> be nice, it can be a good occasion of redention and to become all >> again all freinds and close some old still bleeding wound. I promise to try to be nice. :) >>Does someone provide the swords? > Should have enoght cuttign material for all the salami you can eat :D I don't think he had salami in mind... >> My house has if I rember well 14 bed, and 3 bathrooms (italian >> style, so they are "complete"), It may surprize you, but most Belgian bathrooms are complete as well :). >> the bedrooms are only 5, the other rooms are located in living rooms. >> >>Do you populate bedrooms before arrival with welcome gifts? >> >Wellcome girls only.. sorry Well, could you send the folder in which we can choose the Welcome Girl we want ? Or are those just standard "fit-for-all" models ? :) >> Wife and GF are admitted and well accepted (it's an occasion to >> enjoy all togheder) >> >>What kind of 'enjoyement' did you plan with other CFers GF/Wife? > >While you are occupeied with wellcome girls I will unit test your GF/Wife I doubt you'd want to Unit-test mine, unless you like extreme sports. Besides that, I'm not sure she'd be able to come - it will depends on her work planning, which will be only known next week. >> Food expenses will be divided between all, do not expect more than >> 10 euros each day per person, wine and alcholic excuded. >>Do Belgians have to provide the real Beer? >Presents are allways wellcome, but you will have to drink it all :D Ok, so I'll drink my wafels myself, then :). >> People has confirmed and has hi probablity to come >> gros (as tchize luggage or with a normal big plane) For the 29-30/04 WE, that's not possible for me, I have an important job meeting on the 29th (Yeah, me, working on a Saturday, how awful !). Around the 6th-7th WE would be perfect (and cheaper for the flights as well). >>I heard the wheel seats are cheap but very cold during flight >eeh I've heard that as well. But I've also heard that the view is much better on the tail. >>PS has been suggested to postpone one week the meeting, as flight are >>way cheaper at week-end of 6-7 may. Am ok with it. >Suggestion was from me! :) >Sure portponing it a week make it MUCH cheaper for everyone!! >Let's do it, so come in the week-ed AROUND 6-7, come before or after is >no problem, stay as much as you can, at least 5 day is best so you can >see Milano and Bergamo too (apart Lake house) > Ok for me then. Should probably be from Thursday, 4th to Tuesday, 9th (or Monday, 8th, will fix that Tomorrow). > Best Regards Gabriele Dini Ciacci From tchize at myrealbox.com Sat Apr 1 07:10:49 2006 From: tchize at myrealbox.com (tchize) Date: Sat, 01 Apr 2006 15:10:49 +0200 Subject: [crossfire] Random encounters In-Reply-To: <20060401015206.GA6516@elmex> References: <20060401015206.GA6516@elmex> Message-ID: <442E7BD9.6060008@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robin Redeker a ?crit : > Hi! > > Is that right what i just read: The random encounters where took > out of the code around 2001? Why was it removed? Is it possbile to > reimplement it? > > Robin > Not used, not maintained, and if i remember well, activating it (using a C define) made code uncompilable. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFELnvYHHGOa1Q2wXwRAhsOAJ4j+xVX1JFkE013RmRY1h6qPT14PwCgo15n FeGJi8icIv5VLWj5v9zPjMg= =CBaG -----END PGP SIGNATURE----- From tchize at myrealbox.com Sat Apr 1 10:04:13 2006 From: tchize at myrealbox.com (tchize) Date: Sat, 01 Apr 2006 18:04:13 +0200 Subject: [crossfire] Yet another crossfire fork. Recruiting. Message-ID: <442EA47D.8050400@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some of you might have noted in the last few months I was not very active as a devel in the crossfire community. Various reasons surrounded it. If you dig a bit, you'll remind i was planning a french based crossfire server. This mean a lot of work in term of code and quest design. (protocol modifications, map format, string translations). I couldn't do it alone. But luck was on my path in november 2005, during a trip in Africa. Amongst trip mates there was someone with too much money. I explained him about GPL, the interresting future of opensource products in general and the buisness model behind it. I managedto convince him this could *not* be applied to the gaming industry. We discussed marketing strategy during a few days, just for the fun, putting aside all possiblities to make money with a GPL game. This overall was just a fun discussion. While for other softwares you can rely on the service, it's more difficult to do it in game industry. Even the wow based model with fees didn't look viable (and i understand know why you must also buy WoW). Guildwars was a proof it's better to make money on the game than on connection. Then i remembered of that old commercial game based on cf lib and i got a really stupid idea (I get about 20 stupid idea a day). This one was not as stupid as flying by night with an ultralight but it was not far. Around half of december, He created a company that would drive a projet based on that stupid idea, located in Toulouse France. He phoned me and we got about this conversation. - - You remember that idea you had in Niger? He said me. - - Which one? - - The one you had last friday evening. - - Ha yeah, *that* one? (Laughings) - - Yes, that one.... I did it! - - ...? - - It's viable, I checked it, we just targeted the wrong audience Following was a lenghtly explanation of it's targeted audience, he thought of a target i never thought about and indeed it's a well paying target :) Imagine my surprise :) He asked me to lead the project. However, for personal reasons, i did not want to leave belgium and my job at that time and we agreed i'll do a part time consultancy work on the project while he would pay a few experimented people and a bunch of juniors to work on an opensource game. We also decided to use crossfire as the basis of our code. The project is far from reaching the shelves for now but it's in a good shape. Most important, it has the money to survive at least until 2010. The problem now is to have those modification respect the GPL standards. I studied the possibility to integrate it in the crossfire main cvs, but lenghtly disscussions on mailing list for every change in code did not have a good impact. Unfortunately, the best solution was similar to the one used by Cedega: - - forking from original project to keep control on revisions - - move patch from crossfire project to ours as they are commited, using a special email account which shedule them for integration - - no release of public binary packages (well in fact it doesn't really matter considering the commercial model designed) I'd like to explain more, but information is currently still quite sensible. Now, enough for background story, i get to the point of this email! For the project we want to hire 3 people having a knowledge related to the crossfire project. Additionnal information on the company / project can be given to candidates, providing they agree first on a non disclosure agreement. Title: Alien code integration leader Available positions: 1 Role: You will be responsible to document and survey all processes of integrating patches coming from external projects to the company internal repository (downpatching). You will also select and prepare patches to submit to the external project as bug fixes or improvements (uppatching). You will select the data to be uppatched by balancing company confidentiality requirement and code maintenance facility. You will be the central communication point with other open sources teams, and the crossfire team in particular. Your political skills will be very important. You will be part of the project leading staff and you opinion about balancing confidentiality and GPL restriction will be very important to the success of project. Required knowledges: Good knowledge of crossfire project and proven activity in the last 2 years Strong proven skills in C language Very good relational skills Fluent in English Able to express itself in a French on technical programming and legal subjects Contrat duration: 3 years Salary: 5000 brut euros/month (can be negociated) Location: Toulouse, France Title: Quest leader Available positions: 2 Role: You will be responsible for the coherency of all game quests. You will design the long run plots and organize the job of the various map makers. You will communicate explicit requirement to the developpement team for map add-ons requiring coding. You will gather with the other quest leaders once a week for the cohesion of the different quest branches. You will provide clear documentation on every quest your team is working on, as long as their development status. You will also have to interact with the graphical design team to ensure a good balance between quest requirements and design team scheduling. Required knowledges: Proven experience in game story writing Ability to drive a team and respect scheduling Strong written communication skills Fluent in French Basic knowledge of English Assets: Experience with the tool 'Questflow' is a plus Basic knowledge of current crossfire game limitations is a plus Contract duration: 3 years Salary: 4000 brut euros/month (can be negociated) Location: Toulouse, France The company can provide an appartment to foreign applicants. End of applications: 1st may, 20:00 GMT For organisational reason and to prevent abuse, please send response to mailing list, you will be recontacted with practical information on where to send your CV. If you want additionnal information under non disclosure agreement, submit your request to mailing list, we will take appropriate measure to recontact you. Regard David Delbecq "Tchize" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFELqR9HHGOa1Q2wXwRAhQFAKCXNZzzkFj+824VgIuuv4i/AhtI+QCgtFr1 ZTGYXEHp9P/BGK5Qhb0rMAc= =Sqia -----END PGP SIGNATURE----- From elmex at ta-sa.org Sat Apr 1 14:07:48 2006 From: elmex at ta-sa.org (Robin Redeker) Date: Sat, 1 Apr 2006 22:07:48 +0200 Subject: [crossfire] Yet another crossfire fork. Recruiting. In-Reply-To: <442EA47D.8050400@myrealbox.com> References: <442EA47D.8050400@myrealbox.com> Message-ID: <20060401200748.GA2781@elmex> Hi! > The project is far from reaching the shelves for now but it's in a > good shape. Most important, it has the money to survive at least until > 2010. The problem now is to have those modification respect the GPL > standards. I studied the possibility to integrate it in the crossfire > main cvs, but lenghtly disscussions on mailing list for every change > in code did not have a good impact. Unfortunately, the best solution > was similar to the one used by Cedega: > - forking from original project to keep control on revisions > - move patch from crossfire project to ours as they are commited, > using a special email account which shedule them for integration > - no release of public binary packages (well in fact it doesn't really > matter considering the commercial model designed) It is not clear to me: Will you publish the source code? Robin -- elmex at ta-sa.org / robin at nethype.de / r.redeker at gmail.com Robin Redeker From nicolas.weeger at laposte.net Sat Apr 1 14:51:29 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 01 Apr 2006 22:51:29 +0200 Subject: [crossfire] Player-owner shop proof of concept In-Reply-To: <441C37AB.3070903@laposte.net> References: <441C37AB.3070903@laposte.net> Message-ID: <442EE7D1.8070905@laposte.net> Hello. Here is the second version of my player-owned shop package. The shop's tiles should certainly be unique to keep items, else players may be annoyed by their loss :) How that works: the tile in (0, 0) is unique, and the floor, through keys/values, stores information concerning shop's owner and account (sum of sold items). Owner has a private room, where he can set a price for items (which then get the unpaid flag set), and get money from sold items (commands to say near table are "sell", "account", "get". "buy" will buy shop if no one has it already - i think you can buy it again lol) At first, shop is free to buy, so anyone can enter the owner's room, and say "buy" to buy. Price is 2000 platinum, arbitrarily :) Please note that those Python scripts will *not* work for now as I had to tweak the plugin system. Sourceforge'CVS being down I can't yet commit :) Also, the price estimation seems quite weird - you set the price to eg 2000 silver, and player will pay ~500 platinum :) I suspect it's due to the query_cost and such functions using charisma / shop specialization / ... It's not a really clean thing, but it does work for now. Feel free to comment / tweak it to suit your needs. Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: shop.tar.gz Type: application/gzip Size: 2351 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060401/576ed7e7/attachment.bin From elmex at ta-sa.org Sat Apr 1 15:54:02 2006 From: elmex at ta-sa.org (Robin Redeker) Date: Sat, 1 Apr 2006 23:54:02 +0200 Subject: [crossfire] New GCE release Message-ID: <20060401215402.GA2986@elmex> Hi! we have released a new version of GCE. Now we also have auto join. It works a bit different than the java editor auto joining, but it's IMHO more sensitive to what the map artist wants (at least it's what i would want). To use autojoin just click on the _0 arch in the picker (similar to crossedit). See http://cf.schmorp.de/editor.shtml Robin -- elmex at ta-sa.org / robin at nethype.de / r.redeker at gmail.com Robin Redeker From mwedel at sonic.net Sat Apr 1 20:29:10 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 01 Apr 2006 18:29:10 -0800 Subject: [crossfire] Random encounters In-Reply-To: <20060401015206.GA6516@elmex> References: <20060401015206.GA6516@elmex> Message-ID: <442F36F6.1050409@sonic.net> Robin Redeker wrote: > Hi! > > Is that right what i just read: The random encounters where took out of > the code around 2001? > Why was it removed? Is it possbile to reimplement it? The implementation that was there was IMO more a pain than worthwhile. Basically, with some probability, groups of 3 spaces of the same terrain time would become a special random map, with some creatures on it. The fact those 3 spaces were an encounter map were not visible. So you'd be walking through the forest, and poof, your suddenly on this encounter map that you now need to walk for 40 spaces (killing any creatues on it) to get back to the world map. The encounter maps would only happen if there was the same terrain type in the 3x3 area. So you'd get lots of cases where you wouldn't get them either because of mixed terrain. The encounter type was based on the given terrain, so at level 5 or so, the monsters you'd encounter on grass spaces just started to become a pain and not any real challenge. I think in the end, pretty much every server disabled the encounter maps because they were so annoying, so there was little point to keep them around. That encounter code in no way is close to the other ideas mentioned of terrain periodically generating monsters, but these remain on the world map, and not special encounter maps. From yann.chachkoff at myrealbox.com Sun Apr 2 01:00:13 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun, 02 Apr 2006 09:00:13 +0200 Subject: [crossfire] Yet another crossfire fork. Recruiting. Message-ID: <1143961213.c7c5c51cyann.chachkoff@myrealbox.com> Sir, I'd be interested to get more practical informations about your proposal, which may sound as an interesting way to make my professional path a little more interesting. Please provide me with additional informations on the following email address: yann dot chachkoff at gmx dot net. Given that a meeting between us was scheduled on this afternoon, it would also be a good opportunity to bring a copy of the Non-Disclosure Agreement you require, so that I can sign it and get to examine your offer furthermore. I also take the opportunity to remind you the existence of some scenaristic material related to the "Crossfire in French" project. I'd like to know: 1. If that material conflicts with any material that is to be published in the commercial game; 2. Depending on the answer to point 1, if that material is still of any relevance; 3. If I should take your email as an official "Haltbefehl" to any writing work related to Ailesse. A clarification on those points would be somewhat worthwile, especially given that since it appears that that material is now completely useless, it could probably be reused for Crossfire itself. Yours, Y.E.J Chachkoff. From mwedel at sonic.net Tue Apr 4 00:26:14 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 03 Apr 2006 22:26:14 -0700 Subject: [crossfire] Player-owner shop proof of concept In-Reply-To: <442EE7D1.8070905@laposte.net> References: <441C37AB.3070903@laposte.net> <442EE7D1.8070905@laposte.net> Message-ID: <44320376.9010603@sonic.net> Nicolas Weeger wrote: > Also, the price estimation seems quite weird - you set the price to eg > 2000 silver, and player will pay ~500 platinum :) > I suspect it's due to the query_cost and such functions using charisma / > shop specialization / ... yes. Presumably, shop specialization could be turned off, or made equal for everything, fixing that problem. IIRC, the value of the object is largely its sell value (with various adjustments), buy price is higher. I'm also not sure how you deal with multiple items (too lazy right now to look at the patch). If I have 20 arrows and set the price to 5000 sp, is that 5000 sp for all 20 (250 sp each), or 5000 sp each? You could get odd effects with that also. I'm also not sure if it being on the shop floor may set the identified flag - if for example you set the price to 2000 sp, but that is before it is identified, then once identified, the price could go up quite a bit. IIRC, unidentified items only get pennies on the dollar (silvers on the platinum?) The real fix for all this would be to add an object flag like 'flag_true_cost', which causes the buy/sell code to use the op->value without modifying for various things, basically like the gem code (but with just a minor increase/decrease for buy/sell, but a fixed amount, so you couldn't sell something for the same price you bought it). Perhaps even use a key/value in the object itself to denote that rate? this I think also fixes other problems, in that price is also tweaked based on other attributes of an item - wands are basically pro-rated based on the number of charged. So if the seller set the price for a wand with 10 charges to 10 platinum, the query_cost would effectively reduce that to 2 platinum since the wand only has 20% of its potential charges, etc. I'd think that for this code, when you set the price, the player doing so is already taking all that into consideration and doesn't want the code further mucking with the values. From tchize at myrealbox.com Mon Apr 10 13:03:47 2006 From: tchize at myrealbox.com (tchize) Date: Mon, 10 Apr 2006 20:03:47 +0200 Subject: [crossfire] xslt parser for unit tests, request for comment Message-ID: <443A9E03.8060106@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, unit test code outputs it's result in .xml files. Those can later be parsed using XSLT to create report webpages. Now am wondering which of those 3 solutions is the best to create the report: 1st option: choose a xslt parser, (like gnome's libxslt) and use it's standalone command line utility to generate reports. pro: easy to integrate, no need for configure thingies against: additionnal dependency for crossfire code 2nd option: integrate a standalone xslt parser (like sablotron) in the crossfire code repository (crossfire/test/xslt ?), compile it and run it at unit testing time pro: no new dependency (assuming the parser has no dependency) against: have ot integrate this xslt parser configure code in crossfire one (should be quite easy), need to find a parser which has very little dependecy to be worth 3rd option: have configure check the presence of various known xslt parsers. As all XSLT1.0 compliant parsers are supposed to produce same output from given input, all configure has to do is to discover the command line to use pro: no fixed dependency (*any* xslt parser, could even provide a - --with-xslt='myparser -input $1 -output $2' configure option), no need for very complicated xslt job against: requires a xslt processor, might hit bugs in some processors note: in all cases, unit test should work even without existing processor installed (user will simply not have the nice html output) Personnaly, i like the 3rd, and of course i like the 1st as it can later be converted to the 3rd. Also, the 2nd one is very complicated and crazy, so i like it too. More seriously, i plan to opt for the option 3 comments? Tchize, servant of the Fido's church -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEOp4DHHGOa1Q2wXwRAp8dAKCHnCujcEm5bqisiEGeMiYa643ovQCcDQcY qpL/gqCC2aW+UTYo7efaJa0= =gC75 -----END PGP SIGNATURE----- From antonoussik at gmail.com Tue Apr 11 15:21:06 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Tue, 11 Apr 2006 21:21:06 +0100 Subject: [crossfire] RFC: dynamic alchemy In-Reply-To: <1143480087.14079.216.camel@localhost.localdomain> References: <1143480087.14079.216.camel@localhost.localdomain> Message-ID: On 27/03/06, Wim Villerius wrote: > Shadow alchemy is an exploit, used to create items that are > impossible to create with dynamic alchemy. (It is impossible to have > items with resist_something > 99 - and this limit could even be set > lower) To those unfamiliar with it, shadow alchemy generally involves finding hash collisions for the recipes, fooling the alchemy code into thinking you are doing something else entirely. Since the hashing function is (on purpose) very weak, there is no easy way of making shadow alchemy impossible short of entirely changing the way traditional alchemy works. It is currently hard enough to discourage most people though (thanks to some safeguards in the code). For most purposes, however, it currently does what dynamic alchemy will do, but without the much needed game balancing, and very scarce documentation. I like your idea about dynamic alchemy, but creating a resistance table seems like a lot of work, and so does messing with the arches. Instead, why not make a semi-random roll on what to add/subtract, partially based on the hash value of the ingredient? This means that only the alchemy.c file will need changing, and dynamic alchemy will have a much better chance of actually happening (+working). These are the things I can think of adding/subtracting to items: resistances stats speed weight value ? <-- careful not to make this one exploitable ac wc luck From fuchs.andy at gmail.com Sat Apr 22 15:23:29 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 22 Apr 2006 16:23:29 -0400 Subject: [crossfire] Fwd: [gentoo-announce] [ GLSA 200604-11 ] Crossfire server: Denial of Service and potential arbitrary code execution In-Reply-To: <444A8E2E.7010909@gentoo.org> References: <444A8E2E.7010909@gentoo.org> Message-ID: Umm, was this the flaw i discovered, or is it a new one? ---------- Forwarded message ---------- From: Thierry Carrez Date: Apr 22, 2006 4:12 PM Subject: [gentoo-announce] [ GLSA 200604-11 ] Crossfire server: Denial of Service and potential arbitrary code execution To: gentoo-announce at lists.gentoo.org Cc: bugtraq at securityfocus.com, full-disclosure at lists.grok.org.uk, security-alerts at linuxsecurity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200604-11 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: High Title: Crossfire server: Denial of Service and potential arbitrary code execution Date: April 22, 2006 Bugs: #126169 ID: 200604-11 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis ======== The Crossfire game server is vulnerable to a Denial of Service and potentially to the execution of arbitrary code. Background ========== Crossfire is a cooperative multiplayer graphical adventure and role-playing game. The Crossfire game server allows various compatible clients to connect to participate in a cooperative game. Affected packages ================= ------------------------------------------------------------------- Package / Vulnerable / Unaffected ------------------------------------------------------------------- 1 games-server/crossfire-server < 1.9.0 >= 1.9.0 Description =========== Luigi Auriemma discovered a vulnerability in the Crossfire game server, in the handling of the "oldsocketmode" option when processing overly large requests. Impact ====== An attacker can set up a malicious Crossfire client that would send a large request in "oldsocketmode", resulting in a Denial of Service on the Crossfire server and potentially in the execution of arbitrary code on the server with the rights of the game server. Workaround ========== There is no known workaround at this time. Resolution ========== All Crossfire server users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=games-server/crossfire-server-1.9.0" References ========== [ 1 ] CVE-2006-1010 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1010 Availability ============ This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200604-11.xml Concerns? ========= Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to security at gentoo.org or alternatively, you may file a bug at http://bugs.gentoo.org. License ======= Copyright 2006 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060422/f614e3f5/attachment.pgp From brenlally at gmail.com Sun Apr 23 19:03:41 2006 From: brenlally at gmail.com (Brendan Lally) Date: Mon, 24 Apr 2006 01:03:41 +0100 Subject: [crossfire] requestable party lists Message-ID: <7903f03c0604231703i79e8c2f7o9233eb606047c6ca@mail.gmail.com> I have uploaded a patch to the sourceforge tracker which forms an initial proposal for requestable party lists. https://sourceforge.net/tracker/index.php?func=detail&aid=1475202&group_id=13833&atid=313833 It is designed to allow clients to provide their own interfaces to party interaction, removing the need to use the (rather complex) party commands. [The following are the proposed modifications to doc/Developers/protocol] That there be a new setup option: partysend (0/1) If 1, the client should be sent the name of their current party in the stats packet. That there be a new requestinfo type party_list (no parameters) This returns the list of parties currently active on the server. This can be used by clients to present a list of parties to choose from. All data is sent in text format. Format is: name:leader:number of players:whether there is a password set eg foo:bar:2:0 is a party called foo, let by bar with 2 players and no password bar:baz:12:1 is a party called bar led by baz with 12 players and a password that is needed to join. [end of proposal.] [The rest of this is an edited and modified form of the description on the patch tracker.] Specifically, it adds a new requestinfo type, party_list which returns a list of all parties currently active on the server, and a new stat byte, 32, which gives the name of the party the player is currently in (there is also a new setup flag to define whether that should be sent - possibly this should be extended to include other things that should be added to the stats command about now). Parties are now joined using party join partyname:password rather than prompting for the password seperatly. However currently I have this new style of party password transmission running in parallel with the old one. Nevertheless, I am inclined to say that the old style could be removed now, since the way I implement this, even non-supporting clients can still authenticate to a party (albeit without the masking of input in the text window) One other upshot of this approach is that ':' needs to be a forbidden character in party names, and they can not be longer than 255 characters (although this is longer than cfclient's current entry buffer). [end of description] Please comment, suggest, flame, etc away. If it is felt that I should send this information in a different way/format, I would prefer to know now, rather than after writing client support. From alex_sch at telus.net Sun Apr 23 23:40:59 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 23 Apr 2006 22:40:59 -0600 Subject: [crossfire] requestable party lists In-Reply-To: <7903f03c0604231703i79e8c2f7o9233eb606047c6ca@mail.gmail.com> References: <7903f03c0604231703i79e8c2f7o9233eb606047c6ca@mail.gmail.com> Message-ID: <444C56DB.1070608@telus.net> Brendan Lally wrote: >I have uploaded a patch to the sourceforge tracker which forms an >initial proposal for requestable party lists. > https://sourceforge.net/tracker/index.php?func=detail&aid=1475202&group_id=13833&atid=313833 > >It is designed to allow clients to provide their own interfaces to >party interaction, removing the need to use the (rather complex) party > commands. > Don't have time to look at the patch right now, but the concept and specification seems good to me. I think that giving the clients the ability to do more things via GUI should be good for getting (and keeping) new players. Alex Schultz From mwedel at sonic.net Mon Apr 24 02:13:07 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 24 Apr 2006 00:13:07 -0700 Subject: [crossfire] requestable party lists In-Reply-To: <7903f03c0604231703i79e8c2f7o9233eb606047c6ca@mail.gmail.com> References: <7903f03c0604231703i79e8c2f7o9233eb606047c6ca@mail.gmail.com> Message-ID: <444C7A83.3070207@sonic.net> Overall, the idea looks fine, but I haven't looked at the actual patch. But a few other thoughts: 1) It could be nice to include the highest number party number in the stats command (only transmit when changed). Since I recall that whenever a new party is created, the client can use this to know when in fact there are new parties. 2) It could likewise be nice for the requestinfo party_list to take a parameter, which denotes to only send party info above that number. In this way, the client could keep track of what is last requested up to, and then can just request the new parties. Normally, this isn't an issue, but I believe there have been cases where people have tried to abuse the server by creating hundreds of parties. If with a relatively modest number of parties, you probably want to be able to only send the new ones. Periodically I suppose the client could go through and request all the parties to figure out which are now defunct. OR perhaps more to have something like a request active party type of thing, which really only needs to send the party numbers of the active parties. From brenlally at gmail.com Mon Apr 24 20:19:07 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue, 25 Apr 2006 02:19:07 +0100 Subject: [crossfire] requestable party lists In-Reply-To: <444C7A83.3070207@sonic.net> References: <7903f03c0604231703i79e8c2f7o9233eb606047c6ca@mail.gmail.com> <444C7A83.3070207@sonic.net> Message-ID: <7903f03c0604241819m71ccee3fl7336b13ea760b910@mail.gmail.com> On 4/24/06, Mark Wedel wrote: > > Overall, the idea looks fine, but I haven't looked at the actual patch. > > But a few other thoughts: > > 1) It could be nice to include the highest number party number in the stats > command (only transmit when changed). Since I recall that whenever a new party > is created, the client can use this to know when in fact there are new parties. party number doesn't exist anymore, it hasn't for a while, there was an issue that it was possible to cause that value to wrap, and in so doing duplicating parties, this was why I wrote a patch last summer to treat parties by the pointer to the party struct rather than the partyid > 2) It could likewise be nice for the requestinfo party_list to take a parameter, > which denotes to only send party info above that number. You could give a name, and say only send parties beyond that one in the linked list, but then what do you do when the party you send the name of doesn't exist? (possibly changing the replyinfo to reflect that fact?) > In this way, the client could keep track of what is last requested up to, and > then can just request the new parties. yes, this might even work if done by name, however it provides no nice way to ensure that the player count even vaguely resembles reality, nor any way to cope with parties that are obsoleted. > Normally, this isn't an issue, but I believe there have been cases where > people have tried to abuse the server by creating hundreds of parties. If with > a relatively modest number of parties, you probably want to be able to only send > the new ones. Yes, I was the one who first mentioned that almost a year ago (the thread 'large numbers of parties causes weirdness' from last April) This is why parties with no members are now periodically removed. If the creation of vast numbers of parties is a great concern, it may well be possible to limit each player to a certain number of parties (3 say) and, each time a party form command is received, count up the number of parties they currently have. > Periodically I suppose the client could go through and request all the parties > to figure out which are now defunct. OR perhaps more to have something like a > request active party type of thing, which really only needs to send the party > numbers of the active parties. I don't see how that can usefully allow player counts to be updated. One more point, which is tangential to all of the others, should parties also allow comments? I am thinking of ~50 characters to describe any given party, to be sent as an extra field in the replyinfo. From tchize at myrealbox.com Thu Apr 27 02:56:41 2006 From: tchize at myrealbox.com (Tchize) Date: Thu, 27 Apr 2006 09:56:41 +0200 Subject: [crossfire] Fwd: [gentoo-announce] [ GLSA 200604-11 ] Crossfire In-Reply-To: References: <444A8E2E.7010909@gentoo.org> Message-ID: <44507939.4010205@myrealbox.com> Hi, just a matter of information, crossfire has lots of places potentially allowing execution of arbitrary code using unchecked length string. Fortunately, those are for most not exploitable as they are not a direct consequence of client data. However, this does not mean they must not be fixed. As a developper of crossfire my position is: crossfire has lots of potential security issues and should always be run in a chrooted environment to limit the risks to crossfire account. Regards, David Delbecq Andrew Fuchs a ?crit : >Umm, was this the flaw i discovered, or is it a new one? > >---------- Forwarded message ---------- >From: Thierry Carrez >Date: Apr 22, 2006 4:12 PM >Subject: [gentoo-announce] [ GLSA 200604-11 ] Crossfire server: Denial >of Service and potential arbitrary code execution >To: gentoo-announce at lists.gentoo.org >Cc: bugtraq at securityfocus.com, full-disclosure at lists.grok.org.uk, >security-alerts at linuxsecurity.com > > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Gentoo Linux Security Advisory GLSA 200604-11 >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > http://security.gentoo.org/ >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Severity: High > Title: Crossfire server: Denial of Service and potential arbitrary > code execution > Date: April 22, 2006 > Bugs: #126169 > ID: 200604-11 > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > >Synopsis >======== > >The Crossfire game server is vulnerable to a Denial of Service and >potentially to the execution of arbitrary code. > >Background >========== > >Crossfire is a cooperative multiplayer graphical adventure and >role-playing game. The Crossfire game server allows various compatible >clients to connect to participate in a cooperative game. > >Affected packages >================= > > ------------------------------------------------------------------- > Package / Vulnerable / Unaffected > ------------------------------------------------------------------- > 1 games-server/crossfire-server < 1.9.0 >= 1.9.0 > >Description >=========== > >Luigi Auriemma discovered a vulnerability in the Crossfire game server, >in the handling of the "oldsocketmode" option when processing overly >large requests. > >Impact >====== > >An attacker can set up a malicious Crossfire client that would send a >large request in "oldsocketmode", resulting in a Denial of Service on >the Crossfire server and potentially in the execution of arbitrary code >on the server with the rights of the game server. > >Workaround >========== > >There is no known workaround at this time. > >Resolution >========== > >All Crossfire server users should upgrade to the latest version: > > # emerge --sync > # emerge --ask --oneshot --verbose >">=games-server/crossfire-server-1.9.0" > >References >========== > > [ 1 ] CVE-2006-1010 > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1010 > >Availability >============ > >This GLSA and any updates to it are available for viewing at >the Gentoo Security Website: > > http://security.gentoo.org/glsa/glsa-200604-11.xml > >Concerns? >========= > >Security is a primary focus of Gentoo Linux and ensuring the >confidentiality and security of our users machines is of utmost >importance to us. Any security concerns should be addressed to >security at gentoo.org or alternatively, you may file a bug at >http://bugs.gentoo.org. > >License >======= > >Copyright 2006 Gentoo Foundation, Inc; referenced text >belongs to its owner(s). > >The contents of this document are licensed under the >Creative Commons - Attribution / Share Alike license. > >http://creativecommons.org/licenses/by-sa/2.0 > > >------------------------------------------------------------------------ > >_______________________________________________ >crossfire mailing list >crossfire at metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > From tchize at myrealbox.com Sun Apr 30 10:33:34 2006 From: tchize at myrealbox.com (tchize) Date: Sun, 30 Apr 2006 17:33:34 +0200 Subject: [crossfire] Sourceforge project admin intervention request Message-ID: <4454D8CE.6010809@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Due to a bug in sourceforge security management, only project admins have access to the page named 'source logos' which contains the codes samples to use on every project webpage hosted on sf. As i will publish under crossfire.sourceforge.net/nightly-test the nightly run of unit tests, i need a project admin to give me this list of logo. Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEVNjOHHGOa1Q2wXwRApu6AKCZrIk7ms5Ox8ynxI9sOaJOx7WGagCfYl0n DZKZaFpwNPYdk6izKBBe6ps= =WC+P -----END PGP SIGNATURE----- From mwedel at sonic.net Sun Apr 30 18:16:00 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 30 Apr 2006 16:16:00 -0700 Subject: [crossfire] Sourceforge project admin intervention request In-Reply-To: <4454D8CE.6010809@myrealbox.com> References: <4454D8CE.6010809@myrealbox.com> Message-ID: <44554530.9020907@sonic.net> tchize wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > Due to a bug in sourceforge security management, only project admins > have access to the page named 'source logos' which contains the codes > samples to use on every project webpage hosted on sf. As i will > publish under crossfire.sourceforge.net/nightly-test the nightly run > of unit tests, i need a project admin to give me this list of logo. I looked on sourceforge, and didn't see anything obvious as it pertains to 'source logos'. Can you point me at a page that mentions this - then perhaps I can figure out what/where that is located. From alex_sch at telus.net Sun Apr 30 22:40:59 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 30 Apr 2006 21:40:59 -0600 Subject: [crossfire] Steam Protocol Proposal Message-ID: <4455834A.4020700@telus.net> Hi, Recently, elmex and I did some tests regarding compression, we found that zlib stream compression is better than selective per-packet compression, and also better than than a "hybrid" that I thought of, which allows packets to selectively be part of a compressed stream. AFAIK, the only drawback to zlib stream compression is CPU usage (which shouldn't be very bad really). It's true that you don't get good compression on png data and such, but it seems that the overhead of any sort of system to selectively decide if it should compress a packet or not, outweighs this in terms of bandwidth. Also, I was thinking that partially for purposes of password exchange, some users may like it if the stream was encrypted. So perhaps supporting ssl streams might be an interesting feature. To accommodate for such things in an expendable manner, I think it would be a good idea to have a protocol to have a generic protocol for encapsulating itself in a stream of some sort. I propose that a protocol such as the following be implemented (with a english translation tabbed to the right of what each side is "saying"): (When the client wants the server to start sending in stream format foo, where foo can be something such as 'zlib', 'ssl' or 'plaintext') C->S: req_recv_stream foo "May you send me data in stream format foo?" S->C: ack_send_stream foo "Sure. Here, sending it in format foo now" S->C: (When the client wants to start sending the server data in stream format bar, where bar can be something such as 'zlib', 'ssl' or 'plaintext') C->S: req_send_stream bar "May I send you data in stream format bar?" S->C: ack_recv_stream bar "Yes, I can receive data in stream format bar." C->S: ack_send_stream bar "Ok, here's data in stream format bar." C->S: Also, requests for a stream format may in a space separated format specify multiple stream types, for the server to encapsulate within eachother (i.e. ssl encrypted zlib stream). A streamed format may be exited by a "req_recv_stream plaintext" or "req_send_stream plaintext". Also, when a format is requested that the server does not support, it tells the client this by sending an "ack_recv_stream " or "ack_send_stream ". Also, there is never any "ack_recv_stream" from the client, because it is assumed that the client requesting to receive in a format implies that it understands it. Even if ssl encryption is not worth implementing, I believe that using this format for encapsulating the protocol in any other generic data stream protocol would be both clean and easily expendable. If anyone has any objections to or suggestions, please speak up :) Alex Schultz