Update Postgres 16.2 -> 16.4

[dandelany]

Upgrading Postgres from 16.2 to 16.4, since 16.2 has known security issues that flag our vulnerability scanner. Submitting a PR as a draft for now to see if it breaks any CI tests & if it fixes the "scan" step of the Publish workflow.

Per Postgres Docs I think this should be a safe change that does not require dump/restore or any other instructions/considerations, but let me know if you have any concerns with this, @Mythicaeda

[skovati]

The issue isn't really with postgres, but rather than the debian version (bookworm) that the postgres image is based on includes Go v1.18.2 (since the image installs a small util called gosu), which has a few critical CVEs.

These are basically false positives as far as I understand.

See also: https://github.com/docker-library/postgres/issues/1223

It doesn't look like this small util cuts releases often, so we might have this failing check for a while. We can suppress these few CVEs if desired.

All that being said, we should definitely keep up with postgres patch releases.

[dandelany]

Thanks for the context @skovati - I know the issue(s) are in a deeper layer of the Debian stack but I was hoping the official postgres 16.4 image would also include updates to these underlying dependencies...

• I was hoping to use the checks on this PR to determine if that was true, however I realized the scan workflow is hardcoded to scan the develop aerie images. I've temporarily changed it & hardcoded it to scan the pr-1543 tag (ie. the one published by this repo) to "preview" the results but will need to change this back before merging. Maybe we can make this dynamically use the correct tag for the PR when available? I haven't thought about it too hard.
• The failing scan on develop had two vulnerabilities - one with Debian krb5 (Kerberos) dependency and one with gobinary. In the new scan, the gobinary issue is still present but the Debian/krb5 one appears to be fixed, so I think this is probably still worth merging (see scan output screenshots below)
• I'm still trying to understand the gosu/gobinary thing and confirm whether it is the same as the issue you linked. It feels like we should have some way to define/ignore false positives in our scan - it's annoying to have it failing all the time...

[dandelany]

Thanks @Mythicaeda -

• Seems like this is a good change, so I've reverted hardcoding pr-1543 back to develop in publish.yml, squashed, rebased, & will merge when tests pass.
• After some more research I'm convinced the gobinary/gosu issues are indeed false positives, and I think I have a lead on how to ignore them in the scan, but will do that in a separate PR so as not to muddy the waters.