Based on my brief review of the script-security-plugin source code, when a new classpath exception is added to the Jenkins master a hash is generated for the path, presumably to be able to track when changes are made to the path.

Further, it appears as though the current implementation bases it's hash on the contents of the classpath folder itself (ie: file and subfolder names) rather than it's contents. For example, if a file within the classpath is modified the hash doesn't change but if a new file gets added to the classpath the hash does change.

This is particularly fragile since any number of processes or operations may create files within the classpath folder, none of which have any functional impact on the jars and scripts contained therein.

Here is a trivial example of a problem we just recently ran into. We have some system groovy scripts stored in Scriptler on our Jenkins master. In order for jobs to make use of those scripts we need to add the classpath to the build steps that make use of them. Further, when adding this classpath the job will only build if the path is in the approved classpath list. In one of our example cases we had logged into the Jenkins server and opened one of the groovy files therein using the 'vim' text editor. Further, when vim edits a file it creates a temporary file for storing changes within the current working folder. In so doing the temporary file causes the hash for the classpath to change (ie: new file detected in the classpath) causing all production builds that make use of those scripts to fail. To make matters worse the cause of these failures is difficult at best to diagnose.

My first thought is - why do you need to store a hash of the classpath at all. Assuming only system administrators have access for approving global classpaths, so long as the URI doesn't change everything should be good. Further, assuming the classpath points to a location on the Jenkins master, and that server is also secured with access limited to just sys-admins, then no one can directly modify the contents of the classpath without authorization anyway. Thus, removing the hash completely from the classpath would have little to no effect on the security of the farm while having the nice side effect of avoiding these kinds of problems.

If, however, there is some reason to keep the hash around, perhaps the hash could be reconfigured so that it is calculated based on the file contents within the folder, perhaps using some search criteria for files to include / exclude from the hash (ie: */.groovy in the case of scriptler would probably work). In this way temporary files, backup files and other such randomly generated files that may appear within the folder wouldn't affect the hash.