Open DYukun opened 1 year ago
COMPRESS=true
Spilo build.Btw, what CVE are you speaking about?
Actually we are building from your release branch (2.1-p6
for now) instead of master, to make sure we can still use a stable version of spilo before we decide to put some effort on fixing potential gaps in upgrade.
pg_cron
extension requiring fix, we are not able to build any previous branch.For this particular case, we are fixing the HIGH risk CVE-2023-0286 and a bunch of other CVE with lower risk. But new risk will keep coming continuously as the new base image fixing them. So we're looking for a solution that:
if you rebuild any release branch instead of pulling the prebuilt image, it is not stable anyway (versions not pinned, it will install the latest). That is why I suggested switching to master branch. Moreover, pay attention to the fact 2.1-p6
is quite old, there are later releases.
I really don't get what you want here, sorry. Let's start from the very beginning.
pg_cron extension is not installed correctly and will cause error to cron schema.
this error is caused by a subtle change introduced in v1.5.0
pg_cron release.
inconsistency between versions when rebuild spilo
yes, as we have already discussed, version is not pinned and Spilo pulls the latest available version from pgdg repo (but you can change Spilo build scripts to build pg_cron from any commit from source if you need).
However, when patch this PR to our release branch(we use 2.1-p6 release), there will be new error like: PermissionError: [Errno 13] Permission denied: '/etc/runit/runsvdir/default/patroni' env: ‘/scripts/patroni_wait.sh’: Permission denied
this error has nothing to do with patching with this pg_cron installation fix. The problem is somewhere else. Might be fixed in the later releases, might be in the way you run Spilo...
OK let me re-summary the problem and solutions we investigated. Hopefully this help understand what tradeoff we are facing.
We have a project that depend on spilo images. When using spilo images, our container registry has vulnerability scanning to check whether there is known CVE existing in the images used. And we have requirements to fix them.
In addition, for the CVE source, our scanning system shows that mostly it comes from the ubuntu base image.
We are balance between:
Currently redo the docker build for spilo will fetch all latest dependencies including base image. Therefore the base image got updated and the CVEs in the previous versions will be fixed.
We report this issue because there is edge cases that the latestpg_cron
release is not compatible, and therefore the rebuilt image on old release version won't work anymore.
An improve version of Solution 1. When doing rebuild, it's possible to tag dependencies to stable version and only upgrade the dependencies needed to fix the CVE(mostly the base ubuntu image).
This is also suggested in #840. Is building from master branch always stable and is it recommended?
Is building from master branch always stable and is it recommended?
Not always but now it is
Got it. We will probably keep the current solution to avoid building from non-release branch, but we will try to use the official image as much as possible.
Is there a new release plan recently which can fix the CVEs? Currently p3.0-1 can't be rebuild to fix CVEs because of the incompatible issue mentioned above.
Hi spilo experts,
Context
Our project depends on spilo and has requirements on CVE vulnerability fixes. Most CVE vulnerabilities are caused because the base image has to be updated. Our original solution to deal with this is to rebuild the release branch, which will pull the newest dependencies and base image to fix this.
Problem
Recently starting from 2023 March, we found out that there is inconsistency between versions when rebuild spilo. We found that
pg_cron
extension is not installed correctly and will cause error tocron
schema. Error message is like:Solution tried
We doubt that the pg_cron dependency change cause this issue and found https://github.com/zalando/spilo/pull/863 to fix this. However, when patch this PR to our release branch(we use
2.1-p6
release), there will be new error like:And our pod will stuck in not ready state.
Question
Looking forward to your reply and suggestions. Thanks!