Re: Add Dockerfile for OSS Scanner

Hi,

On Sat, 17 Oct 2026 at 21:06, Noah Misch <noah(at)leadboat(dot)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(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.

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