Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Crash due to incompatibility with RebornCore due to adding class to signed package #68
Caused by: java.lang.SecurityException: class "javassist.ClassLoaderPool"'s signer information does not match signer information of other classes in the same package The classloader in use is actually enforcing signing. It usually doesn't. ClassLoaderPool isn't part of javassist, it's in that package so it can use package private parts of it. That's hacky but usually works fine.…
On 27 April 2017 at 00:31, Steve ***@***.***> wrote: TickProfiler seems to be looking for javassist.ClassLoaderPool, which causes the server to crash. Pastebin: https://pastebin.com/G9wChTBw Forge version 22.214.171.1242 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#68>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAvwaLS2-zCZNjTuW2exD-NAvHbxrTCmks5rz9PAgaJpZM4NJjF3> .
-- Ross Allan
I add a class into the javassist package, which is technically wrong, but the least messy workaround to implement this: https://github.com/nallar/ModPatcher/blob/1.11.2/src/main/java/javassist/ClassLoaderPool.java
Usually LaunchClassLoader doesn't enforce signing (I could be presuming this incorrectly.). I don't add the javassist package as a classloader exclusion either, only a transformer exclusion. Presumably you add a classloader exclusion for that package, or something else does, so the system classloader is being used which does care about signing?
Completely unrelated, but I find it quite funny that you chose to use javassist to implement mixins, when I chose to migrate away from javassist to asm for my mixin implementation.
I dont think there is a lot more I can do to fix this on our end. I added javaassist to the exclusions list and that produced this crash: https://gist.github.com/modmuss50/38ef0076ee394cbbcd1fbfda24bbb630
I think the best thing we both could do to fix it would be to repackage javaassist into our own packages. You could also try and move that class out from javaasist but I see how that could be an issue.
If you have any ideas on how this could be solved I would love to hear them.
You could stop signing packages in your jar which are from other libraries, which would resolve this. Currently you sign your own code as well as signing your dependencies.
In the long term I should get javassist changed to make the methods I need to override not package private but that will take some time for a new release.
Repackaging would work but adds the overhead of having the same classes loaded multiple times under different names. Best to avoid that unless absolutely necessary.