On Wed, Jun 24, 2026 at 10:49 AM Bryan Drewery <[email protected]> wrote: > > On 6/24/26 9:45 AM, Bryan Drewery wrote: > > On 6/24/26 9:33 AM, Alan Somers wrote: > >> On Wed, Jun 24, 2026 at 10:04 AM Bryan Drewery <[email protected]> > >> wrote: > >>> On 6/23/26 7:54 AM, Alan Somers wrote: > >>>> The branch main has been updated by asomers: > >>>> > >>>> URL: > >>>> https://cgit.FreeBSD.org/src/commit/?id=e03ed9daeb49fffa1d16b8d00240c65e92650d01 > >>>> > >>>> commit e03ed9daeb49fffa1d16b8d00240c65e92650d01 > >>>> Author: Jitendra Bhati <[email protected]> > >>>> AuthorDate: 2026-06-12 17:07:55 +0000 > >>>> Commit: Alan Somers <[email protected]> > >>>> CommitDate: 2026-06-23 14:53:56 +0000 > >>>> > >>>> fts: refactor to use fd-relative operations internally > >>>> > >>>> Replace all _open() calls with _openat() in __fts_open(), > >>>> fts_read(), > >>>> and fts_children(). > >>>> > >>>> Add fts_dirfd to FTSENT. Callers can use > >>>> openat(ent->fts_dirfd, ent->fts_name, ...) to access files > >>>> safely without relying on fts_accpath, which enables: > >>>> > >>>> 1. Capsicum capability mode where path-based operations fail > >>>> 2. Security-sensitive programs that avoid TOCTOU races > >>>> > >>>> Replace statfs(ent->fts_path) with _fstatfs(ent->fts_dirfd) in > >>>> fts_ufslinks() when fts_dirfd is valid, falling back to > >>>> statfs() for > >>>> root-level entries where fts_dirfd is -1 > >>>> > >>>> This is a preparatory change for fts_openat() which will allow > >>>> callers to provide a pre-opened directory fd, enabling fts(3) > >>>> traversal inside Capsicum capability mode. > >>>> > >>>> Sponsored by: Google LLC (GSoC 2026) > >>>> Reviewed by: asomers, jillest > >>>> MFC after: 2 weeks > >>>> Pull Request: https://github.com/freebsd/freebsd-src/pull/2278 > >>> Someone on IRC reported they bisected a Poudriere breakage to this > >>> commit. > >> Really? I'd be interested to see that log. Also, Jitendra is already > >> working on the fix. > >> > > I asked for more details but haven't heard back yet. It is probably > > because Poudriere ships static binaries so is hitting the ABI break. > > > > > Sorry for the spam. I misremembered, it's not static but they are > pre-compiled dynamic binaries expecting libc to match the headers built > with.
Ok, I've reverted it for now. Sorry for the breakage.
