Open egeucak opened 1 year ago
This seems reasonable. There's a trade-off to make here between providing the cpython distribution as close as possible to a typical installation (e.g. apt install python3
on Ubuntu) vs taking explicit decisions to remove aspects of the installation that have no value and might have negative value - like the .pem
files you mention.
I think it's worth us investigating this removal of the site-packages/**/tests/
directories. If this process doesn't break any of our test suites then I agree on balance it's probably worth us doing it.
Hello all,
In cpython repository, there are some
.pem
files they use for tests. But when these keys end up in the image, our vulnerability scanner is not very happy. Currently, we whitelist this Private key issue, but that is not a good solution because obviously if a user accidentally puts in private keys, the pipeline will still pass.Expected Behavior
There shouldn't be any kind of private keys in the final image. Ideally, the test code shouldn't end up in the image either.
Current Behavior
Cpython repository is served in the image as is.
Possible Solution
In our non-buildpack docker images that use python, we do
RUN rm -rf /usr/local/lib/python3.10/site-packages/**/tests/
for removing tests and all the private keys with it. An addition to this buildpack that removes these folders will be great.Steps to Reproduce
find /layers/paketo-buildpacks_cpython/ -name *.pem
Motivations
We are using buildpacks for creating images to be used by data scientists. And we also have vulnerability pipelines in place. This pipeline raises error because of these private keys. We also don't want to whitelist this if we can fix it. As an option, we can create a new buildpack to apply some compliancy fixes but fixing the root cause is better.