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. > 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.
