In other news, this package is clearly unmaintained in Mageia.  It's still outdated in Cauldron even though a new version has been available in Fedora since May 30, 2014.  This looks like it should be dropped.

CC: (none) => geiger.david68210, pterjan

Yes it seems to be unmaitaned jtext source code editor needs it so it need to dropped it too.

CC: (none) => ozkyster

See the Novell bug for more info on the behavior of this issue:
https://bugzilla.suse.com/show_bug.cgi?id=916224

Testing mga4 64

tl;dr; The update doesn't appear to fix the problem, but jython does work.


From the PoC

Before
------
# ls -l '/usr/share/jython/Lib/xmllib$py.class'
ls: cannot access /usr/share/jython/Lib/xmllib$py.class: No such file or directory

# (umask 000; jython -c 'import xmllib')
...
# ls -l '/usr/share/jython/Lib/xmllib$py.class'
-rw-rw-rw- 1 root root 52885 Feb 27 14:09 /usr/share/jython/Lib/xmllib$py.class

After
-----
# rm -f '/usr/share/jython/Lib/xmllib$py.class'

# (umask 000; jython -c 'import xmllib')
...
# ls -l '/usr/share/jython/Lib/xmllib$py.class'
-rw-rw-rw- 1 root root 52885 Feb 27 14:10 /usr/share/jython/Lib/xmllib$py.class


For general testing, jython has a cli too. Examples here
http://www.jython.org/newsite_b4/archive/22/userguide.html#id54

$ jython
...
Type "copyright", "credits" or "license" for more information.
>>> from java.util import Random
>>> r = Random()
>>> r.nextInt()
1688705373
>>> for i in range(5):
...     print r.nextDouble()
... 
0.25349144641227783
0.1636200447095133
0.09421192126754419
0.7906735103319492
0.9192635240281638

Whiteboard: (none) => has_procedure feedback

Thanks.  The patches were in the SPEC but not actually applied.  Not sure how I did that.  Fixed now (freeze push requested for the same problem in Cauldron).

Updated packages in core/updates_testing:
========================
jython-2.2.1-13.2.mga4
jython-javadoc-2.2.1-13.2.mga4
jython-manual-2.2.1-13.2.mga4
jython-demo-2.2.1-13.2.mga4

from jython-2.2.1-13.2.mga4.src.rpm

Whiteboard: has_procedure feedback => has_procedure

Testing complete mga4 64

It also moves the storage location from /usr/share to the user home.

After
-----
# ls -l '/usr/share/jython/Lib/xmllib$py.class'
ls: cannot access /usr/share/jython/Lib/xmllib$py.class: No such file or directory

# (umask 000; jython -c 'import xmllib')       
*sys-package-mgr*: processing modified jar, '/usr/share/java/jython.jar'

# ls -l '/usr/share/jython/Lib/xmllib$py.class'
ls: cannot access /usr/share/jython/Lib/xmllib$py.class: No such file or directory

# ll '.jython/cachedir/classes/usr/share/jython/Lib/xmllib0$py.class' 
-rw-rw-rw- 1 root root 52885 Feb 27 16:05 .jython/cachedir/classes/usr/share/jython/Lib/xmllib$py.class


So moved to $HOME but still open perms.

# ll -d .jython/
drwxrwxrwx 3 root root 4096 Feb 27 16:05 .jython//

# ll -d .jython/cachedir/
drwxrwxrwx 4 root root 4096 Feb 27 16:05 .jython/cachedir//

# ll -d .jython/cachedir/classes/
drwxrwxrwx 3 root root 4096 Feb 27 16:05 .jython/cachedir/classes//

# ll -d .jython/cachedir/classes/usr/
drwxrwxrwx 3 root root 4096 Feb 27 16:05 .jython/cachedir/classes/usr//

# ll -d .jython/cachedir/classes/usr/share/
drwxrwxrwx 3 root root 4096 Feb 27 16:05 .jython/cachedir/classes/usr/share//

# ll -d .jython/cachedir/classes/usr/share/jython/
drwxrwxrwx 3 root root 4096 Feb 27 16:05 .jython/cachedir/classes/usr/share/jython//

# ll -d .jython/cachedir/classes/usr/share/jython/Lib/
drwxrwxrwx 2 root root 4096 Feb 27 16:05 .jython/cachedir/classes/usr/share/jython/Lib//
      
# ll .jython/cachedir/classes/usr/share/jython/Lib/
total 284
-rw-rw-rw- 1 root root  7126 Feb 27 16:05 copy_reg$py.class
-rw-rw-rw- 1 root root 28876 Feb 27 16:05 javaos$py.class
-rw-rw-rw- 1 root root 21057 Feb 27 16:05 javapath$py.class
-rw-rw-rw- 1 root root  3655 Feb 27 16:05 re$py.class
-rw-rw-rw- 1 root root 15857 Feb 27 16:05 site$py.class
-rw-rw-rw- 1 root root 22364 Feb 27 16:05 sre_compile$py.class
-rw-rw-rw- 1 root root 15480 Feb 27 16:05 sre_constants$py.class
-rw-rw-rw- 1 root root 38468 Feb 27 16:05 sre_parse$py.class
-rw-rw-rw- 1 root root 21385 Feb 27 16:05 sre$py.class
-rw-rw-rw- 1 root root  6431 Feb 27 16:05 stat$py.class
-rw-rw-rw- 1 root root 22002 Feb 27 16:05 string$py.class
-rw-rw-rw- 1 root root  9255 Feb 27 16:05 UserDict$py.class
-rw-rw-rw- 1 root root 52885 Feb 27 16:05 xmllib$py.class

Yeah the approach they made to fix the permissions was to just adjust the directory instead of the files, but the patch for that looks a bit fishy:
https://bugzilla.redhat.com/attachment.cgi?id=731250

If it doesn't restrict the permissions on ~/.jython or ~/.jython/cachedir or ~/.jython/cachedir/classes (removing "other" executable permissions would be the most effective method), then it's not a very effective solution.

I posted a comment in RedHat's bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=947949#c11

I also e-mailed the SuSE packager who did their update.

Using the PoC, the file is 644 if the directory structure is created by jython cli, the dirs themselves have 655. 

If the directory structure is created with the PoC instead then dirs are 777 and file is 666

ie. If jython cli is run first, then the PoC..

$ ll -d .jython
drwxr-xr-x 3 claire claire 4096 Feb 27 16:27 .jython/

$ ll .jython/cachedir/classes/usr/share/jython/Lib/xmllib\$py.class 
-rw-r--r-- 1 claire claire 52885 Feb 27 16:29 .jython/cachedir/classes/usr/share/jython/Lib/xmllib$py.class


If ~/.jython is not yet created when the PoC is run..

$ rm -rf .jython/
$ (umask 000; jython -c 'import xmllib')
...etc

$ ll -d .jython
drwxrwxrwx 3 claire claire 4096 Feb 27 16:41 .jython/

$ ll .jython/cachedir/classes/usr/share/jython/Lib/xmllib\$py.class 
-rw-rw-rw- 1 claire claire 52885 Feb 27 16:41 .jython/cachedir/classes/usr/share/jython/Lib/xmllib$py.class

So basically the umask is effectively being used to control the permissions of the things being created, which makes sense.  The original bug report says that it creates class files with insecure permissions if a weak umask is used, so I guess the fix is partially effective in that it respects the umask and doesn't just use 666 permissions on the class files all the time, but still doesn't address what happens with a weak umask by ensuring that the class files aren't world-writable.  I guess one could argue it should, but maybe it's debatable whether it's still a security issue now.  If you set a weak umask, maybe you deserve what you get.

Yes, seems like a partial fix.

Adding feedback marker for now

Whiteboard: has_procedure => has_procedure feedback

A response has been posted on the RedHat bug:
https://bugzilla.redhat.com/show_bug.cgi?id=947949#c12

We can go ahead and OK this.  Thanks again Claire.

Whiteboard: has_procedure feedback => has_procedure

Testing complete mga4 32

Whiteboard: has_procedure mga4-64-ok => has_procedure mga4-32-ok mga4-64-ok

Validating. Advisory uploaded with srpm from comment 5

Please push to 4 updates

Thanks

Keywords: (none) => validated_update
Whiteboard: has_procedure mga4-32-ok mga4-64-ok => has_procedure advisory mga4-32-ok mga4-64-ok
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2015-0096.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED