I've been not very well net-connected at work today, hence the long delays. Quoting . . <msucka0xff at programmer.net>: > 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 at us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel