Hi, On Sat, 17 Oct 2026 at 21:06, Noah Misch <[email protected]> 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 <[email protected]> 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 [email protected] 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
