Skip to content
This repository has been archived by the owner on Dec 18, 2024. It is now read-only.

Fix dependency vulnerability #706

Merged
merged 1 commit into from
Nov 13, 2023
Merged

Conversation

erikbosch
Copy link
Contributor

I suggest that we remove version numbers. That should maintaining for vulnerabilities easier. The rationale is that this component is provided "as is", we do not test it and we do not release it, and there is no defined acceptance/test criteria for nailing a version (and possibly create a release).

Side note:

IF we later intend to spend more time on this app we could consider an approach like dbcfeeder, having a requirements.in where we only specify version if needed for functional reasons and compatible version ~= rather than explicit version and then generate/update requirements.txt as part of release, so that it for releases represent a known working version

I did a very basic test after the update, I did not try to set up a S3 server

erik@debian4:~/kuksa.val/kuksa_apps/s3$ python s3_uploader.py
Init parquet packer...
Init kuksa VAL server client...
connect to wss://localhost:8090
Websocket connected. Negotiated subprotocol None
Init S3 client...
Traceback (most recent call last):
  File "/home/erik/kuksa.val/kuksa_apps/s3/s3_uploader.py", line 294, in <module>

@SebastianSchildt
Copy link
Contributor

I DO think this is not clever, because next time there is a vulnerability Securty advisory will say "it can not determine" whether we are affected", this happened to JWT token generation in the past before pinning things. So I think it is better puttting a specfic version. Otherwise I agree let's not spend much effort on this particular tool at the moment

@erikbosch
Copy link
Contributor Author

I DO think this is not clever, because next time there is a vulnerability Securty advisory will say "it can not determine" whether we are affected", this happened to JWT token generation in the past before pinning things. So I think it is better puttting a specfic version. Otherwise I agree let's not spend much effort on this particular tool at the moment

OK, then I will rework to use an *.in* file

@erikbosch
Copy link
Contributor Author

@SebastianSchildt - update to use requirements.in and generated requirements.txt. Makes the dependency list longer but stricter :-)

@SebastianSchildt SebastianSchildt merged commit 876f210 into eclipse:master Nov 13, 2023
2 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants