From msucka0xff at programmer.net Sat Mar 6 22:32:10 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:15 2005 Subject: [Netrek Clients] JTrekApplet on pickled.psychosis.net (not on) Message-ID: <20040307043210.D7B6D2AB2E@ws1-6.us4.outblaze.com> Greetings, I attempted to contact psychosis in regards to allowing the JTrekApplet to run on pickled.psychosis.net. There had been some problems earlier with UDP, but I worked feverishly all day to correct them, using my own server as a test bench. Needless to say it was excruciating work to do correctly, esp with clunky technology like Java, but it would benefit the us by introducing netrek to the uninitiated. If you would please (psychosis) allow it to run on pickled I would be most appreciative. For the moment it is redirected to roadkill.com as continuum.us.netrek.org seems to be down. (Hope this email gets through). You can try the applet by clicking here : http://c-24-4-208-59.client.comcast.net/netrek/JTrek.html Thank You, Bob Dang -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From msucka0xff at programmer.net Tue Mar 9 18:19:14 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:15 2005 Subject: [Netrek Clients] JTrekApplet on pickled.psychosis.net (not on) Message-ID: <20040310001914.7F51043E93@ws1-9.us4.outblaze.com> Psychosis, I have more ppl interested in trying the java applet JTrekApplet at server pickled. It seems only one such user is allowed to connect to pickled.psychosis.net at the moment. Can you please re-allow multiple JTrekApplet users to connect from host c-24-4-208-59.client.comcast.net using the JTrek RSA key ? Was it causing any specific problems with the server? Thank you, Bob Dang -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From msucka0xff at programmer.net Wed Mar 10 11:55:58 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:16 2005 Subject: [Vanilla Devel] Re: [Netrek Clients] JTrekApplet onpickled.psychosis.net (not on) Message-ID: <20040310175558.C81CDDF9EF@ws1-5.us4.outblaze.com> apparently psychosis had not prevented the client as i discovered after talking with him yesterday. i am still tracking down the issues with the client as it is still very buggy. shawn mckisson, java pro, is coming on board the project to help me debug it. i am not intending to cause the server admins any grief. my appologies if that has occurred. thank you bd ----- Original Message ----- From: ". ." Date: Tue, 09 Mar 2004 16:19:14 -0800 To: ". ." , vanilla-clients@us.netrek.org Subject: [Vanilla Devel] Re: [Netrek Clients] JTrekApplet onpickled.psychosis.net (not on) > Psychosis, > I have more ppl interested in trying the java applet JTrekApplet at server pickled. It seems only one such user is allowed to connect to pickled.psychosis.net at the moment. Can you please re-allow multiple JTrekApplet users to connect from host c-24-4-208-59.client.comcast.net using the JTrek RSA key ? Was it causing any specific problems with the server? > Thank you, > Bob Dang -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From msucka0xff at programmer.net Mon Mar 22 20:54:30 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:16 2005 Subject: [Netrek Clients] Obstrek source online in cvs repo Message-ID: <20040323025430.39CA92ABCC@ws1-6.us4.outblaze.com> Folks, The Obstrek client source code is now available in an online CVS repo. To obtain an up-to-the-minute snapshot of the code, point your CVS client at the repository and do a checkout. % cvs -d :pserver:obstrek@c-24-4-208-59.client.comcast.net:/var/lib/cvs \ login Password: obstrek0 % cvs -d :pserver:obstrek@c-24-4-208-59.client.comcast.net:/var/lib/cvs \ checkout jtrek % cvs -d :pserver:obstrek@c-24-4-208-59.client.comcast.net:/var/lib/cvs \ checkout netscape Notes: * project files are called 'jtrek' * javac compiler requires netscape class files, which are included in the repo unless you already have them. -Bob Dang -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From msucka0xff at programmer.net Wed Mar 24 09:29:59 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:16 2005 Subject: [Netrek Clients] Add Java Key (Again) Message-ID: <20040324152959.6EDCC22E1C@ws1-8.us4.outblaze.com> Carlos, I believe it is time again to ask to get the Java key back into the main key chain. The reason being that there are many benefits to using the Java programming language include the 3d graphics, and general client enhancement possibilities. The availability of a large development community, and a broad range of code libraries adds value to its proposition. As a distributed client that can demo netrek to new users from a webbrowser, it is unparalleled. There are certain features such as XML that provide proxy-server and firewall traversal without requiring adminstrative level adjustments. A further survey of the Java-Byte codes, the security model, and other mechanisms like Java to Native Interface can be explored to improve the prevention of client compromise. Also with a beta test group we can iron out the bugs. The primary concern of key compromise has been sufficiently addressed in the sense that the key is not exposed to reverse decompiling. The Java Keys are not exposed i n the Obstrek observer client because they are not in the applet that runs on the users desktop, and the code is obfuscated making it especially difficult to create any borgs from this. Also since it runs in through a redirector, it is unlikely that anyone would want to create a borg. I think we can provide better solutions over time to this concern, but it really needs to move from a dead project to something that developers can continue to evolve. Also the issue of anonymous spamming can easily be fixed, and would improve as well. Here (again) is the java key. Please add it. I think most developers and people that play netrek would agree that there is real value of a Java based observer client and the security measures are sufficient and will continue to improve. I think for an early stage client, the acid test should be not immediately applied, since other early clients were given time to evolve, the same leeway can be taken for all due fairness. -Bob Dang Obstreks-RSA-Key-Java1.4:ct=Obstrek:cr=msucka0xff@programmer.net:\ :cd=March 2004:ar=Java1.4:cl=inl,standard2:\ :cm=Java 1.4:\ :gk=b1183209e283c57baac600b893e4457780d5dbe897e72271f8f4e275bc8bf725:\ :pk=197118a5329b1f04917ce899df47dfba20017d2fa965e5f6e474d04cc5c14a25: -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From msucka0xff at programmer.net Wed Mar 24 20:40:27 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:16 2005 Subject: [Netrek Clients] Add Java Key (Again) Message-ID: <20040325024027.55CD522E89@ws1-8.us4.outblaze.com> OK I'm going to come up with a different angle of encryption for the Java clients. I think I may an idea which seems good, and will post for review. Since this is a rather difficult topic, I'm not immediately able to solve it. -Bob Dang ----- Original Message ----- From: ". ." Date: Wed, 24 Mar 2004 07:29:59 -0800 To: vanilla-devel@us.netrek.org, vanilla-clients@us.netrek.org,vanilla-metaserver@us.netrek.org Subject: [Netrek Clients] Add Java Key (Again) > Carlos, > I believe it is time again to ask to get the Java key back into the main key chain. The reason being that there are many benefits to using the Java programming language include the 3d graphics, and general client enhancement possibilities. The availability of a large development community, and a broad range of code libraries adds value to its proposition. As a distributed client that can demo netrek to new users from a webbrowser, it is unparalleled. There are certain features such as XML that provide proxy-server and firewall traversal without requiring adminstrative level adjustments. A further survey of the Java-Byte codes, the security model, and other mechanisms like Java to Native Interface can be explored to improve the prevention of client compromise. Also with a beta test group we can iron out the bugs. The primary concern of key compromise has been sufficiently addressed in the sense that the key is not exposed to reverse decompiling. The Java Keys are not exposed i > n the Obstrek observer client because they are not in the applet that runs on the users desktop, and the code is obfuscated making it especially difficult to create any borgs from this. Also since it runs in through a redirector, it is unlikely that anyone would want to create a borg. I think we can provide better solutions over time to this concern, but it really needs to move from a dead project to something that developers can continue to evolve. Also the issue of anonymous spamming can easily be fixed, and would improve as well. Here (again) is the java key. Please add it. I think most developers and people that play netrek would agree that there is real value of a Java based observer client and the security measures are sufficient and will continue to improve. I think for an early stage client, the acid test should be not immediately applied, since other early clients were given time to evolve, the same leeway can be taken for all due fairness. > -Bob Dang > > Obstreks-RSA-Key-Java1.4:ct=Obstrek:cr=msucka0xff@programmer.net:\ > :cd=March 2004:ar=Java1.4:cl=inl,standard2:\ > :cm=Java 1.4:\ > :gk=b1183209e283c57baac600b893e4457780d5dbe897e72271f8f4e275bc8bf725:\ > :pk=197118a5329b1f04917ce899df47dfba20017d2fa965e5f6e474d04cc5c14a25: > > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > _______________________________________________ > vanilla-clients mailing list > vanilla-clients@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-clients -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From xyzzy at speakeasy.org Fri Mar 5 18:06:43 2004 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] Re: [Vanilla List] NO_DUPLICATE_HOSTS on Continuum In-Reply-To: <20040217013034.GC28599@us.netrek.org> Message-ID: On Tue, 17 Feb 2004, James Cameron wrote: > The way it works is to hold the client back from joining the queue or > the game until a previous client from the same IP address exits. The > client displays a wait queue of 32. Besides keeping people from joining multiple times, this does two other things. You can't switch teams by waiting in the queue for a open slot to come up on the other team. If you ghostbust, you can't come back in until your slot is finally freed. > passed by others not in the game. In the "wait queue 32" state, you are > not strictly in a queue at all. The server end of the connection will > be polling the player list, waiting for you to free the slot. Once that > happens, it will be as if you started the client then. How does the player list polling work? I get worried whenever I hear someone say polling. _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Sat Mar 6 22:32:10 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] JTrekApplet on pickled.psychosis.net (not on) Message-ID: <20040307043210.D7B6D2AB2E@ws1-6.us4.outblaze.com> Greetings, I attempted to contact psychosis in regards to allowing the JTrekApplet to run on pickled.psychosis.net. There had been some problems earlier with UDP, but I worked feverishly all day to correct them, using my own server as a test bench. Needless to say it was excruciating work to do correctly, esp with clunky technology like Java, but it would benefit the us by introducing netrek to the uninitiated. If you would please (psychosis) allow it to run on pickled I would be most appreciative. For the moment it is redirected to roadkill.com as continuum.us.netrek.org seems to be down. (Hope this email gets through). You can try the applet by clicking here : http://c-24-4-208-59.client.comcast.net/netrek/JTrek.html Thank You, Bob Dang -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From frontloader at mindspring.com Sat Mar 6 22:29:56 2004 From: frontloader at mindspring.com (frontloader [mschupp]) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] JTrekApplet on pickled.psychosis.net (not on) In-Reply-To: <20040307043210.D7B6D2AB2E@ws1-6.us4.outblaze.com> References: <20040307043210.D7B6D2AB2E@ws1-6.us4.outblaze.com> Message-ID: <404AA544.9050609@mindspring.com> Bob wrote: > Greetings, I attempted to contact psychosis in regards to allowing > the JTrekApplet to run on pickled.psychosis.net. There had been some > problems earlier with UDP, but I worked feverishly all day to correct > them, using my own server as a test bench. Needless to say it was > excruciating work to do correctly, esp with clunky technology like > Java, but it would benefit the us by introducing netrek to the > uninitiated. If you would please (psychosis) allow it to run on > pickled I would be most appreciative. > > For the moment it is redirected to roadkill.com as > continuum.us.netrek.org seems to be down. (Hope this email gets > through). > > You can try the applet by clicking here : > http://c-24-4-208-59.client.comcast.net/netrek/JTrek.html > nice work! was just on the server.. wasnt getting very good through-put, but it seemed like the client was behaving like i'd expect. i couldnt seem to get the ship to move however.. [prolly my fault somehow] -m _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Sat Mar 6 23:42:46 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] JTrekApplet on pickled.psychosis.net (not on) Message-ID: <20040307054246.17B302AB2F@ws1-6.us4.outblaze.com> frontload, thanks, it connects in observer mode only because java is not so good hehe. I plan to add a glTrek face lift if that is OK. -bd -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Sun Mar 7 14:10:35 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] JTrekApplet on pickled.psychosis.net (not on) Message-ID: <20040307201036.145E943E6C@ws1-9.us4.outblaze.com> Erik Check the java console for debugging errors. Also you must have Javascript enabled. you must be running Sun's Java plugin 1.4.2 or later. It should work. I tested it from a cafe using a wireless connection. UDP is off by default. You can turn it on if you like, but it is slow. I need to optimize it. Please send me the java console back trace. Thanks, -Bob ----- Original Message ----- From: "E. Hietbrink" Date: Sun, 07 Mar 2004 11:06:11 +0100 To: msucka0xff@programmer.net Subject: Re: [Vanilla Devel] JTrekApplet on pickled.psychosis.net (not on) > Hi Bob, > > as soon as you're ready to have it listed on www.netrek.org, let me know. > I myself tried it out too, but nothing happens after I push the button... > > Greetx, Erik > > > > Greetings, > > I attempted to contact psychosis in regards to allowing the JTrekApplet to run on pickled.psychosis.net. There had been some problems earlier with UDP, but I worked feverishly all day to correct them, using my own server as a test bench. Needless to say it was excruciating work to do correctly, esp with clunky technology like Java, but it would benefit the us by introducing netrek to the uninitiated. If you would please (psychosis) allow it to run on pickled I would be most appreciative. > > > > For the moment it is redirected to roadkill.com as continuum.us.netrek.org seems to be down. (Hope this email gets through). > > > > You can try the applet by clicking here : http://c-24-4-208-59.client.comcast.net/netrek/JTrek.html > > > > Thank You, > > Bob Dang > -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Sun Mar 7 16:28:21 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] Re: [Vanilla List] NO_DUPLICATE_HOSTS on Continuum In-Reply-To: References: <20040217013034.GC28599@us.netrek.org> Message-ID: <20040307222821.GA3307@us.netrek.org> On Fri, Mar 05, 2004 at 04:06:43PM -0800, Trent Piepho wrote: > You can't switch teams by waiting in the queue for a open slot to come up on > the other team. Yes. To compensate, I was thinking of adding a queue for each team. > If you ghostbust, you can't come back in until your slot is finally freed. Yes. I thought of the new connection destroying the old, but that would give everyone a fast way back to their home planet. How long is this delay, and what causes the ghostbust? I had earlier reduced the amount of time that the server will reattempt connection over TCP back to the client on the fallback port. Without being able to do that, there's little point the server keeping the slot in use. > How does the player list polling work? I get worried whenever I hear > someone say polling. Each second, iterates through the player list, doing a strcmp() against each active slot's p_full_hostname. This continues while the Q32 state persists. By comparison, the normal queue polling which happens while you are waiting for a slot in a full game, checks each second to see if is at head of queue, and if so calls pickslot(). The latter is certainly cheaper than the former, but on the old hardware we use for continuum the former is still quite cheap. The netrekd process will not fork more than MAXPROCESSES (88) processes. The wait queue is limited to MAXWAITING (32) as usual. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Tue Mar 9 18:19:14 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] Re: [Netrek Clients] JTrekApplet on pickled.psychosis.net (not on) Message-ID: <20040310001914.7F51043E93@ws1-9.us4.outblaze.com> Psychosis, I have more ppl interested in trying the java applet JTrekApplet at server pickled. It seems only one such user is allowed to connect to pickled.psychosis.net at the moment. Can you please re-allow multiple JTrekApplet users to connect from host c-24-4-208-59.client.comcast.net using the JTrek RSA key ? Was it causing any specific problems with the server? Thank you, Bob Dang -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Wed Mar 10 11:55:58 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] Re: [Netrek Clients] JTrekApplet onpickled.psychosis.net (not on) Message-ID: <20040310175558.C81CDDF9EF@ws1-5.us4.outblaze.com> apparently psychosis had not prevented the client as i discovered after talking with him yesterday. i am still tracking down the issues with the client as it is still very buggy. shawn mckisson, java pro, is coming on board the project to help me debug it. i am not intending to cause the server admins any grief. my appologies if that has occurred. thank you bd ----- Original Message ----- From: ". ." Date: Tue, 09 Mar 2004 16:19:14 -0800 To: ". ." , vanilla-clients@us.netrek.org Subject: [Vanilla Devel] Re: [Netrek Clients] JTrekApplet onpickled.psychosis.net (not on) > Psychosis, > I have more ppl interested in trying the java applet JTrekApplet at server pickled. It seems only one such user is allowed to connect to pickled.psychosis.net at the moment. Can you please re-allow multiple JTrekApplet users to connect from host c-24-4-208-59.client.comcast.net using the JTrek RSA key ? Was it causing any specific problems with the server? > Thank you, > Bob Dang -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Mon Mar 15 23:30:12 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] CVS update: metaserver Message-ID: <200403160530.i2G5UC707081@swashbuckler.real-time.com> Date: Monday March 15, 2004 @ 23:30 Author: unbelver Update of /home/netrek/cvsroot/metaserver In directory swashbuckler.real-time.com:/var/tmp/cvs-serv7076 Modified Files: rsa_keys Log Message: Removing the Java keys due to insecurities --Carlos V. **************************************** Index: metaserver/rsa_keys diff -u metaserver/rsa_keys:2.36 metaserver/rsa_keys:2.37 --- metaserver/rsa_keys:2.36 Mon Jan 12 16:27:39 2004 +++ metaserver/rsa_keys Mon Mar 15 23:30:11 2004 @@ -1180,14 +1180,6 @@ :gk=f7a1740736267ac14a133563dfe080175daa9aad74b975047bec25694fd46b20:\ :pk=c3915350005759ed5f831e63a5358547de04282c187d8874b0457ea979b88b0d: # -#JAVATrek keys -# -key.JTrek:ct=JTrek 0.94beta:cr=robertt@starwave.com:\ - :cd=November 1998:ar=Java 1.1:cl=standard2:\ - :cm=http://www.starwave.com/people/robertt/JTrek:\ - :gk=899c6d33741e2cdcfc49c9da47afac007122a6575c7ce9191282ed8895efc30a:\ - :pk=c5333ca798c9a6944d3343e60ecd5bc904cc5b33bf67842332247b116932eb07: -# # # NetrekXP-RSA-Key-Win32:ct=NetrekXP:cr=ssheldon@sodablue.org:\ @@ -1205,9 +1197,4 @@ # # Temp development keys # -Obstreks-RSA-Key-Java1.4.2_02:ct=obstrek:cr=msucka0xff@programmer.net:\ - :cd=December 2003:ar=Java1.4.2_02:cl=standard2:\ - :cm=Java obs development key:\ - :gk=abb27563e0cc985f45ac92c8a75878e94c4203bd8372b9a9ce77d7dffafd1b02:\ - :pk=17cc95a2f29c0c4b84cc2507b99163f78316531702923807565c32c0a37af600: # --- end of list --- _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From slagerni at msu.edu Tue Mar 16 00:04:40 2004 From: slagerni at msu.edu (Nicholas James Slager) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] Re: CVS update: metaserver In-Reply-To: <200403160530.i2G5UC707081@swashbuckler.real-time.com> References: <200403160530.i2G5UC707081@swashbuckler.real-time.com> Message-ID: What insecurites exactly? Cause if you remove the java client keys, the chances of me ever touching anything related to netrek again drop to zero. Nick Vanilla CVS Development writes: > Date: Monday March 15, 2004 @ 23:30 > Author: unbelver > > Update of /home/netrek/cvsroot/metaserver > In directory swashbuckler.real-time.com:/var/tmp/cvs-serv7076 > > Modified Files: > rsa_keys > Log Message: > Removing the Java keys due to insecurities > > --Carlos V. > > > > **************************************** > > Index: metaserver/rsa_keys > diff -u metaserver/rsa_keys:2.36 metaserver/rsa_keys:2.37 > --- metaserver/rsa_keys:2.36 Mon Jan 12 16:27:39 2004 > +++ metaserver/rsa_keys Mon Mar 15 23:30:11 2004 > @@ -1180,14 +1180,6 @@ > :gk=f7a1740736267ac14a133563dfe080175daa9aad74b975047bec25694fd46b20:\ > :pk=c3915350005759ed5f831e63a5358547de04282c187d8874b0457ea979b88b0d: > # > -#JAVATrek keys > -# > -key.JTrek:ct=JTrek 0.94beta:cr=robertt@starwave.com:\ > - :cd=November 1998:ar=Java 1.1:cl=standard2:\ > - :cm=http://www.starwave.com/people/robertt/JTrek:\ > - :gk=899c6d33741e2cdcfc49c9da47afac007122a6575c7ce9191282ed8895efc30a:\ > - :pk=c5333ca798c9a6944d3343e60ecd5bc904cc5b33bf67842332247b116932eb07: > -# > # > # > NetrekXP-RSA-Key-Win32:ct=NetrekXP:cr=ssheldon@sodablue.org:\ > @@ -1205,9 +1197,4 @@ > # > # Temp development keys > # > -Obstreks-RSA-Key-Java1.4.2_02:ct=obstrek:cr=msucka0xff@programmer.net:\ > - :cd=December 2003:ar=Java1.4.2_02:cl=standard2:\ > - :cm=Java obs development key:\ > - :gk=abb27563e0cc985f45ac92c8a75878e94c4203bd8372b9a9ce77d7dffafd1b02:\ > - :pk=17cc95a2f29c0c4b84cc2507b99163f78316531702923807565c32c0a37af600: > # --- end of list --- > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From unbelver at us.netrek.org Tue Mar 16 12:20:00 2004 From: unbelver at us.netrek.org (Carlos Y. Villalpando) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] Re: CVS update: metaserver In-Reply-To: References: <200403160530.i2G5UC707081@swashbuckler.real-time.com> Message-ID: <20040316182000.GA29750@brain.jpl.nasa.gov> Quoting Nicholas James Slager : > > What insecurites exactly? A demonstrated key extraction. --Carlos V. _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From larry.coates at rtg-usa.com Wed Mar 17 14:10:52 2004 From: larry.coates at rtg-usa.com (Larry Coates) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] Resources for work in the US! Message-ID: <008501c40c5b$f2a2f6a0$6401a8c0@CPQ49314066312> Skipped content of type multipart/alternative-------------- next part -------------- _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Wed Mar 17 15:00:06 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] Re: Nick Slager Message-ID: <20040317210006.B566A2334A@ws1-2.us4.outblaze.com> Nick Slager please contact me. I attempted to send you email, but I believe it was blocked or flagged as SPAM. Thanks, bd -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Thu Mar 18 13:20:33 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] Re: CVS update: metaserver Message-ID: <20040318192033.7ED1D2334E@ws1-10.us4.outblaze.com> Carlos, I have new RSA keys that need to be added to the metaserver key list. I will send you the new RSA key, please add it ASAP. I would like to have it online for Thursday's draft clue game. Please look for my email in case it gets flagged as SPAM. I redesigned the applet so that the RSA keys are internal to the remote Java VM that runs on my linux server. The JTrekApplet uses RMI, so it has only stubs of the methods that are called. I moved the keys into the remote server, and the implementation class it runs is not in the applet jar file that is downloaded to the user. The code is not as clean as it used to be because I nearly cut and paste all of jtrek.rsa.RSA java file into the RMI remote server implementation file and then exposed a single prototype call "generateRSAResponse". You may check it out now to convince yourself. It has been uploaded already. Thanks, -bd -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Thu Mar 18 13:38:01 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] Re: CVS update: metaserver In-Reply-To: <20040318192033.7ED1D2334E@ws1-10.us4.outblaze.com> Message-ID: <20040318193801.45424.qmail@web21108.mail.yahoo.com> hey jay, how about having the remote Java VM run on a host in the netrek.org domain that way the key gods can feel more at ease knowing their security measures will protect the keys and not those of your home server? zach --- ". ." wrote: > Carlos, > > I have new RSA keys that need to be added to the > metaserver key list. > I will send you the new RSA key, please add it ASAP. I > would like to > have it online for Thursday's draft clue game. Please > look for my email > in case it gets flagged as SPAM. > > I redesigned the applet so that the RSA keys are > internal to the remote Java VM that runs on my linux > server. The > JTrekApplet uses RMI, so it has only stubs of the methods > that are > called. I moved the keys into the remote server, and the > implementation class it runs is not in the applet jar > file that is > downloaded to the user. The code is not as clean as it > used to be > because I nearly cut and paste all of jtrek.rsa.RSA java > file into > the RMI remote server implementation file and then > exposed a single > prototype call "generateRSAResponse". > > You may check it out now to convince yourself. It has > been uploaded already. > > Thanks, > -bd > > > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From unbelver at us.netrek.org Thu Mar 18 15:16:19 2004 From: unbelver at us.netrek.org (Carlos Y. Villalpando) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] Re: CVS update: metaserver In-Reply-To: <20040318192033.7ED1D2334E@ws1-10.us4.outblaze.com> References: <20040318192033.7ED1D2334E@ws1-10.us4.outblaze.com> Message-ID: <20040318211619.GA5168@brain.jpl.nasa.gov> Quoting . . : > I have new RSA keys that need to be added to the metaserver key > list. I won't add them. And by the way, the Java mkkey seems to be making keys formatted incorrectly. I've had to edit all of them by hand. > I redesigned the applet so that the RSA keys are > internal to the remote Java VM that runs on my linux server. Now your redirector is blessed, but not the clients that the user runs. The user can write an info borg to his heart's content and let you authenticate him by calling your RSA function. True, its not likely to happen by tonight, but its the principle of the thing. And before you say "But I can authenticate my clients!" You will have the same problem RSA authentication has. The point of internal keys is to bless the binary and to make some effort to be sure the binary is the same as what we distributed. Moving the key out of the .jar doesn't do that. There seems to be no practical way to bless Java apps at the moment, so no Java keys will be added for now. That's not to say you can't convice the server god to add it manually. Your key should look like this, btw: Obstreks-RSA-Key-Java1.4.2_02:ct=Obstrek:cr=msucka0xff@programmer.net:\ :cd=March 2004:ar=Java1.4.2_02:cl=inl,standard2:\ :cm=Some random comment here:\ :gk=b1183209e283c57baac600b893e4457780d5dbe897e72271f8f4e275bc8bf725:\ :pk=197118a5329b1f04917ce899df47dfba20017d2fa965e5f6e474d04cc5c14a25: The key you sent me won't be able to connect anywhwere. --Carlos V. _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Thu Mar 18 16:17:10 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] Re: CVS update: metaserver In-Reply-To: <20040318211619.GA5168@brain.jpl.nasa.gov> Message-ID: <20040318221710.67547.qmail@web21113.mail.yahoo.com> --- "Carlos Y. Villalpando" wrote: > Now your redirector is blessed, but not the clients that > the user > runs. The user can write an info borg to his heart's > content and let > you authenticate him by calling your RSA function. True, > its not > likely to happen by tonight, but its the principle of the > thing. Jay, Have you investigated signing/verifying JAR files and sealed JAR files? you can digitally sign a certificate and authenticate using RSA. Also you may want check out JAAS: http://java.sun.com/security/jaas/doc/api.html Zach __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Thu Mar 18 17:29:05 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:56 2005 Subject: [Vanilla Devel] Re: CVS update: metaserver In-Reply-To: <20040318211619.GA5168@brain.jpl.nasa.gov> References: <20040318192033.7ED1D2334E@ws1-10.us4.outblaze.com> <20040318211619.GA5168@brain.jpl.nasa.gov> Message-ID: <20040318232905.GA2064@us.netrek.org> Carlos, Will you accept a key if the ability to send messages from the application is turned off? (I'm thinking of making a server side change to force the slot to be dumb if it's this key, if you are unwilling to place the key. I still see anonymous abuse as a design problem.) Or, could you make a new category for the key and allow the server admins to choose from the updated command line? If we suppose there will be cheating (people observing through this channel while playing on the other side), then I guess a one minute delay on the data stream might come in handy. I've been thinking of doing that for standard observers anyway. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From unbelver at us.netrek.org Thu Mar 18 21:57:02 2004 From: unbelver at us.netrek.org (Carlos Y. Villalpando) Date: Wed Jan 12 00:50:57 2005 Subject: [Vanilla Devel] Re: Add java key (3rd attempt) In-Reply-To: <20040319012118.E2BA223359@ws1-10.us4.outblaze.com> References: <20040319012118.E2BA223359@ws1-10.us4.outblaze.com> Message-ID: <20040319035702.GA6145@brain.jpl.nasa.gov> I've been not very well net-connected at work today, hence the long delays. Quoting . . : > This is the 2nd attempt at sending the same message. Basically the > jar's will be digitally signed. That means that nobody can call the > 'generateRSAResponse' without a jar that I distributed/created. The > technology used to sign the jar file is stronger than that which is > used to authenticate and bless netrek clients. I'm researching signed/sealed .jar files, and I see a lot of references to make sure the browser/user can be sure its untampered so that the browser/JavaRunTime can expand priveledges, but I can't find where the server can verify that. Could you help me out and give me a reference link? Thanks. I'm still looking, though and I admit I'm not very knowledgeable about this. Teach me. Convice me. What I'm worried about is the user unsigning/unsealing all the .jar classes so that no class would want to throw a Security Exception, giving it UniversalConnect privledges, removing the certificate checks in your code, and running that. What do you call on the server that will force a Security Exception to get thrown on the client and you finding out about that and dropping the connection? Thanks! > At this point there are no substantial technical issues surrounding > the secruity and use of the netrek RSA key for other anything other > than it's intended purpose. I'd like to independantely verify that. Anyone else listening in here can give me pointers too. > If you do not, I would be inclined to the conclusion that you are > letting your personal feelings interfere with netrek progress. Here's a hint: Trying to insult people you're trying to convice of your position isn't a good idea. Especially when that someone has a history of publicly trying to remain impartial and reasonable when it comes to "official duties." As opinionated as we "official" people are, I've noticed that we are all reasonable when it becomes an issue of official duties. I revoked the Java keys because it became obvious that more people than just you knew how to extract the Java keys on r.g.n and in my personal e-mail. I even publicly stated that the abuse monkey argument wasn't enough. Yes, I have publicly stated as a player on r.g.n. and in hockey games that I think eject/abuse monkeys are driving away new players, but I've also said you don't need your client to be anon, so that wasn't enough. I'm all for more observers. I'm all for more coders. Now you're introducing a new client verification method, so you have to expect that you need to convice people. Assuming that .jar signing does pan out, a few suggestions: 1) INL team captains are going to want to know who's on their obs slots. At the very least, leave in an IP address, or a FQDN answer to a pig call handled at the redirector, not the client. 2) Now that I think about it...... This really shouldn't be a separate thing. Once this is mature enough I'm wondering what it would take to turn this into a Java version of ntserv. Or at the very least, run the redirector on the same server as the game and put the redirector in the .bypass file. Roll this into Vanilla so it doesn't need a key. --Carlos V. _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From larry.coates at rtg-usa.com Fri Mar 19 07:20:41 2004 From: larry.coates at rtg-usa.com (Larry Coates) Date: Wed Jan 12 00:50:57 2005 Subject: [Vanilla Devel] Re: Resources for work in the US! Message-ID: <031201c40db4$fa76a390$6401a8c0@CPQ49314066312> Skipped content of type multipart/alternative-------------- next part -------------- _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Fri Mar 19 12:25:42 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:50:57 2005 Subject: [Vanilla Devel] Re: CVS update: metaserver In-Reply-To: <20040318232905.GA2064@us.netrek.org> Message-ID: <20040319182542.86335.qmail@web21111.mail.yahoo.com> --- James Cameron wrote: > If we suppose there will be cheating (people observing > through this > channel while playing on the other side), then I guess a > one minute > delay on the data stream might come in handy. I've been > thinking of > doing that for standard observers anyway. Perhaps toggle this off during INL mode and for hockey tournament mode because it's hard enough for dial-up players observing an INL game without an additional 60,000 ms delay ;) Zach __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Fri Mar 19 15:25:14 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:57 2005 Subject: [Vanilla Devel] Re: Add java key (3rd attempt) Message-ID: <20040319212514.5FF6522E16@ws1-10.us4.outblaze.com> I'm putting together a document to answer your concerns. ----- Original Message ----- From: "Carlos Y. Villalpando" Date: Thu, 18 Mar 2004 19:57:02 -0800 To: ". ." , vanilla-devel@us.netrek.org Subject: [Vanilla Devel] Re: Add java key (3rd attempt) > Here's a hint: Trying to insult people you're trying to convice of > your position isn't a good idea. Especially when that someone has a Please accept my appologies. -bd -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From slagerni at msu.edu Fri Mar 19 16:30:25 2004 From: slagerni at msu.edu (Nicholas James Slager) Date: Wed Jan 12 00:50:57 2005 Subject: [Vanilla Devel] Re: Solicit metaserver problems In-Reply-To: <5.2.0.9.0.20040227105552.03bb4eb8@mailgate.team17.com> References: <200402201955.i1KJt2a00637@swashbuckler.real-time.com> <5.2.0.9.0.20040223165720.037ea8b8@mailgate.team17.com> <20040223214223.GB9995@us.netrek.org> <5.2.0.9.0.20040227105552.03bb4eb8@mailgate.team17.com> Message-ID: Sorry it took a while to get back to this. I moved out of state so things have been a mess. But hey, if I'm going to be unemployed I need something to keep me occupied until I am. My gess is that the call to rprog(j->p_login, j->p_full_hostname) is failing. I'll admit that when I wrote this part I horked it from the newbie server and didn't really know what I was doing. I modifed the rprog function to something that worked on my system, and it probably broke on the ones that are having the problem. Could someone verify this for me and possibly even suggest a better way of doing this? Nick David Watson writes: > > I believe that PreT is always 4v4 so there is a limit (not sure why it is > needed) On a working preT server you do see the teams greyed out before a > bot quits leaving a slot open for you to join. once you reach the minimum > for T then preT ends and you can progress up to a full game... > > Certainly the bots are not quitting out at any time, either when a human > wants in or after preT times out with no players. To my uneducated eye it > looks like the bots slot is freed in order to get it out? Its the pret bot > that manages this (robots/pret.c) and the function given below > > static void stop_a_robot(void) > { > int i; > struct player *j; > int teamToStop; > > if(debugTarget != -1 && debugLevel == 3) { > messOne(255, roboname, debugTarget, "#1(%d): %d #2(%d): %d", > team1, num_humans(team1), team2, num_humans(team2)); > } > if(num_humans(team1) < num_humans(team2)) > teamToStop = team1; > else > teamToStop = team2; > > if(debugTarget != -1 && debugLevel == 3) { > messOne(255, roboname, debugTarget, "Stopping from %d", teamToStop); > } > /* Nuke robot from the team with the fewest humans. */ > for (i = 0, j = players; i < MAXPLAYER; i++, j++) { > if (j->p_status == PFREE) > continue; > if (j->p_flags & PFROBOT) > continue; > > /* If he's at the MOTD we'll get him next time. */ > if (j->p_team == teamToStop && j->p_status == PALIVE && > rprog(j->p_login, j->p_full_hostname)) { > stop_this_bot(j); > return; > } > } > } > > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Sat Mar 20 02:19:04 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:57 2005 Subject: [Vanilla Devel] Re: CVS update: metaserver In-Reply-To: <20040319182542.86335.qmail@web21111.mail.yahoo.com> References: <20040318232905.GA2064@us.netrek.org> <20040319182542.86335.qmail@web21111.mail.yahoo.com> Message-ID: <20040320081904.GA16513@us.netrek.org> On Fri, Mar 19, 2004 at 10:25:42AM -0800, Zach wrote: > Perhaps toggle this off during INL mode and for hockey > tournament mode because it's hard enough for dial-up > players observing an INL game without an additional 60,000 > ms delay ;) Apart from the difficulty of synchronising the replacement of a player by someone in reserve, I don't see how a minute's delay in the data stream will hurt observers of an INL game. They'd still get to see everything at the same rate. ;-} -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Sat Mar 20 10:10:48 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:57 2005 Subject: [Vanilla Devel] Re: CVS update: metaserver Message-ID: <20040320161048.B4ECE22E1C@ws1-10.us4.outblaze.com> Please dont do this; your last mod with w q 32 was a real barn broadsider :-) Ideally you want observers to be a position to coach, so they need to be in the same time frame. On pickup servers the rules are different, but you want to still to be able to do the same kind of good coaching. Sending messages after a minute's delay wont have the same meaning. Also what do you propose to display for the delayed minute it takes to shift the observers to the appropriate sync slot? For a real time game, this is a faux pas. Have you seen the chess server source code lately? :-) -BobDang ----- Original Message ----- From: James Cameron Date: Sat, 20 Mar 2004 19:19:04 +1100 To: Vanilla Netrek Development Mailing List Subject: Re: [Vanilla Devel] Re: CVS update: metaserver > On Fri, Mar 19, 2004 at 10:25:42AM -0800, Zach wrote: > > Perhaps toggle this off during INL mode and for hockey > > tournament mode because it's hard enough for dial-up > > players observing an INL game without an additional 60,000 > > ms delay ;) > > Apart from the difficulty of synchronising the replacement of a player > by someone in reserve, I don't see how a minute's delay in the data > stream will hurt observers of an INL game. They'd still get to see > everything at the same rate. ;-} -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From keyos at keyos.org Sat Mar 20 11:19:45 2004 From: keyos at keyos.org (Stas Pirogov) Date: Wed Jan 12 00:50:57 2005 Subject: [Vanilla Devel] Re: CVS update: metaserver In-Reply-To: <20040320081904.GA16513@us.netrek.org> References: <20040318232905.GA2064@us.netrek.org> <20040319182542.86335.qmail@web21111.mail.yahoo.com> <20040320081904.GA16513@us.netrek.org> Message-ID: Hmm, I think this will break all the fun in observing the game. The delay (whatever long) will turn real game into recording. Instead of cheering and probably making suggestions at the stadium observers will become bored guys sitting at their houses and watching game. You shouldn't forget that people come there not only to watch, but to talk to others. Also I don't really understand all keys revoking thing lately. The fact that keys can be extracted from both Java and C is known for years. The easiness I think doesn't matter here. If person is serious enough to extract keys he will probably do that to C clients (forgive me Java guys), because in my experience C clients are much faster. Please, think about game before introducing delays and revoking keys. It is always possible to revoke single key when you are sure that client is used to provide borg features (which is not right for any client for now) instead of making general decision to revoke everything. About the delays - well, I don't think who threw that idea in the first place, but I think discussing such things with comminity is the first thing that should be done. There are enough decent people there to give you truthful observations on the matter. Stas. On Sat, 20 Mar 2004, James Cameron wrote: > Date: Sat, 20 Mar 2004 19:19:04 +1100 > From: James Cameron > Reply-To: Vanilla Netrek Development Mailing List > > To: Vanilla Netrek Development Mailing List > Subject: Re: [Vanilla Devel] Re: CVS update: metaserver > > On Fri, Mar 19, 2004 at 10:25:42AM -0800, Zach wrote: > > Perhaps toggle this off during INL mode and for hockey > > tournament mode because it's hard enough for dial-up > > players observing an INL game without an additional 60,000 > > ms delay ;) > > Apart from the difficulty of synchronising the replacement of a player > by someone in reserve, I don't see how a minute's delay in the data > stream will hurt observers of an INL game. They'd still get to see > everything at the same rate. ;-} > > -- > James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Sat Mar 20 11:54:19 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:57 2005 Subject: [Vanilla Devel] Re: Add java key (3rd attempt) Message-ID: <20040320175419.8EE5E22E18@ws1-10.us4.outblaze.com> Folks, Well I think the only thing Carlos will accept is the appology I offered last time, but not the java keys I have been struggling to get him to accept. The problem of blessed clients is more complex than I can solve with a one liner like "jar file is signed". It is almost (if not entirely) equivalent to the netrek server to netrek blessed client issue. I just shifted the issue, but solved nothing. The reason for this is that even if the jar file is signed, I need to have something in the applet telling my server that the applet originated from my server, and is running in the client's java plugin. This breaks down if you were to imagine that somebodies could devise a surrogate process posing to be the digitally signed applet. Also the authority of that statement is based on the believablity that the java plug-in running on a remote host is saying so, and not an imposter java-plugin/process. This thing has so many complications including java VM compatibility within different webbrowsers (e.g. netscape, MSIE, mozilla), implemented feature sets (some VM's do support specific features others do not), that it's intended audience becomes further diminished. As it is, almost nobody uses it anyway. I would be worse off with this utility implemented in this fashion, than the applet being what it is without. When I began to look at it closely, I had the gut feeling that I was t rying to get java to do something it was not able to do. It was the same feeling I had when I tried to get RMI to operate in an applet over HTTP tunneling and over remote proxy servers. It is another example of how java appear to provide one functionality, but after some reality checks and internal R&D it turns out not to live up to its glowing promises. If I am to continue using java, I must come up with a way to obfuscate the key in the java byte codes. But again this is just a guess and still Carlos must approve. Also to deliver the applet to more users, I need to either get rid of RMI (I thought XML was an alternative), or get the users to grant the applet more privileges (which again limits the audience). If you look at how the java applet runs now, you would say it does, only bearly run. It is no where near as robust or solid as the native C compiled version. I am not certain that this will change since I have decided to scale back my effort on this project, if not abandon it entirely. In the mean time, if the server admins can add my java key to their key chains so that the observer client can still login to pickup servers that would be terrific. Note that I think it would be almost as difficult for someone to call my generateRSAResponse in the correct sequence with their own info borg as it would be to reverse engineer the netrek clients, and steal the keys. Also note that the actual code that runs 'generateRSAResponse' is a method that belongs to a remotely activated object that is created in response to a factory call -- it is all very hairy business understand the program flow in the first place. Note that my current version of the applet is obfuscated, and has no RSA keys. So evil hackors must overcome all of these issues for the relatively weak reward of accessing an info borg (not in the wildest fantasy as useful as the keys to a bank vault). The performance just does not exist for a play borg, because it is tcp only and routed thru my bottleneck pa cket rerouter. Please let me know if you can add my key so I will know which servers to allow the JTrekApplet to run on. One amusing footnote is that now it only runs on my own netrek server (which nobody uses anyway), and Robert Temples original unmodified JTrekApplet could have done that. What a way to waste a year of my time! I hope this never happens again. I should have stayed in retirement. (just kidding ;-) I still would like to bring gl4java to observer clients hehehe. Just give me a key I can use ;-) ;-). Obstreks-RSA-Key-Java1.4.2_02:ct=Obstrek:cr=msucka0xff@programmer.net:\ :cd=March 2004:ar=Java1.4.2_02:cl=inl,standard2:\ :cm=JavaSucks:\ :gk=b1183209e283c57baac600b893e4457780d5dbe897e72271f8f4e275bc8bf725:\ :pk=197118a5329b1f04917ce899df47dfba20017d2fa965e5f6e474d04cc5c14a25: Thanks, -Bob Dang ----- Original Message ----- From: "Carlos Y. Villalpando" Date: Thu, 18 Mar 2004 19:57:02 -0800 To: ". ." , vanilla-devel@us.netrek.org Subject: [Vanilla Devel] Re: Add java key (3rd attempt) > > I've been not very well net-connected at work today, hence the long > delays. > > Quoting . . : > > > This is the 2nd attempt at sending the same message. Basically the > > jar's will be digitally signed. That means that nobody can call the > > 'generateRSAResponse' without a jar that I distributed/created. The > > technology used to sign the jar file is stronger than that which is > > used to authenticate and bless netrek clients. > > I'm researching signed/sealed .jar files, and I see a lot of > references to make sure the browser/user can be sure its untampered so > that the browser/JavaRunTime can expand priveledges, but I can't find > where the server can verify that. Could you help me out and give me a > reference link? Thanks. I'm still looking, though and I admit I'm > not very knowledgeable about this. Teach me. Convice me. > > What I'm worried about is the user unsigning/unsealing all the .jar > classes so that no class would want to throw a Security Exception, > giving it UniversalConnect privledges, removing the certificate checks > in your code, and running that. > > What do you call on the server that will force a Security Exception to > get thrown on the client and you finding out about that and dropping > the connection? Thanks! > > > At this point there are no substantial technical issues surrounding > > the secruity and use of the netrek RSA key for other anything other > > than it's intended purpose. > > I'd like to independantely verify that. Anyone else listening in here > can give me pointers too. > > > If you do not, I would be inclined to the conclusion that you are > > letting your personal feelings interfere with netrek progress. > > Here's a hint: Trying to insult people you're trying to convice of > your position isn't a good idea. Especially when that someone has a > history of publicly trying to remain impartial and reasonable when it > comes to "official duties." As opinionated as we "official" people > are, I've noticed that we are all reasonable when it becomes an issue > of official duties. > > I revoked the Java keys because it became obvious that more people > than just you knew how to extract the Java keys on r.g.n and in my > personal e-mail. I even publicly stated that the abuse monkey > argument wasn't enough. Yes, I have publicly stated as a player on > r.g.n. and in hockey games that I think eject/abuse monkeys are > driving away new players, but I've also said you don't need your > client to be anon, so that wasn't enough. > > I'm all for more observers. I'm all for more coders. > > Now you're introducing a new client verification method, so you have > to expect that you need to convice people. > > Assuming that .jar signing does pan out, a few suggestions: > > 1) INL team captains are going to want to know who's on their obs > slots. At the very least, leave in an IP address, or a FQDN answer > to a pig call handled at the redirector, not the client. > > 2) Now that I think about it...... This really shouldn't be a > separate thing. Once this is mature enough I'm wondering what > it would take to turn this into a Java version of ntserv. Or at > the very least, run the redirector on the same server as the game > and put the redirector in the .bypass file. Roll this into > Vanilla so it doesn't need a key. > > --Carlos V. ----- Original Message ----- From: "Carlos Y. Villalpando" Date: Thu, 18 Mar 2004 19:57:02 -0800 To: ". ." , vanilla-devel@us.netrek.org Subject: [Vanilla Devel] Re: Add java key (3rd attempt) > > I've been not very well net-connected at work today, hence the long > delays. > > Quoting . . : > > > This is the 2nd attempt at sending the same message. Basically the > > jar's will be digitally signed. That means that nobody can call the > > 'generateRSAResponse' without a jar that I distributed/created. The > > technology used to sign the jar file is stronger than that which is > > used to authenticate and bless netrek clients. > > I'm researching signed/sealed .jar files, and I see a lot of > references to make sure the browser/user can be sure its untampered so > that the browser/JavaRunTime can expand priveledges, but I can't find > where the server can verify that. Could you help me out and give me a > reference link? Thanks. I'm still looking, though and I admit I'm > not very knowledgeable about this. Teach me. Convice me. > > What I'm worried about is the user unsigning/unsealing all the .jar > classes so that no class would want to throw a Security Exception, > giving it UniversalConnect privledges, removing the certificate checks > in your code, and running that. > > What do you call on the server that will force a Security Exception to > get thrown on the client and you finding out about that and dropping > the connection? Thanks! > > > At this point there are no substantial technical issues surrounding > > the secruity and use of the netrek RSA key for other anything other > > than it's intended purpose. > > I'd like to independantely verify that. Anyone else listening in here > can give me pointers too. > > > If you do not, I would be inclined to the conclusion that you are > > letting your personal feelings interfere with netrek progress. > > Here's a hint: Trying to insult people you're trying to convice of > your position isn't a good idea. Especially when that someone has a > history of publicly trying to remain impartial and reasonable when it > comes to "official duties." As opinionated as we "official" people > are, I've noticed that we are all reasonable when it becomes an issue > of official duties. > > I revoked the Java keys because it became obvious that more people > than just you knew how to extract the Java keys on r.g.n and in my > personal e-mail. I even publicly stated that the abuse monkey > argument wasn't enough. Yes, I have publicly stated as a player on > r.g.n. and in hockey games that I think eject/abuse monkeys are > driving away new players, but I've also said you don't need your > client to be anon, so that wasn't enough. > > I'm all for more observers. I'm all for more coders. > > Now you're introducing a new client verification method, so you have > to expect that you need to convice people. > > Assuming that .jar signing does pan out, a few suggestions: > > 1) INL team captains are going to want to know who's on their obs > slots. At the very least, leave in an IP address, or a FQDN answer > to a pig call handled at the redirector, not the client. > > 2) Now that I think about it...... This really shouldn't be a > separate thing. Once this is mature enough I'm wondering what > it would take to turn this into a Java version of ntserv. Or at > the very least, run the redirector on the same server as the game > and put the redirector in the .bypass file. Roll this into > Vanilla so it doesn't need a key. > > --Carlos V. > > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Sat Mar 20 14:28:16 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:50:57 2005 Subject: [Vanilla Devel] Re: CVS update: metaserver In-Reply-To: <20040320081904.GA16513@us.netrek.org> Message-ID: <20040320202816.86861.qmail@web21113.mail.yahoo.com> --- James Cameron wrote: > > Apart from the difficulty of synchronising the > replacement of a player > by someone in reserve, I don't see how a minute's delay > in the data > stream will hurt observers of an INL game. They'd still > get to see > everything at the same rate. ;-} Touchee! :) Zach __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Sat Mar 20 14:47:53 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:50:58 2005 Subject: [Vanilla Devel] Re: Add java key (3rd attempt) In-Reply-To: <20040320175419.8EE5E22E18@ws1-10.us4.outblaze.com> Message-ID: <20040320204753.83448.qmail@web21106.mail.yahoo.com> yo jay, i think the security issues exist with the C clients as well as the Java. as Stas said if we want to make our security criteria tight enough than every blessed netrek client out now would have its key revoked. i think carlos has some legitamate concerns and if you can make it comparably as hard to hijack your key as it is with any of the C compiled clients then you will get the key. perhaps allow some others to look at/play with your code. is the CVS server up yet? zach --- ". ." wrote: > Folks, > Well I think the only thing Carlos will accept is the > appology I offered last time, but not the java keys I > have been struggling to get him to accept. The problem of > blessed clients is more complex than I can solve with a > one liner like "jar file is signed". It is almost (if not > entirely) equivalent to the netrek server to netrek > blessed client issue. I just shifted the issue, but > solved nothing. > > The reason for this is that even if the jar file is > signed, I need to have something in the applet telling my > server that the applet originated from my server, and is > running in the client's java plugin. This breaks down if > you were to imagine that somebodies could devise a > surrogate process posing to be the digitally signed > applet. Also the authority of that statement is based on > the believablity that the java plug-in running on a > remote host is saying so, and not an imposter > java-plugin/process. This thing has so many complications > including java VM compatibility within different > webbrowsers (e.g. netscape, MSIE, mozilla), implemented > feature sets (some VM's do support specific features > others do not), that it's intended audience becomes > further diminished. As it is, almost nobody uses it > anyway. I would be worse off with this utility > implemented in this fashion, than the applet being what > it is without. When I began to look at it closely, I had > the gut feeling that I was t > rying to get java to do something it was not able to do. > It was the same feeling I had when I tried to get RMI to > operate in an applet over HTTP tunneling and over remote > proxy servers. It is another example of how java appear > to provide one functionality, but after some reality > checks and internal R&D it turns out not to live up to > its glowing promises. > > If I am to continue using java, I must come up with a way > to obfuscate the key in the java byte codes. But again > this is just a guess and still Carlos must approve. Also > to deliver the applet to more users, I need to either get > rid of RMI (I thought XML was an alternative), or get the > users to grant the applet more privileges (which again > limits the audience). If you look at how the java applet > runs now, you would say it does, only bearly run. It is > no where near as robust or solid as the native C compiled > version. I am not certain that this will change since I > have decided to scale back my effort on this project, if > not abandon it entirely. > > In the mean time, if the server admins can add my java > key to their key chains so that the observer client can > still login to pickup servers that would be terrific. > Note that I think it would be almost as difficult for > someone to call my generateRSAResponse in the correct > sequence with their own info borg as it would be to > reverse engineer the netrek clients, and steal the keys. > Also note that the actual code that runs > 'generateRSAResponse' is a method that belongs to a > remotely activated object that is created in response to > a factory call -- it is all very hairy business > understand the program flow in the first place. Note that > my current version of the applet is obfuscated, and has > no RSA keys. So evil hackors must overcome all of these > issues for the relatively weak reward of accessing an > info borg (not in the wildest fantasy as useful as the > keys to a bank vault). The performance just does not > exist for a play borg, because it is tcp only and routed > thru my bottleneck pa > cket rerouter. > > Please let me know if you can add my key so I will know > which servers to allow the JTrekApplet to run on. One > amusing footnote is that now it only runs on my own > netrek server (which nobody uses anyway), and Robert > Temples original unmodified JTrekApplet could have done > that. What a way to waste a year of my time! I hope this > never happens again. I should have stayed in retirement. > (just kidding ;-) I still would like to bring gl4java to > observer clients hehehe. Just give me a key I can use ;-) > ;-). > > Obstreks-RSA-Key-Java1.4.2_02:ct=Obstrek:cr=msucka0xff@programmer.net:\ > :cd=March 2004:ar=Java1.4.2_02:cl=inl,standard2:\ > :cm=JavaSucks:\ > :gk=b1183209e283c57baac600b893e4457780d5dbe897e72271f8f4e275bc8bf725:\ > :pk=197118a5329b1f04917ce899df47dfba20017d2fa965e5f6e474d04cc5c14a25: > > Thanks, > -Bob Dang > > ----- Original Message ----- > From: "Carlos Y. Villalpando" > Date: Thu, 18 Mar 2004 19:57:02 -0800 > To: ". ." , > vanilla-devel@us.netrek.org > Subject: [Vanilla Devel] Re: Add java key (3rd attempt) > > > > > I've been not very well net-connected at work today, > hence the long > > delays. > > > > Quoting . . : > > > > > This is the 2nd attempt at sending the same message. > Basically the > > > jar's will be digitally signed. That means that > nobody can call the > > > 'generateRSAResponse' without a jar that I > distributed/created. The > > > technology used to sign the jar file is stronger > than that which is > > > used to authenticate and bless netrek clients. > > > > I'm researching signed/sealed .jar files, and I see a > lot of > > references to make sure the browser/user can be sure > its untampered so > > that the browser/JavaRunTime can expand priveledges, > but I can't find > > where the server can verify that. Could you help me > out and give me a > > reference link? Thanks. I'm still looking, though and > I admit I'm > > not very knowledgeable about this. Teach me. Convice > me. > > > > What I'm worried about is the user unsigning/unsealing > all the .jar > > classes so that no class would want to throw a Security > Exception, > > giving it UniversalConnect privledges, removing the > certificate checks > > in your code, and running that. > > > > What do you call on the server that will force a > Security Exception to > > get thrown on the client and you finding out about that > and dropping > > the connection? Thanks! > > > > > At this point there are no substantial technical > issues surrounding > > > the secruity and use of the netrek RSA key for other > anything other > > > than it's intended purpose. > > > > I'd like to independantely verify that. Anyone else > listening in here > > can give me pointers too. > > > > > If you do not, I would be inclined to the conclusion > that you are > > > letting your personal feelings interfere with netrek > progress. > > > > Here's a hint: Trying to insult people you're trying to > convice of > > your position isn't a good idea. Especially when that > someone has a > > history of publicly trying to remain impartial and > reasonable when it > > comes to "official duties." As opinionated as we > "official" people > > are, I've noticed that we are all reasonable when it > becomes an issue > > of official duties. > > > > I revoked the Java keys because it became obvious that > more people > > than just you knew how to extract the Java keys on > r.g.n and in my > > personal e-mail. I even publicly stated that the abuse > monkey > > argument wasn't enough. Yes, I have publicly stated as > a player on > > r.g.n. and in hockey games that I think eject/abuse > monkeys are > > driving away new players, but I've also said you don't > need your > > client to be anon, so that wasn't enough. > > > > I'm all for more observers. I'm all for more coders. > > > > Now you're introducing a new client verification > method, so you have > > to expect that you need to convice people. > > > > Assuming that .jar signing does pan out, a few > suggestions: > > > > 1) INL team captains are going to want to know who's > on their obs > > slots. At the very least, leave in an IP address, > or a FQDN answer > > to a pig call handled at the redirector, not the > client. > > > > 2) Now that I think about it...... This really > shouldn't be a > > separate thing. Once this is mature enough I'm > wondering what > > it would take to turn this into a Java version of > ntserv. Or at > > the very least, run the redirector on the same > server as the game > > and put the redirector in the .bypass file. Roll > this into > > Vanilla so it doesn't need a key. > > > > --Carlos V. > > ----- Original Message ----- > From: "Carlos Y. Villalpando" > Date: Thu, 18 Mar 2004 19:57:02 -0800 > To: ". ." , > vanilla-devel@us.netrek.org > Subject: [Vanilla Devel] Re: Add java key (3rd attempt) > > > > > I've been not very well net-connected at work today, > hence the long > > delays. > > > > Quoting . . : > > > > > This is the 2nd attempt at sending the same message. > Basically the > > > jar's will be digitally signed. That means that > nobody can call the > > > 'generateRSAResponse' without a jar that I > distributed/created. The > > > technology used to sign the jar file is stronger > than that which is > > > used to authenticate and bless netrek clients. > > > > I'm researching signed/sealed .jar files, and I see a > lot of > > references to make sure the browser/user can be sure > its untampered so > > that the browser/JavaRunTime can expand priveledges, > but I can't find > > where the server can verify that. Could you help me > out and give me a > > reference link? Thanks. I'm still looking, though and > I admit I'm > > not very knowledgeable about this. Teach me. Convice > me. > > > > What I'm worried about is the user unsigning/unsealing > all the .jar > > classes so that no class would want to throw a Security > Exception, > > giving it UniversalConnect privledges, removing the > certificate checks > > in your code, and running that. > > > > What do you call on the server that will force a > Security Exception to > > get thrown on the client and you finding out about that > and dropping > > the connection? Thanks! > > > > > At this point there are no substantial technical > issues surrounding > > > the secruity and use of the netrek RSA key for other > anything other > > > than it's intended purpose. > > > > I'd like to independantely verify that. Anyone else > listening in here > > can give me pointers too. > > > > > If you do not, I would be inclined to the conclusion > that you are > > > letting your personal feelings interfere with netrek > progress. > > > > Here's a hint: Trying to insult people you're trying to > convice of > > your position isn't a good idea. Especially when that > someone has a > > history of publicly trying to remain impartial and > reasonable when it > > comes to "official duties." As opinionated as we > "official" people > > are, I've noticed that we are all reasonable when it > becomes an issue > > of official duties. > > > > I revoked the Java keys because it became obvious that > more people > > than just you knew how to extract the Java keys on > r.g.n and in my > > personal e-mail. I even publicly stated that the abuse > monkey > > argument wasn't enough. Yes, I have publicly stated as > a player on > > r.g.n. and in hockey games that I think eject/abuse > monkeys are > > driving away new players, but I've also said you don't > need your > > client to be anon, so that wasn't enough. > > > > I'm all for more observers. I'm all for more coders. > > > > Now you're introducing a new client verification > method, so you have > > to expect that you need to convice people. > > > > Assuming that .jar signing does pan out, a few > suggestions: > > > > 1) INL team captains are going to want to know who's > on their obs > > slots. At the very least, leave in an IP address, > or a FQDN answer > > to a pig call handled at the redirector, not the > client. > > > > 2) Now that I think about it...... This really > shouldn't be a > > separate thing. Once this is mature enough I'm > wondering what > > it would take to turn this into a Java version of > ntserv. Or at > > the very least, run the redirector on the same > server as the game > > and put the redirector in the .bypass file. Roll > this into > > Vanilla so it doesn't need a key. > > > > --Carlos V. > > > > > > _______________________________________________ > > vanilla-devel mailing list > > vanilla-devel@us.netrek.org > > > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Sat Mar 20 17:26:46 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:58 2005 Subject: [Vanilla Devel] Re: Add java key (3rd attempt) Message-ID: <20040320232646.2145A43EF4@ws1-9.us4.outblaze.com> true, also maybe there's a way to do it with signed jars. i still could use more study and help if you know of a way or know someone who knows a way or know a newsgroup that has ppl that knows the way ;-) ill put it up tomorrow -jay -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Mon Mar 22 00:07:43 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:58 2005 Subject: [Vanilla Devel] Re: Add java key (3rd attempt) In-Reply-To: <20040320175419.8EE5E22E18@ws1-10.us4.outblaze.com> References: <20040320175419.8EE5E22E18@ws1-10.us4.outblaze.com> Message-ID: <20040322060743.GA5112@us.netrek.org> I'm a bit lacking in time at the moment, and I haven't investigated how to add a key locally. That's why I asked Carlos if he could add it in another category. I know I can change the categories accepted by the server. And no, I have no great desire at this time to implement the observer time delay ... but it's something that appeals to me if abuse escalates. Besides, if I did, you could all turn it off on your servers. ;-) -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Mon Mar 22 20:54:30 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:58 2005 Subject: [Vanilla Devel] Obstrek source online in cvs repo Message-ID: <20040323025430.39CA92ABCC@ws1-6.us4.outblaze.com> Folks, The Obstrek client source code is now available in an online CVS repo. To obtain an up-to-the-minute snapshot of the code, point your CVS client at the repository and do a checkout. % cvs -d :pserver:obstrek@c-24-4-208-59.client.comcast.net:/var/lib/cvs \ login Password: obstrek0 % cvs -d :pserver:obstrek@c-24-4-208-59.client.comcast.net:/var/lib/cvs \ checkout jtrek % cvs -d :pserver:obstrek@c-24-4-208-59.client.comcast.net:/var/lib/cvs \ checkout netscape Notes: * project files are called 'jtrek' * javac compiler requires netscape class files, which are included in the repo unless you already have them. -Bob Dang -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From slagerni at msu.edu Tue Mar 23 10:47:14 2004 From: slagerni at msu.edu (Nicholas James Slager) Date: Wed Jan 12 00:50:58 2005 Subject: [Vanilla Devel] Pre-T bot problem In-Reply-To: <5.2.0.9.0.20040227105552.03bb4eb8@mailgate.team17.com> References: <200402201955.i1KJt2a00637@swashbuckler.real-time.com> <5.2.0.9.0.20040223165720.037ea8b8@mailgate.team17.com> <20040223214223.GB9995@us.netrek.org> <5.2.0.9.0.20040227105552.03bb4eb8@mailgate.team17.com> Message-ID: As a pontential solution to the bots not leaving problem, try compliling and running the following small bit of code: #include int main () { char localHostName[80]; gethostname(localHostName, 80); printf("%s\n", localHostName); } compile and run with: gcc test.c; ./a.out or however you really want to do it. Set ROBOTHOST in your .sysdef = whatever gets output. This should make the application aware of what player is actually a bot. If David or James could verify that this either does or does not solve the problem I'd really appreciate it. Thanks, Nick David Watson writes: > > I believe that PreT is always 4v4 so there is a limit (not sure why it is > needed) On a working preT server you do see the teams greyed out before a > bot quits leaving a slot open for you to join. once you reach the minimum > for T then preT ends and you can progress up to a full game... > > Certainly the bots are not quitting out at any time, either when a human > wants in or after preT times out with no players. To my uneducated eye it > looks like the bots slot is freed in order to get it out? Its the pret bot > that manages this (robots/pret.c) and the function given below > > static void stop_a_robot(void) > { > int i; > struct player *j; > int teamToStop; > > if(debugTarget != -1 && debugLevel == 3) { > messOne(255, roboname, debugTarget, "#1(%d): %d #2(%d): %d", > team1, num_humans(team1), team2, num_humans(team2)); > } > if(num_humans(team1) < num_humans(team2)) > teamToStop = team1; > else > teamToStop = team2; > > if(debugTarget != -1 && debugLevel == 3) { > messOne(255, roboname, debugTarget, "Stopping from %d", teamToStop); > } > /* Nuke robot from the team with the fewest humans. */ > for (i = 0, j = players; i < MAXPLAYER; i++, j++) { > if (j->p_status == PFREE) > continue; > if (j->p_flags & PFROBOT) > continue; > > /* If he's at the MOTD we'll get him next time. */ > if (j->p_team == teamToStop && j->p_status == PALIVE && > rprog(j->p_login, j->p_full_hostname)) { > stop_this_bot(j); > return; > } > } > } > > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From David.Watson at team17.com Tue Mar 23 11:23:06 2004 From: David.Watson at team17.com (David Watson) Date: Wed Jan 12 00:50:58 2005 Subject: [Vanilla Devel] Pre-T bot problem In-Reply-To: References: <5.2.0.9.0.20040227105552.03bb4eb8@mailgate.team17.com> <200402201955.i1KJt2a00637@swashbuckler.real-time.com> <5.2.0.9.0.20040223165720.037ea8b8@mailgate.team17.com> <20040223214223.GB9995@us.netrek.org> <5.2.0.9.0.20040227105552.03bb4eb8@mailgate.team17.com> Message-ID: <5.2.0.9.0.20040323172042.058dfab8@mailgate.team17.com> Setting the hostname in ROBOTHOST gives exactly the same behavior. If I set an incorrect value means the robots will not start (whether or not the name resolves. Thanks Dave _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Tue Mar 23 13:26:37 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:50:58 2005 Subject: [Vanilla Devel] Pre-T bot problem In-Reply-To: Message-ID: <20040323192637.77738.qmail@web21111.mail.yahoo.com> cool. IIRC some *nix systems use the gethostbyname() call instead of gethostname() zach --- Nicholas James Slager wrote: > As a pontential solution to the bots not leaving problem, > try compliling and > running the following small bit of code: > > #include > > int main () { > char localHostName[80]; > > gethostname(localHostName, 80); > printf("%s\n", localHostName); > } > > compile and run with: gcc test.c; ./a.out > or however you really want to do it. > > Set ROBOTHOST in your .sysdef = whatever gets output. > This should make the > application aware of what player is actually a bot. If > David or James could > verify that this either does or does not solve the > problem I'd really > appreciate it. > > Thanks, > Nick > > > David Watson writes: > > > > > I believe that PreT is always 4v4 so there is a limit > (not sure why it is > > needed) On a working preT server you do see the teams > greyed out before a > > bot quits leaving a slot open for you to join. once you > reach the minimum > > for T then preT ends and you can progress up to a full > game... > > > > Certainly the bots are not quitting out at any time, > either when a human > > wants in or after preT times out with no players. To my > uneducated eye it > > looks like the bots slot is freed in order to get it > out? Its the pret bot > > that manages this (robots/pret.c) and the function > given below > > > > static void stop_a_robot(void) > > { > > int i; > > struct player *j; > > int teamToStop; > > > > if(debugTarget != -1 && debugLevel == 3) { > > messOne(255, roboname, debugTarget, "#1(%d): %d > #2(%d): %d", > > team1, num_humans(team1), team2, num_humans(team2)); > > } > > if(num_humans(team1) < num_humans(team2)) > > teamToStop = team1; > > else > > teamToStop = team2; > > > > if(debugTarget != -1 && debugLevel == 3) { > > messOne(255, roboname, debugTarget, "Stopping from > %d", teamToStop); > > } > > /* Nuke robot from the team with the fewest humans. > */ > > for (i = 0, j = players; i < MAXPLAYER; i++, j++) { > > if (j->p_status == PFREE) > > continue; > > if (j->p_flags & PFROBOT) > > continue; > > > > /* If he's at the MOTD we'll get him next time. > */ > > if (j->p_team == teamToStop && j->p_status == > PALIVE && > > rprog(j->p_login, j->p_full_hostname)) { > > stop_this_bot(j); > > return; > > } > > } > > } > > > > > > _______________________________________________ > > vanilla-devel mailing list > > vanilla-devel@us.netrek.org > > > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > > > > > > > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Tue Mar 23 17:20:39 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:58 2005 Subject: [Vanilla Devel] Pre-T bot problem In-Reply-To: <20040323192637.77738.qmail@web21111.mail.yahoo.com> References: <20040323192637.77738.qmail@web21111.mail.yahoo.com> Message-ID: <20040323232039.GA12726@us.netrek.org> On Tue, Mar 23, 2004 at 11:26:37AM -0800, Zach wrote: > cool. IIRC some *nix systems use the gethostbyname() call > instead of gethostname() Not really. Both are standard calls, and they differ. The first is for obtaining the IP address of a host given a name, and the second is for obtaining the host name of the host executing the program. Some programs need to have the host name that they will be perceived as by their peers when communicating over TCP/IP. For these, they may use getsockname() to find the IP address through which the connection leaves the machine, and then gethostbyaddr() to find the host name corresponding to this IP. This sometimes doesn't work, because gethostbyaddr() may use /etc/hosts to find the name, and the peer doesn't have our /etc/hosts. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Wed Mar 24 09:29:59 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:58 2005 Subject: [Vanilla Devel] Add Java Key (Again) Message-ID: <20040324152959.6EDCC22E1C@ws1-8.us4.outblaze.com> Carlos, I believe it is time again to ask to get the Java key back into the main key chain. The reason being that there are many benefits to using the Java programming language include the 3d graphics, and general client enhancement possibilities. The availability of a large development community, and a broad range of code libraries adds value to its proposition. As a distributed client that can demo netrek to new users from a webbrowser, it is unparalleled. There are certain features such as XML that provide proxy-server and firewall traversal without requiring adminstrative level adjustments. A further survey of the Java-Byte codes, the security model, and other mechanisms like Java to Native Interface can be explored to improve the prevention of client compromise. Also with a beta test group we can iron out the bugs. The primary concern of key compromise has been sufficiently addressed in the sense that the key is not exposed to reverse decompiling. The Java Keys are not exposed i n the Obstrek observer client because they are not in the applet that runs on the users desktop, and the code is obfuscated making it especially difficult to create any borgs from this. Also since it runs in through a redirector, it is unlikely that anyone would want to create a borg. I think we can provide better solutions over time to this concern, but it really needs to move from a dead project to something that developers can continue to evolve. Also the issue of anonymous spamming can easily be fixed, and would improve as well. Here (again) is the java key. Please add it. I think most developers and people that play netrek would agree that there is real value of a Java based observer client and the security measures are sufficient and will continue to improve. I think for an early stage client, the acid test should be not immediately applied, since other early clients were given time to evolve, the same leeway can be taken for all due fairness. -Bob Dang Obstreks-RSA-Key-Java1.4:ct=Obstrek:cr=msucka0xff@programmer.net:\ :cd=March 2004:ar=Java1.4:cl=inl,standard2:\ :cm=Java 1.4:\ :gk=b1183209e283c57baac600b893e4457780d5dbe897e72271f8f4e275bc8bf725:\ :pk=197118a5329b1f04917ce899df47dfba20017d2fa965e5f6e474d04cc5c14a25: -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Wed Mar 24 12:01:33 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:50:58 2005 Subject: [Vanilla Devel] Pre-T bot problem In-Reply-To: <20040323232039.GA12726@us.netrek.org> Message-ID: <20040324180133.17172.qmail@web21101.mail.yahoo.com> --- James Cameron wrote: > > Not really. Both are standard calls, and they differ. > The first is for > obtaining the IP address of a host given a name, and the > second is for > obtaining the host name of the host executing the > program. > > Some programs need to have the host name that they will > be perceived as > by their peers when communicating over TCP/IP. For > these, they may use > getsockname() to find the IP address through which the > connection leaves > the machine, and then gethostbyaddr() to find the host > name corresponding > to this IP. This sometimes doesn't work, because > gethostbyaddr() may use > /etc/hosts to find the name, and the peer doesn't have > our /etc/hosts. Ah. I see. Thanks for the clarification! Zach __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Wed Mar 24 20:40:27 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:58 2005 Subject: [Vanilla Devel] Re: [Netrek Clients] Add Java Key (Again) Message-ID: <20040325024027.55CD522E89@ws1-8.us4.outblaze.com> OK I'm going to come up with a different angle of encryption for the Java clients. I think I may an idea which seems good, and will post for review. Since this is a rather difficult topic, I'm not immediately able to solve it. -Bob Dang ----- Original Message ----- From: ". ." Date: Wed, 24 Mar 2004 07:29:59 -0800 To: vanilla-devel@us.netrek.org, vanilla-clients@us.netrek.org,vanilla-metaserver@us.netrek.org Subject: [Netrek Clients] Add Java Key (Again) > Carlos, > I believe it is time again to ask to get the Java key back into the main key chain. The reason being that there are many benefits to using the Java programming language include the 3d graphics, and general client enhancement possibilities. The availability of a large development community, and a broad range of code libraries adds value to its proposition. As a distributed client that can demo netrek to new users from a webbrowser, it is unparalleled. There are certain features such as XML that provide proxy-server and firewall traversal without requiring adminstrative level adjustments. A further survey of the Java-Byte codes, the security model, and other mechanisms like Java to Native Interface can be explored to improve the prevention of client compromise. Also with a beta test group we can iron out the bugs. The primary concern of key compromise has been sufficiently addressed in the sense that the key is not exposed to reverse decompiling. The Java Keys are not exposed i > n the Obstrek observer client because they are not in the applet that runs on the users desktop, and the code is obfuscated making it especially difficult to create any borgs from this. Also since it runs in through a redirector, it is unlikely that anyone would want to create a borg. I think we can provide better solutions over time to this concern, but it really needs to move from a dead project to something that developers can continue to evolve. Also the issue of anonymous spamming can easily be fixed, and would improve as well. Here (again) is the java key. Please add it. I think most developers and people that play netrek would agree that there is real value of a Java based observer client and the security measures are sufficient and will continue to improve. I think for an early stage client, the acid test should be not immediately applied, since other early clients were given time to evolve, the same leeway can be taken for all due fairness. > -Bob Dang > > Obstreks-RSA-Key-Java1.4:ct=Obstrek:cr=msucka0xff@programmer.net:\ > :cd=March 2004:ar=Java1.4:cl=inl,standard2:\ > :cm=Java 1.4:\ > :gk=b1183209e283c57baac600b893e4457780d5dbe897e72271f8f4e275bc8bf725:\ > :pk=197118a5329b1f04917ce899df47dfba20017d2fa965e5f6e474d04cc5c14a25: > > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > _______________________________________________ > vanilla-clients mailing list > vanilla-clients@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-clients -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From larry.coates at rtg-usa.com Wed Mar 24 21:54:14 2004 From: larry.coates at rtg-usa.com (Larry Coates) Date: Wed Jan 12 00:50:59 2005 Subject: [Vanilla Devel] Re: Resources for work in the US! Message-ID: <002101c4121c$d6cdeae0$6401a8c0@CPQ49314066312> Skipped content of type multipart/alternative-------------- next part -------------- _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Fri Mar 26 18:26:49 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:59 2005 Subject: [Vanilla Devel] CVS update: Vanilla Message-ID: <200403270026.i2R0QnI13415@swashbuckler.real-time.com> Date: Friday March 26, 2004 @ 18:26 Author: tanner Update of /home/netrek/cvsroot/Vanilla In directory swashbuckler.real-time.com:/var/tmp/cvs-serv13412 Modified Files: configure.in Log Message: Under debian unstable powerpc, I needed to adding m4 stuff to find the glib includes and glib libraries. Tested this against debian unstable sparc and intel, same problem. **************************************** Index: Vanilla/configure.in diff -u Vanilla/configure.in:1.25 Vanilla/configure.in:1.26 --- Vanilla/configure.in:1.25 Tue May 1 21:00:18 2001 +++ Vanilla/configure.in Fri Mar 26 18:26:48 2004 @@ -94,7 +94,11 @@ AC_CHECK_HEADERS(unistd.h memory.h math.h stdlib.h) AC_CHECK_HEADERS(sys/timeb.h sys/ptyio.h sys/fcntl.h fcntl.h) AC_CHECK_HEADERS(ctype.h machine/endian.h sys/resource.h) -AC_CHECK_HEADERS(sys/wait.h netinet/in.h sys/filio.h) +AC_CHECK_HEADERS(sys/wait.h netinet/in.h sys/filio.h gdbm.h) +AC_CHECK_HEADERS(ncurses.h) + +AC_CHECK_LIB(gdbm, gdbm_open, [LIBS="$LIBS -lgdbm"]) +AM_PATH_GLIB(1.2.10, [LIBS="$LIBS $GLIB_LIBS" CFLAGS="$CFLAGS $GLIB_CFLAGS"], [AC_MSG_ERROR(GLIB not in path)]) AC_FUNC_WAIT3 AC_TYPE_PID_T _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From xyzzy at speakeasy.org Fri Mar 5 18:06:43 2004 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:51:54 2005 Subject: [Vanilla List] NO_DUPLICATE_HOSTS on Continuum In-Reply-To: <20040217013034.GC28599@us.netrek.org> Message-ID: On Tue, 17 Feb 2004, James Cameron wrote: > The way it works is to hold the client back from joining the queue or > the game until a previous client from the same IP address exits. The > client displays a wait queue of 32. Besides keeping people from joining multiple times, this does two other things. You can't switch teams by waiting in the queue for a open slot to come up on the other team. If you ghostbust, you can't come back in until your slot is finally freed. > passed by others not in the game. In the "wait queue 32" state, you are > not strictly in a queue at all. The server end of the connection will > be polling the player list, waiting for you to free the slot. Once that > happens, it will be as if you started the client then. How does the player list polling work? I get worried whenever I hear someone say polling. _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From quozl at us.netrek.org Sun Mar 7 16:28:21 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:54 2005 Subject: [Vanilla Devel] Re: [Vanilla List] NO_DUPLICATE_HOSTS on Continuum In-Reply-To: References: <20040217013034.GC28599@us.netrek.org> Message-ID: <20040307222821.GA3307@us.netrek.org> On Fri, Mar 05, 2004 at 04:06:43PM -0800, Trent Piepho wrote: > You can't switch teams by waiting in the queue for a open slot to come up on > the other team. Yes. To compensate, I was thinking of adding a queue for each team. > If you ghostbust, you can't come back in until your slot is finally freed. Yes. I thought of the new connection destroying the old, but that would give everyone a fast way back to their home planet. How long is this delay, and what causes the ghostbust? I had earlier reduced the amount of time that the server will reattempt connection over TCP back to the client on the fallback port. Without being able to do that, there's little point the server keeping the slot in use. > How does the player list polling work? I get worried whenever I hear > someone say polling. Each second, iterates through the player list, doing a strcmp() against each active slot's p_full_hostname. This continues while the Q32 state persists. By comparison, the normal queue polling which happens while you are waiting for a slot in a full game, checks each second to see if is at head of queue, and if so calls pickslot(). The latter is certainly cheaper than the former, but on the old hardware we use for continuum the former is still quite cheap. The netrekd process will not fork more than MAXPROCESSES (88) processes. The wait queue is limited to MAXWAITING (32) as usual. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From msucka0xff at programmer.net Wed Mar 24 09:29:59 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:53:26 2005 Subject: [META] Add Java Key (Again) Message-ID: <20040324152959.6EDCC22E1C@ws1-8.us4.outblaze.com> Carlos, I believe it is time again to ask to get the Java key back into the main key chain. The reason being that there are many benefits to using the Java programming language include the 3d graphics, and general client enhancement possibilities. The availability of a large development community, and a broad range of code libraries adds value to its proposition. As a distributed client that can demo netrek to new users from a webbrowser, it is unparalleled. There are certain features such as XML that provide proxy-server and firewall traversal without requiring adminstrative level adjustments. A further survey of the Java-Byte codes, the security model, and other mechanisms like Java to Native Interface can be explored to improve the prevention of client compromise. Also with a beta test group we can iron out the bugs. The primary concern of key compromise has been sufficiently addressed in the sense that the key is not exposed to reverse decompiling. The Java Keys are not exposed i n the Obstrek observer client because they are not in the applet that runs on the users desktop, and the code is obfuscated making it especially difficult to create any borgs from this. Also since it runs in through a redirector, it is unlikely that anyone would want to create a borg. I think we can provide better solutions over time to this concern, but it really needs to move from a dead project to something that developers can continue to evolve. Also the issue of anonymous spamming can easily be fixed, and would improve as well. Here (again) is the java key. Please add it. I think most developers and people that play netrek would agree that there is real value of a Java based observer client and the security measures are sufficient and will continue to improve. I think for an early stage client, the acid test should be not immediately applied, since other early clients were given time to evolve, the same leeway can be taken for all due fairness. -Bob Dang Obstreks-RSA-Key-Java1.4:ct=Obstrek:cr=msucka0xff@programmer.net:\ :cd=March 2004:ar=Java1.4:cl=inl,standard2:\ :cm=Java 1.4:\ :gk=b1183209e283c57baac600b893e4457780d5dbe897e72271f8f4e275bc8bf725:\ :pk=197118a5329b1f04917ce899df47dfba20017d2fa965e5f6e474d04cc5c14a25: -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-metaserver mailing list vanilla-metaserver@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver From msucka0xff at programmer.net Wed Mar 24 20:40:27 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:53:26 2005 Subject: [META] Re: [Netrek Clients] Add Java Key (Again) Message-ID: <20040325024027.55CD522E89@ws1-8.us4.outblaze.com> OK I'm going to come up with a different angle of encryption for the Java clients. I think I may an idea which seems good, and will post for review. Since this is a rather difficult topic, I'm not immediately able to solve it. -Bob Dang ----- Original Message ----- From: ". ." Date: Wed, 24 Mar 2004 07:29:59 -0800 To: vanilla-devel@us.netrek.org, vanilla-clients@us.netrek.org,vanilla-metaserver@us.netrek.org Subject: [Netrek Clients] Add Java Key (Again) > Carlos, > I believe it is time again to ask to get the Java key back into the main key chain. The reason being that there are many benefits to using the Java programming language include the 3d graphics, and general client enhancement possibilities. The availability of a large development community, and a broad range of code libraries adds value to its proposition. As a distributed client that can demo netrek to new users from a webbrowser, it is unparalleled. There are certain features such as XML that provide proxy-server and firewall traversal without requiring adminstrative level adjustments. A further survey of the Java-Byte codes, the security model, and other mechanisms like Java to Native Interface can be explored to improve the prevention of client compromise. Also with a beta test group we can iron out the bugs. The primary concern of key compromise has been sufficiently addressed in the sense that the key is not exposed to reverse decompiling. The Java Keys are not exposed i > n the Obstrek observer client because they are not in the applet that runs on the users desktop, and the code is obfuscated making it especially difficult to create any borgs from this. Also since it runs in through a redirector, it is unlikely that anyone would want to create a borg. I think we can provide better solutions over time to this concern, but it really needs to move from a dead project to something that developers can continue to evolve. Also the issue of anonymous spamming can easily be fixed, and would improve as well. Here (again) is the java key. Please add it. I think most developers and people that play netrek would agree that there is real value of a Java based observer client and the security measures are sufficient and will continue to improve. I think for an early stage client, the acid test should be not immediately applied, since other early clients were given time to evolve, the same leeway can be taken for all due fairness. > -Bob Dang > > Obstreks-RSA-Key-Java1.4:ct=Obstrek:cr=msucka0xff@programmer.net:\ > :cd=March 2004:ar=Java1.4:cl=inl,standard2:\ > :cm=Java 1.4:\ > :gk=b1183209e283c57baac600b893e4457780d5dbe897e72271f8f4e275bc8bf725:\ > :pk=197118a5329b1f04917ce899df47dfba20017d2fa965e5f6e474d04cc5c14a25: > > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > _______________________________________________ > vanilla-clients mailing list > vanilla-clients@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-clients -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-metaserver mailing list vanilla-metaserver@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver