Here's the conversation from freenode describing it: omygawshkenas: Yep, most of the time its wonderful — but I've got a bit of a thundercloud: omygawshkenas: When trying to use a signed jar. It works great in combination with a signed jruby.jar omygawshkenas: But with the vanilla jruby command, when I try to subclass something in that .jar, I get: omygawshkenas: Caused by: java.lang.SecurityException: class "processing.core.PApplet$Proxy0"'s signer information does not match signer information of other classes in the same package 6:05 PM omygawshkenas: Because the proxy is coming from JRuby, which isn't signed. omygawshkenas: Which is a quandary. headius: oh, I see headius: well we could tack on something else to the package headius: org.jruby.proxy headius: though headius: hmmm java.lang.reflect.Proxy headius: depends if we're doing the proxy or not omygawshkenas: I was hoping that there would be a workaround, involving turning off the particular aspect of the Security Sanbox, but there doesn't seem to be. logan_barnett: omygawshkenas: <security> logan_barnett: <all-permissions/> logan_barnett: </security> <-- you have this? logan_barnett: In your JNLP, that is. omygawshkenas: yeah, I know about that one. But this is for distribution, and I can't make everyone turn off their security. omygawshkenas: However, it is bundling jruby-complete, so perhaps it'll just have to become more self-contained, with everything going through there. rvalyi has joined the channel 6:10 PM logan_barnett: If processing uses native extensions, I could see why the security manager would call foul. omygawshkenas: It doesn't, actually, but it has libraries which do. logan_barnett: Did you self-sign all of the jars? omygawshkenas: Yeah. logan_barnett: I think when doing self-signing, you can't mix and match signatures. headius: hmmm omygawshkenas: Yeah, there was one thread on the web about "getting a real cert" logan_barnett: That's lots of money though? logan_barnett: At least not a trivial amount. logan_barnett: That's what I've heard. No real authority. omygawshkenas: Yep, too much money for me, and again, this is going to be distributed for other people to write code with, so I can't really have it be officially signed — that would defeat the purpose (and probably the legality) of the real certs. 6:15 PM omygawshkenas: But I already have a script/open for running them, and can just force the use of that. The next thing is to cook up a script/spec .... msmitty has quit the server jdamick_ has quit the server saying: Read error: 110 (Connection timed out) headius: omygawshkenas: I think we can just decorate that package name headius: that would solve it, no? omygawshkenas: I'm not sure... Not too familiar with decorations. Sounds like a neat workaround, though. headius: we already do this because java.* packages are protected headius: pastie pastie: http://pastie.org/186465 by headius. walters has quit the server saying: Read error: 110 (Connection timed out) headius: we could easily just stick org.jruby.proxy on the beginning of all such packages msmitty has joined the channel headius: I also notice we instantiate the resulting class with the protect domain of JRuby rather than of the target proxy wrappee headius: which also is probably not right headius: either way 6:20 PM headius: file a bug with this conversation omygawshkenas: Cool. So, the actual subclass would belong to the real package, and the proxy object would belong to the proxy package? omygawshkenas: Will do.