Update SSSD, move to portage-stable

[krnowak]

CI: http://jenkins.infra.kinvolk.io:8080/job/container/job/packages_all_arches/5083/cldsv/

Closes flatcar/Flatcar#1489

--

• sys-auth/sssd: [PROD] [DEV]

  • from 2.3.1-r6 to 2.9.5
  • EAPI 8
  • fixes CVE-2023-3758
    • update: sssd Flatcar#1489
  • dropped most of our modifications, the ones that are still needed are moved to config overrides or user patches
    • systemd sssd.service is replaced by upstream, but it has similar modifications to what we have done
    • tmpfiles config file is gone - it only had entries for /etc and /var
      • /etc entries are not needed - we now have /etc as an overlay
        • the only thing needed was to have a default config made from an example config, and it's done in config overrides
      • /var entries are not needed - they are generated during image build
    • stop modifying dependencies
      • pulls in net-dns/bind-tools instead of net-dns/bind…
      • enabled gssapi on net-dns/bind-tools (used to have issues on arm64)
      • enabled winbind in net-fs/samba (no idea why it was dropped before)
    • retained modifications:
      • pam config moved from /etc to /usr (config override)
      • create a default sssd config in /etc (config override)
      • cross-compilation fix for a broken openldap check (user patch)
      • enable nss lookups with sss plugin even if sssd is not running (user patch)
  • dropped USE=+locator, enabled unconditionally
  • dropped USE=pac, folded into USE=samba
  • dropped USE=valgrind
  • added USE=subid, something to do with subuid and subgid allocation, disabled
  • added USE=systemtap, for enabling instrumentation, disabled
  • replaced a dependency on dev-libs/libpcre with dev-libs/libpcre2
    • this makes dev-libs/libpcre unused
  • dropped a dependency on net-libs/http-parser
    • this makes net-libs/http-parser unused
  • added required USE=experimental on net-nds/openldap

• net-dns/bind-tools:

  • added back, dependency of sys-auth/sssd
    • it's temporary, the package is deprecated, so it will be eventually replaced with net-dns/bind

• net-nds/openldap:

  • enabled USE=experimental, required by sys-auth/sssd

• net-fs/samba:

  • enabled USE=winbind, required by sys-auth/sssd

• profiles:

  • dropped unused oem-aci profiles

--

• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
• Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

[krnowak]

First CI run succeeded, but I kicked off another one, since I added another user-patch and dropped two now-unused packages.

[github-actions]

Build action triggered: https://github.com/flatcar/scripts/actions/runs/12141170502

[chewi]

Wouldn't it be better to just keep this instead of adding the patch? Or if you're confident about this check being redundant, I could just add this line to Gentoo.

[krnowak]

I wanted to switch it to "yes", because our version of OpenLDAP has the lc_arg member in struct ldap_conncb and using it seems to allow SSSD to track some referrals or something (in general this seems to be preferred). But the "yes" case has a runtime check for a bug that was fixed 16 years ago. And we know that runtime checks and cross-compilation do go along.

I think that long-term my preferences would be in this order:

1. Upstream to drop the runtime check, just like my user-patch is doing.
2. Upstream adding a --enable-ldap-conncb-i-know-what-i-am-doing flag that skips the runtime check.
3. Gentoo taking my patch.

[chewi]

Ah, I had it backwards. In that case, a better option may be to populate the 4th AC_RUN_IFELSE argument, which is currently [], to simply assume HAVE_LDAP_CONNCB=1 when cross-compiling. This seems like a reasonable compromise given how old that release is now. Upstream may be more willing to do that than drop the check entirely.

[krnowak]

I have filed a PR to SSSD, let's see how it goes - SSSD/sssd#7743

[chewi]

You can wait on the outcome of our sssd patch discussion, but this is fine as-is in any case.