Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rebuild current image to get updated PHP version and avoid CVEs / security-scanning false-positives? #21

Open
sambernet opened this issue Mar 7, 2022 · 1 comment

Comments

@sambernet
Copy link

Hi

We use the current 0.12.2 version of the agentejo/cockpit-docker image.
The image is based upon the php:7.4-apache upstream base image.

Unfortunately the 0.12.2 version (but also latest) have not been built & published for over 6 months now. the php base image was using PHP version 7.4.2 when the last image build was performed:

docker run --rm -it agentejo/cockpit:0.12.2 bash -c "php -v"
PHP 7.4.2 (cli) (built: Feb  1 2020 19:39:30) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.2, Copyright (c), by Zend Technologies

Whereas the current version of the php:7.4-apache image delivers a fully-patched "old-stable" PHP version 7.4.28:

docker run --rm -it php:7.4-apache bash -c "php -v"
PHP 7.4.28 (cli) (built: Mar  3 2022 09:55:51) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

This leads to the agentejo/cockpit-docker:latest and agentejo/cockpit-docker:0.12.2 image versions being tagged as vulnerable to a range of vulnerabilities during security scanning. Some examples:

To be fair, agentejo/cockpit-docker is in reality not vulnerable to any of those CVEs according to my own research (e.g. the critical CVE-2020-7061 only affects PHP running on windows OS to start with...) - but due to the outdated and potentially vulnerable PHP 7.4.2 version being used in the image, this still raises red flags whenever any security scanning is performed on the final image or some exposure assessment is done.

Overall I am left with the following questions/wishes/suggestions:

  • Would it be possible to just perform a fresh build, making sure the updated php:7.4-apache base image is used for the build, and publish an updated image?
  • Would it maybe make sense to use more explicit upstream version tags in the FROM instruction in the Dockerfile to simplify obtaining upstream PHP/Apache version information? That would mean using FROM php:7.4.28-apache-buster instead of the more broad FROM php:7.4-apache (also fixing the debian base distro version along the way)?
  • Should this updated image be published with a new version tag, e.g. 0.12.2_1 to distinguish it from the previous, vulnerable version, or would it be favorable to override the existing tag?

I would be happy to discuss those matters with @aheinze - or whoever can help - and can of course also provide an MR if that helps.

@sambernet
Copy link
Author

We have to move forward with this on our end.

Due to lack of feedback from any contributor (@aheinze seems to be the only significant contributor, really), we will probably just proceed with a fork and publishing our own duplicate of this image.

We will also implement our own suggestions above as we see fit, as people seem to generally agree (ok, those are mostly coworkers, but not all of them 😇).

I'm still interested to get this back onto the "official image", but it's a minor nuisance and we can live with that for the time being 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant