Bug 2317851

Bug fixes are available upstream

So I googled and a VLV is apparently a "virtual list view". Okay. That doesn't help.

What's one of those? What is its relevance to FreeIPA? What kind of a FreeIPA deployment "requires support of VLV control"? What's the consequence of VLV control being broken?

These are the sorts of things we need to know in order to evaluate whether this is a release blocker. Thanks!

Let me add details here.

FreeIPA default deployment configuration includes Certificate Authority which is used to issue all certificates required for FreeIPA operations. This CA is implemented with the help of Dogtag PKI project. Current version of Dogtag PKI uses VLV feature internally to handle certificates during issuance and pruning of expired certificates. Broken VLV means several problems would occur:

- Dogtag PKI would not be seeing correct data when issuing certificates, meaning it potentially could issue certficates with serial numbers that already were used
- Dogtag PKI might not be able to see already issued but expired certificates that might accumulate and clutter data store

These problems especially affect environment where people has enabled ACME protocol support in FreeIPA, making possible to automatically issue certificates for external applications (ACME is the protocol behind Let's Encrypt! service).

We recognize that Fedora OpenQA tests for FreeIPA aren't utilizing these scenarios with large enough number of certificates to trigger problems in 389-ds. We have been able to find these issues in FreeIPA upstream tests when we started to switch by default to random serial numbers feature of Dogtag PKI (which is a requirement if you have thousands of ACME certificates).

The change, as proposed, is contained within 389-ds lmdb database backend implementation. FreeIPA team has a reproducer and was able to confirm the fix is working.

The component 389-ds-base delivers a LDAP V3 Directory Server. Since it was part of Fedora, 389-ds-base support VLV control (https://datatracker.ietf.org/doc/html/draft-ietf-ldapext-ldapv3-vlv-09) and Dogtag PKI is not the only project using VLV.

VLV are working fine up to F39. This bug is a regression that appeared in F40. Since F40, 389-ds-base switched to a new database (LMDB) and the implementation of VLV with that new database hit those bugs (https://github.com/389ds/389-ds-base/issues/6347 and 389ds 389-ds-base issues 6356).

FreeIPA identified a systematic reproducer that reveal that bug but the nasty thing is that the regression may also be not noticeable. Because of that bug LDAP server can fail to process VLV control but may also report invalid results. Indeed the bug is a misalignment between a cache and a database and the server may not detect this misalignment and return invalid data from the cache.

Discussed at a blocker review meeting [1], agreed on the following:

AcceptedFreezeException (Final), punt (blocker status) - we noted that the current FreeIPA criteria do not explicitly cover certificate issuance and management, but this could be considered an oversight. For now we agreed to accept this as a freeze exception issue to minimize the likelihood of problems for early deployments, and delay the blocker decision to allow for discussion of whether there should be a criterion covering this feature of FreeIPA

[1] https://meetbot-raw.fedoraproject.org//meeting_matrix_fedoraproject-org/2024-10-14/

FEDORA-2024-e2b005db3d (389-ds-base-3.1.1-3.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-e2b005db3d

FEDORA-2024-e04bcb55d4 (389-ds-base-3.0.4-3.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-e04bcb55d4

FEDORA-2024-8d43854db3 (389-ds-base-3.1.1-3.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-8d43854db3

FEDORA-2024-e04bcb55d4 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-e04bcb55d4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-e04bcb55d4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-8d43854db3 has been pushed to the Fedora 41 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-8d43854db3`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-8d43854db3

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-e2b005db3d (389-ds-base-3.1.1-3.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.

This is an F41 FE, so it should not be closed by the Rawhide update going stable.

FEDORA-2024-8d43854db3 (389-ds-base-3.1.1-3.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2024-e04bcb55d4 (389-ds-base-3.0.4-3.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.