Add pyyaml < 4 for CVE-2017-18342

[alex]

The default insecurity of yaml.load has been assigned CVE-2017-18342. This is resolved in PyYAML >= 4

[alefhsousa]

Hey @alex I checked the official website https://pyyaml.org/wiki/PyYAML, in the site the current version is 3.13. The pyup is broken my PR because for him exists a vulnerability in this version of the library. I think this pr is referencing the library: https://pypi.org/project/pyaml/#history is right?

[alex]

Sigh, I don't know what the right way to handle this was. There was a release, pyyaml 4.1, resolving this CVE. Then the maintainers decided to withdraw it (you can see the discussion on github for the background). There has not yet been a new release that fixes this issue.

…

On Tue, Jul 17, 2018 at 11:20 AM Alefh Sousa ***@***.***> wrote: Hey @alex <https://github.com/alex> I checked the official website https://pyyaml.org/wiki/PyYAML, in the site the current version is 3.13. The pyup is broken my PR because for him exists a vulnerability in this version of the library. I think this pr is referencing the library: https://pypi.org/project/pyaml/#history is right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2271 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAADBH6SQhAfpqQKc3RQqDuaTMoakLXcks5uHg7OgaJpZM4U5lBz> .

-- All that is necessary for evil to succeed is for good people to do nothing.

[Jwomers]

@alex @alefhsousa Justin from PyUp here. We are monitoring this. It looks like PyYAML version 4.1 exists in their repository (see https://github.com/yaml/pyyaml/blob/master/setup.py ), but has not been published to PyPi ( https://pypi.org/project/PyYAML/ )

[alex]

FWIW, it _was_ published to PyPI, and then was retracted.

…

On Tue, Jul 17, 2018 at 2:50 PM Justin Womersley ***@***.***> wrote: @alex <https://github.com/alex> @alefhsousa <https://github.com/alefhsousa> Justin from PyUp here. We are monitoring this. It looks like PyYAML version 4.1 exists in their repository (see https://github.com/yaml/pyyaml/blob/master/setup.py ), but has not been published to PyPi ( https://pypi.org/project/PyYAML/ ) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2271 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAADBFOv7Pj5p8r6Uhrk0X7agYecmHRKks5uHj_ogaJpZM4U5lBz> .

-- All that is necessary for evil to succeed is for good people to do nothing.

[Jwomers]

@alex got it. Looking through their releases, it looks like 3.13 might actually fix the issue. I have opened an issue on PyYAML GitHub to ask for clarification.

[Jwomers]

Update here, 3.13 does not fix the issue, read more here - they are advising that 4.2 (next release) has high hopes of fixing the issue. The vulnerability is now in the PyUp proprietary safety database and will get added to safety-db in the next monthly update. So no fix for now :(

[acaprari]

Hi, unfortunately PyYAML is a dependency of many libraries (awscli and moto just to mention some) and as such it gets included implicitly in many projects. Also, the fix for the CVE hasn't reached consensum yet (see yaml/pyyaml#189) and it's not known whether the next 4.2 release would include it.

For the build of our components we had to choose between disabling dependency checks as a whole or having all the builds failing.

I understand this is an unfortunate situation, but what's the best solution for this kind of thing? Is it possible to have the CVE advisory ignored and excluded from the safety DB until an actual fix gets released?

[Jwomers]

@acaprari Great question, we are debating this internally. We should have an answer today, likely we'll remove the advisory from Safety DB for the time being.

[timofurrer]

@acaprari Great question, we are debating this internally. We should have an answer today, likely we'll remove the advisory from Safety DB for the time being.

@Jwomers did you come to any conclusions? Seems like it's still treated as vulnerability?

[Jwomers]

@timofurrer we've removed this is an advisory for now since there is no fix.