During a discussion of this patching mechanism between Kevin Conner and the security response team, we covered the issue of old JARs being left on the system after they have been updated by a patch. With previous zip-based patching, the old JARs would be overwritten. With this mechanism, the old JARs are left on the system (for rollback etc.). This potentially exposes security concerns, where a patch provides updated JARs that resolve security issues. Although the old JARs would not be deployed in the running server, they could be exposed via classpath, and they could be accidentally/inadvertently used in running code. To remove this possibility, I suggest disabling old JARs when they are archived, and then re-enabling them again if and when they are rolled back. The disabling would need to be two-way (i.e. you can disable then re-enable later). It doesn't need to use any fancy techniques, so long as it effectively renders the JAR unusable. Off the top of my head, one way to do this is to just flip a bit in the zip file end of central directory signature (little-endian 0x06054b50). I have tested this method and it renders the JAR unable to be extracted, and unable to be executed by the JVM. Re-enabling is just a matter of flipping the bit back. Of course, this only works for zipped JARs; exploded JARs would require something similar done to the individual class files.
What do people think, it this a feasible idea?