Message12996

It seems I have a choice forming the JAR to round up or down. Let's choose down, so that the source via the JAR not older than the mtime in the $py.class.
If I log this difference, it does indeed seem to be spread from 0 to 2000 ms:

runpy$py.class time is 1,161 ms later than source
imp$py.class time is 1,599 ms later than source
os$py.class time is 1,755 ms later than source
ntpath$py.class time is 958 ms later than source
stat$py.class time is 1,271 ms later than source
genericpath$py.class time is 83 ms later than source
warnings$py.class time is 677 ms later than source
linecache$py.class time is 849 ms later than source
types$py.class time is 661 ms later than source
UserDict$py.class time is 1,864 ms later than source
_abcoll$py.class time is 1,255 ms later than source
abc$py.class time is 1,911 ms later than source
_weakrefset$py.class time is 1,317 ms later than source
jythonlib$py.class time is 1,661 ms later than source
pkgutil$py.class time is 1,786 ms later than source
ensurepip\__init__$py.class time is 1,552 ms later than source
__future__$py.class time is 1,880 ms later than source
shutil$py.class time is 1,208 ms later than source
fnmatch$py.class time is 36 ms later than source
...

Tolerating this, we should be able to avoid the recompilation that affects the permissions, without reverting the fix of the CVE.

A dry run on Linux confirms this, and I installed as root (with sudo) and can run it (sort of) as an ordinary user.

pip and setuptools installed by ensurepip, which surely involves some compilation, do not result in private files, so probably the installation of packages takes care of permissions.

The fault now is that Jython is trying to place the JAR cache in the installation directory.