it may or may not work depending on the changes made to the script/module.
It
must work, if the developer of the script or module knows what he or she is doing. In fact, AFAIK this has not happened with any standard script or module so far.
We have many resources implemented to support backward compatibility. For example, there are a few standard tools that have changed significantly since the first versions we published back in 2008. In the rare cases where this happens, we always provide a compatibility version and automatic replacement of existing instances. An example is ATrousWaveletTransform. Right now you can open a .psm file created in 2008, and all ATrousWaveletTransform icons will be converted automatically into ATrousWaveletTransformV1 icons. The ATrousWaveletTransformV1 process is available under the Compatibility category. We take backward compatibility very seriously.
Perhaps, saving all the modules and scripts with the project data would be possible? Then when the project is opened, it would use the saved versions instead of those stored in Program Files.
This would introduce serious problems. For example, the automatic update system would basically not work. Bugs would never get fixed, improved versions would not be distributed consistently, and mutual interactions between different tools and versions would be unpredictable. Imagine that each time you save a document created with your favorite text editor, the whole text editing application would be saved with the document.
I think the problem is the MD5 script verification functionality. It just does not make sense to prohibit execution of a new script version just because a single ASCII character changed.
Scripts are extremely vulnerable by nature, since the entire source code is always exposed. For example, somebody or 'something' could add a little code snippet at the beginning of a script to remove all files on the user's home directory, just to name a relatively 'innocent' possibility.
As the principal developer of the PixInsight platform, I am responsible for keeping it as secure as possible. Script checksum validation is a basic security feature to give the user an opportunity to stop a potential security risk. For example, if you know that a script has not been updated, and checksum validation fails for an existing icon, then something strange has happened and you should not trust the script. Checksum validation confers the responsibility for script execution to the user.
On the other hand, nothing prohibits or prevents execution of an existing Script instance when the script's source code has been modified. See the attached screen shot. You just have to remove the MD5 checksum on the Script tool, and no checksum validation will be performed. You can also save an icon without a checksum from the Script tool, although doing that is strongly discouraged for security reasons.
Of course, the current script security system can be improved. It will be improved in future PI versions. For example, scripts could be encrypted/decrypted automatically, or PJSR could provide resources for script authentication. However, I think the current checksum validation system is reasonably secure and does not cause too much trouble to the user.
