Re: August 2025 stabilization week

On 8/28/25 22:37, Konstantin Belousov wrote:
> On Thu, Aug 28, 2025 at 10:21:43PM -0500, Kyle Evans wrote:
>> On 8/28/25 22:07, Konstantin Belousov wrote:
>>> On Thu, Aug 28, 2025 at 06:06:54PM -0500, Kyle Evans wrote:
>>>> On 8/28/25 17:21, Olivier Cochard-Labbé wrote:
>>>>>
>>>>> On Wed, Aug 27, 2025 at 7:26 PM Olivier Cochard-Labbé <olivier@freebsd.org <mailto:olivier@freebsd.org>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>       I'm still waiting for our contributions about this stabweek before closing the week.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The "August 2025 stabilization week" is now over.
>>>>>
>>>>> This stabweek has been more challenging than usual, so please be aware of the following known issues:
>>>>>
>>>>> 1.  OpenSSL 3.5.1: The legacy provider is broken, causing some ports to fail. A temporary fix is to use `env CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1`. Cf an example of regression in PR/273656
>>>>>
>>>>> 2.  MIT Kerberos: The default Kerberos is now MIT. Clients should migrate smoothly, but some scripts may need adjusting. Machines running kdc must continue to use Heimdal by setting WITHOUT_MITKRB5="yes" in /etc/src.conf.
>>>>>
>>>>> 3.  Still empty Pkg repo today: The official package repository is currently almost empty. Don't run `make delete-old-libs` unless you're prepared to build packages from source. A bug in the current version of pkg means that running `pkg upgrade` might result in the removal of many packages due to this empty repository state.
>>>>>
>>>>> 4.  ABI Breakage: A recent ABI change in `setgroups(2)` and `getgroups(2)` syscalls will cause some packages to crash. These packages must be rebuilt.
>>>>>
>>>>
>>>> At the risk of being both repetitive and pedantic, I note once more that it's important to emphasize that they must be rebuilt
>>>> *if you are not running a kernel with COMPAT_FREEBSD14*.  The distinction is quite important because if you're not running
>>>> GENERIC or MINIMAL and you need to rebuild, ok, cool, that's the usual process.  If you're running GENERIC or MINIMAL and
>>>> you need to rebuild, I really want to hear about it because that means I broke something that wasn't supposed to break.
>>>>
>>>
>>> To be correct, this is not an ABI breakage.  Old binaries which are linked
>>> against setgroups@FBSD_1.0/SYS_freebsd14_setgroups#80, get the old behavior.
>>> The new behavior of setgroups@FBSD_1.8/SYS_setgroups#596 is what hits the
>>> old unaware code _after recompilation and linking_.
>>>
>>
>> I haven't yet seen any reports of problems after recompilation and linking, but I'm
>> interested in those as well, of course.  The reports we've seen to-date that I am
>> aware of have been from getting smacked with a SIGSYS or SIGABRT, and I suspect the
>> latter may have been something that fork()ed a child that got hit with a SIGSYS, which
>> effectively asserted in the parent when the child did not exit as expected.  We weren't
>> able to collect any debug information from the SIGABRT case to confirm, though.
>>
> 
> What we might do, which is not too late still, is something like this,
> of course not tested.  Then only the code that explicitly opts in, would
> get the new behavior after the recompilation.
> 
> I am more worried about ports and third-party compilation envs that we
> do not control, than about src/.
> 

Ports software almost universally comes from platforms that don't exhibit the same
behavior that we used to.  We could do something like this, but I'm hesitant to do
anything here until we understand if there's even a problem.  We haven't even had an
actual package set since the change happened on any platform, and we're not going to
have any idea what kind of problems lay in wait if nobody's ever actually run the
new behavior.

> diff --git a/include/unistd.h b/include/unistd.h
> index 21e3a7740607..7de52d036654 100644
> --- a/include/unistd.h
> +++ b/include/unistd.h
> @@ -571,7 +571,11 @@ int	 ruserok(const char *, int, const char *, const char *);
>   int	 select(int, fd_set *, fd_set *, fd_set *, struct timeval *);
>   #endif
>   int	 setdomainname(const char *, int);
> +#ifndef	_WANT_SEGROUPS_NO_EGID
>   int	 setgroups(int, const gid_t *);
> +#else
> +int	 setgroups(int, const gid_t *) __attribute__((__alias__("setgroups@FBSD_1.0")));
> +#endif
>   void	 sethostid(long);
>   int	 sethostname(const char *, int);
>   int	 setlogin(const char *);
> 
>>> I.e. while being perfectly ABI compatible there, we get some nuanced new
>>> behavior that is impossible to detect at the compile time.  I was assured
>>> that the advantages of this change overcome the inconvinience.
>>>
>>> not assuming egid presence is provided
>>>>> 5.  ZFS Kernel Panic: We've identified a 100% reproducible kernel panic when running ZFS regression tests. The bug has been reported on PR/289131. The FreeBSD CI ZFS tests have not been running for about a month, with the latest run also resulting in a panic too [1].
>>>>>
>>>>> Thanks for your reports,
>>>>>
>>>>> Olivier
>>>>>
>>>>> [1] https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console <https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console>
>>>>
>>>