Assigning to the Python stack maintainer, CC'ing the registered maintainer.

Assignee: bugsquad => python
CC: (none) => makowski.mageia, marja11

I proposed a 4.1 version in cauldron. It would be great that more savy python packagers look at it and check it doesn't break compatibility. Seems the only end packages using it are crmsh and unknown-horizons

CC: (none) => bruno
Status: NEW => ASSIGNED

Fixed again upstream in 5.1, Fedora advisory from March 29:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/JEX7IPV5P2QJITAMA5Z63GQCZA5I6NVZ/

We should upgrade it again, as 4.1 was pulled by upstream for causing problems.

Status comment: (none) => Fixed upstream in 5.1
Version: 6 => Cauldron
Whiteboard: (none) => MGA6TOO
Severity: normal => major

cauldron updated with 5.1
What is the recommendation for mga6 ? It wasn't update with 4.1.

Version: Cauldron => 6
Whiteboard: MGA6TOO => (none)

It sounds like the API changes made 4.1 unsafe but 5.1 should be safer.  As long as it doesn't break anything that uses it, we can update it.  It sounds like it'll be OK.

5.1 Update pushed for mga6 as well then.

Assignee: python => qa-bugs

Bruno, you incorrectly added a subrel (never do that when updating to a new version), so now you need to rebuild in Cauldron.

Advisory:
========================

Updated python-yaml package fixes security vulnerability:

It was found that using yaml.load() API on untrusted input could lead to
arbitrary code execution (CVE-2017-18342).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18342
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/JEX7IPV5P2QJITAMA5Z63GQCZA5I6NVZ/
========================

Updated packages in core/updates_testing:
========================
python-yaml-5.1-1.1.mga6
python3-yaml-5.1-1.1.mga6

from python-yaml-5.1-1.1.mga6.src.rpm

Sorry, I'm always hesitating wtr subrel when the release is the same :-( Will update cauldron immediately.

Created attachment 10897 [details]
Loading and printing an instance of a class converted to YAML format

Should work with python and python3.

CC: (none) => tarazed25

Created attachment 10898 [details]
Series of tests from online tutorial

To be run with python and python3.
The failure in the last test needs to be explained before the packages can be moved on.

mga6, x86_64

Nothing useful found for CVE-2017-18342

UPDATED the two packages.
A big jump, from 3.10-13.

Found a tutorial at https://pyyaml.org/wiki/PyYAMLDocumentation.
Several of the example snippets failed and I could not get in-string encoding
declarations to work.  In particular a document string containing several documents, specified by a name: key, throws this error, e.g.:
yaml.scanner.ScannerError: mapping values are not allowed here
  in "<string>", line 3, column 9:
        name: The Set of Gauntlets 'Pauraegen'
            ^
Using the load function is flagged as unsafe so switching to safe_load is recommended,
otherwise the loader needs to be specified, but how?  (See later)

With safe_load:
$ python tutorial2.py
['Hesperiidae', 'Papilionidae', 'Apatelodidae', 'Epiplemidae']
{'none': [None, None], 'bool': [True, False, True, False], 'int': 42, 'dict': {'hp': 13, 'sp': 5}, 'float': 3.14159, 'list': ['LITE', 'RES_ACID', 'SUS_DEXT']}

I could not get in-string encoding declarations to work either, possibly because of uncertainty about syntax.

$ cat tutorial3.py
----------------------------------------
import yaml

class Hero:
        def __init__(self, name, hp, sp):
            self.name = name
            self.hp = hp
            self.sp = sp
        def __repr__(self):
            return "%s(name=%r, hp=%r, sp=%r)" % (
                self.__class__.__name__, self.name, self.hp, self.sp)

objecttest = yaml.load("""
    !!python/object:__main__.Hero
    name: Welthyr Syxgon
    hp: 1200
    sp: 0
    """)

print objecttest
----------------------------------------

$ python tutorial3.py
tutorial3.py:17: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
  """)
Hero(name='Welthyr Syxgon', hp=1200, sp=0)

In that test I had to revert to load because with safe_load the example failed.
At a guess, the unsafe loader had caused  problems with the retrieval of the object for
printing which might have been overcome by a Loader= declaration somewhere in the
script.  Don't know how to do that.  Maybe a python expert could advise?
The link suggested states that safe_load handles only a subset of YAML, which explains the failures seen here.
Further reading:
yaml.load(input, Loader=yaml.FullLoader) loads the full YAML language.
The FullLoader cannot be enabled by default because that would annul the safety policy.

Backtracking and editing the scripts:

Several of the examples from the online tutorial have been condensed into the attached
script, yamltests.py.  Just run
$ python yamltests.py
to view the results.  yaml3tests.py should work with python3 also.
Note the failure in the last test.
Running interactive python with the same input as the tutorial shows for the Monster
class raises the same error that the script test produces, namely "mapping values are
not allowed here" which comes from yaml.scanner.

I have very little knowledge of python so cannot interpret this.  Appealing toexperts to
examine the syntax.  Otherwise the conclusion is that the package is broken.

Probably the most useful way to test this is through other packages that require it.

Yes, I guess I should do that, but it would still be reassuring to see an explanation of the error.

Have to wait until tomorrow now.  been working on this all day, literally.

Several applications use these packages including ansible and rednotebook.
Chose to install and test rednotebook under strace.  Created a diary and wrote the first page.  The trace showed many opens for python yaml related libraries and operations including loading and serializing.  That seems to demonstrate that python-yaml is being used successfully.

Passing this for 64-bits but shall probably raise a bug on the failure of the tutorial example.

Whiteboard: (none) => MGA6-64-OK

Tested in 32-bit for installation issues only. Looks OK. Validating. Suggested advisory in Comment 7.

Whiteboard: MGA6-64-OK => MGA6-64-OK MGA6-32-OK
Keywords: (none) => validated_update
CC: (none) => andrewsfarm, sysadmin-bugs

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

https://advisories.mageia.org/MGASA-2019-0125.html

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