PyYAML, required by dparse, has vulnerability, so safety check always fails

[richleland]

• safety version: 1.8.1
• Python version: 3.6.5
• Operating System: MacOS High Sierra and CentOS Linux release 7.2.1511

Description

I'm trying to run safety check --full-report. I expect the check to pass, but it fails with a pyyaml vulnerability. Safety has a dependency on dparse, which has a dependency on pyyaml. I'm running safety against a package (no requirements.txt), so it falls back to checking installed packages via pip's API. This means that any dependencies of safety or its sub-dependencies are also checked.

What I Did

I'm running safety via tox:

$ tox -r -e scan-deps                                                               10s 649ms
GLOB sdist-make: /Users/rleland/myproject/setup.py
scan-deps recreate: /Users/rleland/myproject/.tox/scan-deps
scan-deps installdeps: safety==1.8.1
scan-deps inst: /Users/rleland/myproject/.tox/dist/myproject-1.1.3.zip
scan-deps installed: myproject==1.1.3,certifi==2018.4.16,chardet==3.0.4,click==6.7,dparse==0.4.1,idna==2.7,packaging==17.1,pyparsing==2.2.0,PyYAML==3.13,requests==2.19.1,safety==1.8.1,six==1.11.0,urllib3==1.23
scan-deps runtests: PYTHONHASHSEED='2113859831'
scan-deps runtests: commands[0] | safety check --full-report
╒══════════════════════════════════════════════════════════════════════════════╕
│                                                                              │
│                               /$$$$$$            /$$                         │
│                              /$$__  $$          | $$                         │
│           /$$$$$$$  /$$$$$$ | $$  \__//$$$$$$  /$$$$$$   /$$   /$$           │
│          /$$_____/ |____  $$| $$$$   /$$__  $$|_  $$_/  | $$  | $$           │
│         |  $$$$$$   /$$$$$$$| $$_/  | $$$$$$$$  | $$    | $$  | $$           │
│          \____  $$ /$$__  $$| $$    | $$_____/  | $$ /$$| $$  | $$           │
│          /$$$$$$$/|  $$$$$$$| $$    |  $$$$$$$  |  $$$$/|  $$$$$$$           │
│         |_______/  \_______/|__/     \_______/   \___/   \____  $$           │
│                                                          /$$  | $$           │
│                                                         |  $$$$$$/           │
│  by pyup.io                                              \______/            │
│                                                                              │
╞══════════════════════════════════════════════════════════════════════════════╡
│ REPORT                                                                       │
│ checked 16 packages, using pyup.io's DB                                      │
╞════════════════════════════╤═══════════╤══════════════════════════╤══════════╡
│ package                    │ installed │ affected                 │ ID       │
╞════════════════════════════╧═══════════╧══════════════════════════╧══════════╡
│ pyyaml                     │ 3.13      │ <4                       │ 36333    │
╞══════════════════════════════════════════════════════════════════════════════╡
│ pyyaml before 4 uses ``yaml.load`` which has been assigned CVE-2017-18342.   │
╘══════════════════════════════════════════════════════════════════════════════╛

There doesn't appear to be a non-pre-release version of PyYAML on PyPI of version 4.

There are ways for me to work around this (add ignore, create and maintain requirements alongside setup.py, etc.) but I thought it might be helpful for anyone else that runs into this. Curious what your thoughts are too around some way to check only non-dev dependencies. I really like checking whatever pip has installed, but that will always catch everything installed.

[shtratos]

see pyupio/safety-db#2271

[shtratos]

This seems to be fixed now. pipenv check passes without -i 36333 for pyyaml 3.13 installed

[Jwomers]

@shtratos @richleland yes we removed this advisory since there is no fix for now.

[ghost]

@shtratos @richleland yes we removed this advisory since there is no fix for now.

The fix in upstream has been done in >=4.1.

So why can we not keep marking <4.1 as unsafe to trigger the upstream packages?

"Let's not scream about vulnerabilities marked won't fix by maintainer" is a bad precedent for a security scanner IMHO. Especially when fix versions are available (albeit other major versions).

[EDIT]: I see now that 4.1 has been pulled or never released and they're taking their time with 4.2. So I take it, that once 4.2 has been officially released, this is being reactivated?