Add Dockerfile for OSS Scanner
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t254246psql -h localhost -U postgresBuilt from patchset v7 (message #7), October 19, 2026 at 11:54 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t254246_7 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t254246_7 && git checkout t254246_7Patchset v7 (message #7) is on t254246_7
On 2026-10-08, Anthropic launched its "OSS Scanner"
(https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source).
The plan is to enroll security@postgresql.org for automated notification of
vulnerabilities it finds. One of the steps is to provide a Dockerfile that
the scanner will use to get a PostgreSQL build. The attached patch adds one
to postgresql.git. It mimics CI.
If using the test recipe in the header comment, change "git clone
https://github.com/anthropics/oss-scanner/" to "git clone -b enroll-postgresql
https://github.com/nmisch/oss-scanner/". That's a temporary need until
enrollment completes.
On Fri, Oct 16, 2026 at 11:22 PM Noah Misch <noah@leadboat.com> wrote:
On 2026-10-08, Anthropic launched its "OSS Scanner"
(https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source).
The plan is to enroll security@postgresql.org for automated notification of
vulnerabilities it finds. One of the steps is to provide a Dockerfile that
the scanner will use to get a PostgreSQL build. The attached patch adds one
to postgresql.git. It mimics CI.
I tried v1 on master (6a2edf2a1e6) using the recipe in the header
comment and the enroll-postgresql branch. tools/check built it in
about seven minutes on my 16-core box.
I ran the full suite inside the finished image, without network access,
as the postgres user:
Ok: 402 Skipped: 24 Fail: 3
The three failures were test_aio 001_aio, 003_initdb, and
004_read_stream, all reporting:
FATAL: could not setup io_uring queue: Operation not permitted
Docker's default seccomp profile blocks io_uring. With liburing-dev
installed, meson enables io_uring support, but the tests fail when they
attempt to use it.
I removed liburing-dev and added -Dliburing=disabled. All four test_aio
tests then passed, and the full suite was clean:
Ok: 405 Skipped: 24 Fail: 0
Attached v2 also puts the packages one per line, sorted, to minimize
future diffs.
I thought about adding this to pg-ci.yml too, but it'd be mostly the
same as linux-meson-64. If we want a check, maybe a separate workflow
job limited to src/tools/oss-scanner changes. And I think it sends out
it failures too so you'll get notified regardless.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
On Sat, Oct 17, 2026 at 10:22:27AM -0400, Sehrope Sarkuni wrote:
On Fri, Oct 16, 2026 at 11:22 PM Noah Misch <noah@leadboat.com> wrote:
On 2026-10-08, Anthropic launched its "OSS Scanner"
(https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source).
The plan is to enroll security@postgresql.org for automated notification of
vulnerabilities it finds. One of the steps is to provide a Dockerfile that
the scanner will use to get a PostgreSQL build. The attached patch adds one
to postgresql.git. It mimics CI.I tried v1 on master (6a2edf2a1e6) using the recipe in the header
comment and the enroll-postgresql branch. tools/check built it in
about seven minutes on my 16-core box.I ran the full suite inside the finished image, without network access,
as the postgres user:
Thanks.
Ok: 402 Skipped: 24 Fail: 3
The three failures were test_aio 001_aio, 003_initdb, and
004_read_stream, all reporting:FATAL: could not setup io_uring queue: Operation not permitted
Docker's default seccomp profile blocks io_uring. With liburing-dev
installed, meson enables io_uring support, but the tests fail when they
attempt to use it.I removed liburing-dev and added -Dliburing=disabled. All four test_aio
tests then passed, and the full suite was clean:
I am more inclined to add a comment:
# The tests that try each of TestAio::supported_io_methods() would fail if
# run, since oss-scanner seccomp blocks io_uring. Speculate that having the
# io_uring code in the binary, visible to the scanner's other analyses, is
# more valuable than having those tests pass. If the scanner execution
# environment relaxes restrictions, this build will be ready.
Ok: 405 Skipped: 24 Fail: 0
Attached v2 also puts the packages one per line, sorted, to minimize
future diffs.
I agree with one-per-line. For order, I'm more inclined to match the order in
https://github.com/anarazel/pg-vm-images/blob/main/scripts/linux_debian_install_deps.sh
since the goal is to keep them in sync. Is that okay? v1 was closer to that,
though it deviated.
I thought about adding this to pg-ci.yml too, but it'd be mostly the
same as linux-meson-64. If we want a check, maybe a separate workflow
job limited to src/tools/oss-scanner changes. And I think it sends out
it failures too so you'll get notified regardless.
Agreed, oss-scanner failure reports should suffice to start.
Hi,
On Sat, 17 Oct 2026 at 19:52, Sehrope Sarkuni <sehrope@jackdb.com> wrote:
On Fri, Oct 16, 2026 at 11:22 PM Noah Misch <noah@leadboat.com> wrote:
On 2026-10-08, Anthropic launched its "OSS Scanner"
(https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source).
The plan is to enroll security@postgresql.org for automated notification of
vulnerabilities it finds. One of the steps is to provide a Dockerfile that
the scanner will use to get a PostgreSQL build. The attached patch adds one
to postgresql.git. It mimics CI.I tried v1 on master (6a2edf2a1e6) using the recipe in the header
comment and the enroll-postgresql branch. tools/check built it in
about seven minutes on my 16-core box.I ran the full suite inside the finished image, without network access,
as the postgres user:Ok: 402 Skipped: 24 Fail: 3
The three failures were test_aio 001_aio, 003_initdb, and
004_read_stream, all reporting:FATAL: could not setup io_uring queue: Operation not permitted
Docker's default seccomp profile blocks io_uring. With liburing-dev
installed, meson enables io_uring support, but the tests fail when they
attempt to use it.I removed liburing-dev and added -Dliburing=disabled. All four test_aio
tests then passed, and the full suite was clean:
Wouldn't removing liburing-dev / setting -Dliburing=disabled also stop
building the io_uring code completely? Since the goal here is to give
the scanner a build with as many optional features as practical,
keeping liburing compiled in seems preferable even if those 3 test_aio
tests cannot run under container seccomp...
If at all there might arise a need for it to trigger all tests in docker
build, we can control io_uring tests with adding something like:
if $ENV{PG_TEST_SKIP_IO_URING} eq 'yes'
Regards,
Ayush
Hi,
On Sat, 17 Oct 2026 at 21:06, Noah Misch <noah@leadboat.com> wrote:
On Sat, Oct 17, 2026 at 10:22:27AM -0400, Sehrope Sarkuni wrote:
On Fri, Oct 16, 2026 at 11:22 PM Noah Misch <noah@leadboat.com> wrote:
On 2026-10-08, Anthropic launched its "OSS Scanner"
(https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source).
The plan is to enroll security@postgresql.org for automated notification of
vulnerabilities it finds. One of the steps is to provide a Dockerfile that
the scanner will use to get a PostgreSQL build. The attached patch adds one
to postgresql.git. It mimics CI.I tried v1 on master (6a2edf2a1e6) using the recipe in the header
comment and the enroll-postgresql branch. tools/check built it in
about seven minutes on my 16-core box.I ran the full suite inside the finished image, without network access,
as the postgres user:Thanks.
Ok: 402 Skipped: 24 Fail: 3
The three failures were test_aio 001_aio, 003_initdb, and
004_read_stream, all reporting:FATAL: could not setup io_uring queue: Operation not permitted
Docker's default seccomp profile blocks io_uring. With liburing-dev
installed, meson enables io_uring support, but the tests fail when they
attempt to use it.I removed liburing-dev and added -Dliburing=disabled. All four test_aio
tests then passed, and the full suite was clean:I am more inclined to add a comment:
# The tests that try each of TestAio::supported_io_methods() would fail if
# run, since oss-scanner seccomp blocks io_uring. Speculate that having the
# io_uring code in the binary, visible to the scanner's other analyses, is
# more valuable than having those tests pass. If the scanner execution
# environment relaxes restrictions, this build will be ready.
Could we add docker default seccomp block io_uring instead of
oss-scaner does? Else it seems like our file limitation.
Ok: 405 Skipped: 24 Fail: 0
Attached v2 also puts the packages one per line, sorted, to minimize
future diffs.I agree with one-per-line. For order, I'm more inclined to match the order in
https://github.com/anarazel/pg-vm-images/blob/main/scripts/linux_debian_install_deps.sh
since the goal is to keep them in sync. Is that okay? v1 was closer to that,
though it deviated.I thought about adding this to pg-ci.yml too, but it'd be mostly the
same as linux-meson-64. If we want a check, maybe a separate workflow
job limited to src/tools/oss-scanner changes. And I think it sends out
it failures too so you'll get notified regardless.Agreed, oss-scanner failure reports should suffice to start.
+1 on that.
There's a tiny typo present in both patches:
"opts to runs" -> "opts to run".
Apart from that and the above comment, the file looks good to me.
Regards,
Ayush
Hi,
On 2026-10-16 20:22:15 -0700, Noah Misch wrote:
On 2026-10-08, Anthropic launched its "OSS Scanner"
(https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source).
The plan is to enroll security@postgresql.org for automated notification of
vulnerabilities it finds. One of the steps is to provide a Dockerfile that
the scanner will use to get a PostgreSQL build. The attached patch adds one
to postgresql.git. It mimics CI.
Can't we just use the actual container used for CI for that? I don't think
it's good to have multiple almost equivalent recipes for testing postgres in
different forms.
Greetings,
Andres Freund
On Sat, Oct 17, 2026 at 11:58:20AM -0400, Andres Freund wrote:
On 2026-10-16 20:22:15 -0700, Noah Misch wrote:
On 2026-10-08, Anthropic launched its "OSS Scanner"
(https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source).
The plan is to enroll security@postgresql.org for automated notification of
vulnerabilities it finds. One of the steps is to provide a Dockerfile that
the scanner will use to get a PostgreSQL build. The attached patch adds one
to postgresql.git. It mimics CI.Can't we just use the actual container used for CI for that?
I had not realized it was that easy. Attached.
On Sat, Oct 17, 2026 at 09:16:58PM +0530, Ayush Tiwari wrote:
On Sat, 17 Oct 2026 at 21:06, Noah Misch <noah@leadboat.com> wrote:
# The tests that try each of TestAio::supported_io_methods() would fail if
# run, since oss-scanner seccomp blocks io_uring. Speculate that having the
# io_uring code in the binary, visible to the scanner's other analyses, is
# more valuable than having those tests pass. If the scanner execution
# environment relaxes restrictions, this build will be ready.Could we add docker default seccomp block io_uring instead of
oss-scaner does? Else it seems like our file limitation.
No, I think the comment more accurately describes the separation of concerns.
oss-scanner chooses how to configure docker. It currently chooses a way that
includes this seccomp restriction, and it could choose differently. Whether
that's an explicit choice or a docker default, the part PostgreSQL controls
experiences it the same way.
There's a tiny typo present in both patches:
"opts to runs" -> "opts to run".
Fixed. Thanks.
On Sat, Oct 17, 2026 at 12:39 PM Noah Misch <noah@leadboat.com> wrote:
On Sat, Oct 17, 2026 at 11:58:20AM -0400, Andres Freund wrote:
Can't we just use the actual container used for CI for that?
I had not realized it was that easy. Attached.
Yes, using that CI image is nicer.
v2 builds with tools/check fine for me on the same box with the
expected aio test failures.
I did have one random other failure but it's not really the image.
From subscription/023_twophase_stream:
2026-10-17 17:44:48.950 UTC startup[49516] FATAL: could not
resize shared memory segment "/PostgreSQL.3189924516" to 1048576
bytes: No space left on device
Docker's default /dev/shm is 64 MB which ends up being too small for
meson's default parallelism (nproc, so 16 on my test box). Running it
with --shm-size=1g or default size with MESON_TESTTHREADS=4 fixes it.
I think this is the type of thing an agent like Claude would figure out
automatically and retry. But might want to add it to a comment so it
knows about it in advance.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
On Sat, Oct 17, 2026 at 02:09:55PM -0400, Sehrope Sarkuni wrote:
v2 builds with tools/check fine for me on the same box with the
expected aio test failures.I did have one random other failure but it's not really the image.
From subscription/023_twophase_stream:2026-10-17 17:44:48.950 UTC startup[49516] FATAL: could not
resize shared memory segment "/PostgreSQL.3189924516" to 1048576
bytes: No space left on deviceDocker's default /dev/shm is 64 MB which ends up being too small for
meson's default parallelism (nproc, so 16 on my test box). Running it
with --shm-size=1g or default size with MESON_TESTTHREADS=4 fixes it.I think this is the type of thing an agent like Claude would figure out
automatically and retry. But might want to add it to a comment so it
knows about it in advance.
Thanks for testing. I decided not to add the /dev/shm note. This dockerfile
is not for running tests, so I'd rather not accumulate test troubleshooting
advice here. Pushed as ddd468c.