Re: Add Dockerfile for OSS Scanner

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(at)leadboat(dot)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(at)postgresql(dot)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.