I've been not very well net-connected at work today, hence the long

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