You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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-dockeris in reality not vulnerable to any of those CVEs according to my own research (e.g. the criticalCVE-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.
The text was updated successfully, but these errors were encountered:
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 🙂
Hi
We use the current
0.12.2
version of theagentejo/cockpit-docker
image.The image is based upon the
php:7.4-apache
upstream base image.Unfortunately the
0.12.2
version (but alsolatest
) have not been built & published for over 6 months now. thephp
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
andagentejo/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:
php:7.4-apache
base image is used for the build, and publish an updated image?FROM
instruction in theDockerfile
to simplify obtaining upstream PHP/Apache version information? That would mean usingFROM php:7.4.28-apache-buster
instead of the more broadFROM php:7.4-apache
(also fixing the debian base distro version along the way)?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.
The text was updated successfully, but these errors were encountered: