Thank you very much @yeisonvargasf, that's perfect 😄

@SofyaTavrovskaya thank you! your fix was merged, because of that I closed this issue.

FAIL: test_using_valid_specifier_sets_0000__meta (main.TestData)

Traceback (most recent call last): File "C:\Users\COMP\AppData\Local\Programs\Python\Python37\lib\site-packages\parameterized\parameterized.py", line 530, in standalone_func return func(*(a + p.args), **p.kwargs) File "D:\safety-db-master\tests.py", line 28, in test_using_valid_specifier_sets self.failUnless(specifier_set, msg=message) AssertionError: None is not true : Bad specifier for $meta: 'advisory'

====================================================================== FAIL: test_using_valid_specifier_sets_0001__meta (main.TestData)

Traceback (most recent call last): File "C:\Users\COMP\AppData\Local\Programs\Python\Python37\lib\site-packages\parameterized\parameterized.py", line 530, in standalone_func return func(*(a + p.args), **p.kwargs) File "D:\safety-db-master\tests.py", line 28, in test_using_valid_specifier_sets self.failUnless(specifier_set, msg=message) AssertionError: None is not true : Bad specifier for $meta: 'timestamp'

Ran 1903 tests in 7.515s

FAILED (failures=2)

@SofyaTavrovskaya thanks for your PR, @pawamoy next version will be published on PyPi by the automatic deployment on July 1.

@nicholasks any chance you could review this again? The Travis builds are still failing. Is there another maintainer I could maybe reach out to?

Hi maintainers, could you please merge this? This is preventing Travis builds from passing, resulting in no new releases on pypi since 8 months. Users installing safety-db with pip are therefore 8 months late regarding CVEs 😕

I'm using safety-db by actually installing the package using pip. The problem is that the monthly update seems to only push commits to master, not release a new version on pypi. Would it be possible to automate such releases on pypi each months?

It's actually already the case, but tests are failing and therefore Travis does not publish the new releases. See #2324

Hi,

Version 19.10 is being incorrectly flagged as insecure. How would I approach fixing this? I'm happy to patch the DB myself, but it looks like it is auto generated by a bot - so if I made the change, would the bot undo it from wherever it gets its sources from?

Discussed in both Airflow and Gunicorn, and confirmed that 19.10 was patched:

https://github.com/apache/airflow/issues/15570 https://github.com/benoitc/gunicorn/issues/2572

The CVE also states that 19.10.0 and 20.0.1 both have the fix:

https://snyk.io/vuln/SNYK-PYTHON-GUNICORN-541164

Database: https://github.com/pyupio/safety-db/blob/master/data/insecure_full.json#L8507

Id: pyup.io-40105

Yes, you are correct. Thanks for letting us know. We have updated our database. Note that this will not reflect in our free database until June 1st, 2021.

I'm using safety-db by actually installing the package using pip. The problem is that the monthly update seems to only push commits to master, not release a new version on pypi. Would it be possible to automate such releases on pypi each months?

Hi,

Version 19.10 is being incorrectly flagged as insecure. How would I approach fixing this? I'm happy to patch the DB myself, but it looks like it is auto generated by a bot - so if I made the change, would the bot undo it from wherever it gets its sources from?

Discussed in both Airflow and Gunicorn, and confirmed that 19.10 was patched:

https://github.com/apache/airflow/issues/15570 https://github.com/benoitc/gunicorn/issues/2572

The CVE also states that 19.10.0 and 20.0.1 both have the fix:

https://snyk.io/vuln/SNYK-PYTHON-GUNICORN-541164

Database: https://github.com/pyupio/safety-db/blob/master/data/insecure_full.json#L8507

Id: pyup.io-40105

Signed-off-by: Christoph Görn goern@redhat.com

CVE-2021-25290 has now been added for Pillow by means of our usual vulnerability advisory review process.

Signed-off-by: Christoph Görn goern@redhat.com

Unsure if this is the best place to report this, but I was looking at CVE-2021-23338 and noticed from the included exploit link https://github.com/418sec/huntr/pull/1329 that it is a vulnerability for microsoft/qlib and that the corresponding pip package for that appears to be pyqlib rather than qlib

Thanks for your message, Weston.

We were unable to find a source that confirms that qlib is not vulnerable, so until then, we have marked both qlib and pyqlib as vulnerable. The latter has been assigned pyup.io-40060.

lambda-warmer-py is marked as insecure before version 1.2.0, but it's only at version 0.6.

Was the name reused, or is this just a mistake?

You are right. We had it associated with https://github.com/jeremydaly/lambda-warmer by accident. Thanks for the note.

Note that users who use our free software will not see this correction until April 1st, 2021.

You're right! Would be nice if safety itself could detect it, or have an option to enable detection.

The files are included, they just aren't referenced properly. I installed safety-db into a virtualenv and the files are at:

./venv/lib/python3.6/site-packages/safety_db/insecure_full.json.

The code expects them in a data directly below your current working directory.

lambda-warmer-py is marked as insecure before version 1.2.0, but lambda-warmer-py is only at version 0.6.

Was the name reused, or is this just a mistake?