Re: git: e03ed9daeb49 - main - fts: refactor to use fd-relative operations internally

From: Bryan Drewery <bdrewery_at_FreeBSD.org>
Date: Wed, 24 Jun 2026 16:49:37 UTC
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 <bdrewery@freebsd.org> 
>> 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 <bhatijitendra2022@gmail.com>
>>>> AuthorDate: 2026-06-12 17:07:55 +0000
>>>> Commit:     Alan Somers <asomers@FreeBSD.org>
>>>> 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.