Removed null encryption key vulnerability #196
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello! I really like this repo, managing S3 data like pathlib Path's is awesome. I'd like to use your s3path in an internal project. However, a security scan by Fortify revealed this one "vulnerability" so I wanted to contribute to its removal, so our security guys will be happy.
This is what the Fortify had to say about the offending line
access_key = secret_key = token = None:I will say, to get to this part in the code, you need to have python<3.12 and smart-open<5.1.0. The latter requirement is already blocked by your setup.py requirements, so if you're okay with more formally removing support for smart-open<5.1.0 (forcibly installing smart-open==5.0.0 causes 1 pytest failure on python 3.10 (
test_open_method_with_custom_endpoint_url - AssertionError: assert 'https://s3.amazonaws.com' == 'http://localhost') and 21 on python 3.12 (all areTypeError: open() got an unexpected keyword argument 'compression')) I'm down to make an alternative PR removing this code support for <5.1.0 entirely. However, this proposed change maintains the exact same functionality as before.I've ran the pytests with these changes and no extra errors occur asides from those inherent to smart-open==5.0.0 as mentioned. Other than with your moto tests not requiring credentials, I've otherwise tested on a bucket requiring credentials, and seen that you will get the same authentication error, whether 'aws_secret_access_key' etc. is to None (current), or not provided at all (this proposed change).