Back to bug 2103327
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Red Hat Bugzilla | 2022-07-02 08:50:29 UTC | Pool ID | sst_idm_ipa_rhel_9 | |
| Red Hat One Jira (issues.redhat.com) | 2022-07-02 09:04:35 UTC | Link ID | Red Hat Issue Tracker FREEIPA-8445 | |
| Red Hat One Jira (issues.redhat.com) | 2022-07-02 09:04:39 UTC | Link ID | Red Hat Issue Tracker RHELPLAN-126891 | |
| Florence Blanc-Renaud | 2022-07-03 15:13:26 UTC | Flags | needinfo?(abroy) | |
| Florence Blanc-Renaud | 2022-07-07 09:07:06 UTC | CC | dpal, fdvorak | |
| Assignee | frenaud | jrische | ||
| Component | ipa | krb5 | ||
| Julien Rische | 2022-07-08 16:19:34 UTC | Status | NEW | ASSIGNED |
| Julien Rische | 2022-07-12 08:08:36 UTC | Summary | RHEL 9.0 IPA Client Fails to Join Realm or authenticate users with FIPS enabled | Generate AES SHA-2 HMAC keys on deployed IPA instances in FIPS mode |
| Abhijit Roy | 2022-07-12 19:47:36 UTC | Flags | needinfo?(abroy) | |
| RHEL Program Management | 2022-07-13 08:57:14 UTC | Keywords | Triaged | |
| cilmar | 2022-08-30 15:30:35 UTC | CC | cilmar | |
| Vinay Mishra | 2022-08-30 17:44:37 UTC | CC | vmishra | |
| Vinay Mishra | 2022-08-31 18:43:09 UTC | Link ID | Red Hat Knowledge Base (Solution) 6973768 | |
| Red Hat Bugzilla | 2022-11-05 04:17:47 UTC | CC | dpal | |
| Prasad Kulkarni | 2023-01-10 01:34:17 UTC | CC | pkulkarn | |
| Abhinay Reddy Peddireddy | 2023-01-11 09:41:23 UTC | CC | apeddire, jrische | |
| Flags | needinfo?(jrische) | |||
| Kevin Myers | 2023-01-11 17:15:26 UTC | CC | kemyers | |
| Kuunal Rathod | 2023-01-20 06:37:21 UTC | CC | kurathod | |
| Kuunal Rathod | 2023-01-20 06:37:34 UTC | Severity | medium | high |
| Kuunal Rathod | 2023-01-20 06:59:10 UTC | Flags | needinfo?(jrische) | |
| Julien Rische | 2023-01-20 17:35:28 UTC | Flags | needinfo?(jrische) needinfo?(jrische) | |
| Abhinay Reddy Peddireddy | 2023-01-21 05:37:09 UTC | Flags | needinfo?(jrische) | |
| Ding-Yi Chen | 2023-01-23 04:07:53 UTC | Flags | needinfo?(jrische) | |
| CC | dchen | |||
| Ding-Yi Chen | 2023-01-23 07:45:25 UTC | Link ID | Red Hat Bugzilla 2006843 | |
| Abhinay Reddy Peddireddy | 2023-01-26 07:44:45 UTC | Flags | needinfo?(jrische) | |
| Mike Ralph | 2023-01-26 13:20:42 UTC | CC | mralph | |
| Julien Rische | 2023-01-27 14:41:53 UTC | Flags | needinfo?(jrische) | |
| Julien Rische | 2023-01-27 14:43:55 UTC | CC | abokovoy | |
| Flags | needinfo?(abokovoy) | |||
| Alexander Bokovoy | 2023-01-30 07:39:18 UTC | Flags | needinfo?(abokovoy) | |
| Julien Rische | 2023-01-30 08:43:58 UTC | Doc Text | Cause: The default RHEL9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961 section 5.1[1] (contrary to RHEL7 and RHEL8 which are aiming FIPS 140-2 compliance, where this function is allowed). This leaves AES HMAC-SHA2 encryption types as the only option for Kerberos cryptography. Consequence: This constraint will be a blocker when migrating an IPA instance from FIPS RHEL8 to FIPS RHEL9. For IPA instances created on FIPS RHEL 8.6 and older, migration will fail because there will be no common encryption types between RHEL9 and previous RHEL version servers. Workaround (if any): Enable the AD-SUPPORT module for the FIPS policy on RHEL9 servers: update-crypto-policies --set FIPS:AD-SUPPORT This will allow AES HMAC-SHA1 encryption types, which is still compliant with FIPS 140-2. The module is named AD-SUPPORT because AES HMAC-SHA1 encryption types are also the strongest ones available on Active Directory. Result: This will allow FIPS RHEL9 servers to use AES HMAC-SHA1 encryption types, which will allow migration from FIPS RHEL8 to RHEL9. There is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys (achieving FIPS 140-3 compliance). However this process will not be fully automated, because the design of Kerberos key cryptography does not allow converting existing keys to different encryption types. The only way is to ask users to renew their passwords. | |
| Doc Type | If docs needed, set a value | Known Issue | ||
| Gabi Fialová | 2023-01-30 12:46:30 UTC | Docs Contact | fhanzelk | |
| Filip Hanzelka | 2023-02-07 15:56:02 UTC | Doc Text | Cause: The default RHEL9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961 section 5.1[1] (contrary to RHEL7 and RHEL8 which are aiming FIPS 140-2 compliance, where this function is allowed). This leaves AES HMAC-SHA2 encryption types as the only option for Kerberos cryptography. Consequence: This constraint will be a blocker when migrating an IPA instance from FIPS RHEL8 to FIPS RHEL9. For IPA instances created on FIPS RHEL 8.6 and older, migration will fail because there will be no common encryption types between RHEL9 and previous RHEL version servers. Workaround (if any): Enable the AD-SUPPORT module for the FIPS policy on RHEL9 servers: update-crypto-policies --set FIPS:AD-SUPPORT This will allow AES HMAC-SHA1 encryption types, which is still compliant with FIPS 140-2. The module is named AD-SUPPORT because AES HMAC-SHA1 encryption types are also the strongest ones available on Active Directory. Result: This will allow FIPS RHEL9 servers to use AES HMAC-SHA1 encryption types, which will allow migration from FIPS RHEL8 to RHEL9. There is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys (achieving FIPS 140-3 compliance). However this process will not be fully automated, because the design of Kerberos key cryptography does not allow converting existing keys to different encryption types. The only way is to ask users to renew their passwords. | .Migrating IdM servers running on RHEL 8.6 or earlier in FIPS mode to RHEL 9 fails The default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of the AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961, section 5.1. This constraint is a blocker when migrating an Identity Management (IdM) instance from FIPS RHEL 8.6 and earlier to FIPS RHEL 9. This is because there are no common encryption types between RHEL 9 and the previous RHEL versions, which commonly use the AES HMAC-SHA1 encryption types but do not use the AES HMAC-SHA2 encryption types. To work around the problem, enable the use of AES HMAC-SHA1 on RHEL9 servers: + [subs="quotes"] ---- update-crypto-policies --set FIPS:AD-SUPPORT ---- As a result, migration from FIPS RHEL 8 to RHEL 9 proceeds correctly. Note that there is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys on RHEL 7 and RHEL 8 servers. This will achieve FIPS 140-3 compliance. However, this process will not be fully automated, because the design of Kerberos key cryptography makes it impossible to convert existing keys to different encryption types. The only way is to ask users to renew their passwords. |
| Filip Hanzelka | 2023-02-07 16:12:29 UTC | Flags | needinfo?(jrische) | |
| Julien Rische | 2023-02-08 09:27:47 UTC | Flags | needinfo?(jrische) | |
| Filip Hanzelka | 2023-02-09 06:38:23 UTC | Doc Text | .Migrating IdM servers running on RHEL 8.6 or earlier in FIPS mode to RHEL 9 fails The default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of the AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961, section 5.1. This constraint is a blocker when migrating an Identity Management (IdM) instance from FIPS RHEL 8.6 and earlier to FIPS RHEL 9. This is because there are no common encryption types between RHEL 9 and the previous RHEL versions, which commonly use the AES HMAC-SHA1 encryption types but do not use the AES HMAC-SHA2 encryption types. To work around the problem, enable the use of AES HMAC-SHA1 on RHEL9 servers: + [subs="quotes"] ---- update-crypto-policies --set FIPS:AD-SUPPORT ---- As a result, migration from FIPS RHEL 8 to RHEL 9 proceeds correctly. Note that there is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys on RHEL 7 and RHEL 8 servers. This will achieve FIPS 140-3 compliance. However, this process will not be fully automated, because the design of Kerberos key cryptography makes it impossible to convert existing keys to different encryption types. The only way is to ask users to renew their passwords. | .Migrating IdM environment in FIPS mode that was initialized with RHEL 8.6 or earlier to RHEL 9 fails The default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of the AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961, section 5.1. This constraint is a blocker when migrating an Identity Management (IdM) environment that is running in FIPS mode and in which the first server was installed on a RHEL 8.6 system or earlier, to RHEL 9 in FIPS mode. This is because there are no common encryption types between RHEL 9 and the previous RHEL versions, which commonly use the AES HMAC-SHA1 encryption types but do not use the AES HMAC-SHA2 encryption types. To work around the problem, enable the use of AES HMAC-SHA1 on the RHEL 9 servers: + [subs="quotes"] ---- update-crypto-policies --set FIPS:AD-SUPPORT ---- As a result, migration from FIPS RHEL 8 to RHEL 9 proceeds correctly. Note that there is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys on RHEL 7 and RHEL 8 servers. This will achieve FIPS 140-3 compliance on RHEL 9. However, this process will not be fully automated, because the design of Kerberos key cryptography makes it impossible to convert existing keys to different encryption types. The only way is to ask users to renew their passwords. |
| Filip Hanzelka | 2023-02-09 06:58:53 UTC | Doc Text | .Migrating IdM environment in FIPS mode that was initialized with RHEL 8.6 or earlier to RHEL 9 fails The default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of the AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961, section 5.1. This constraint is a blocker when migrating an Identity Management (IdM) environment that is running in FIPS mode and in which the first server was installed on a RHEL 8.6 system or earlier, to RHEL 9 in FIPS mode. This is because there are no common encryption types between RHEL 9 and the previous RHEL versions, which commonly use the AES HMAC-SHA1 encryption types but do not use the AES HMAC-SHA2 encryption types. To work around the problem, enable the use of AES HMAC-SHA1 on the RHEL 9 servers: + [subs="quotes"] ---- update-crypto-policies --set FIPS:AD-SUPPORT ---- As a result, migration from FIPS RHEL 8 to RHEL 9 proceeds correctly. Note that there is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys on RHEL 7 and RHEL 8 servers. This will achieve FIPS 140-3 compliance on RHEL 9. However, this process will not be fully automated, because the design of Kerberos key cryptography makes it impossible to convert existing keys to different encryption types. The only way is to ask users to renew their passwords. | .Migrating IdM environment in FIPS mode that was initialized with RHEL 8.6 or earlier to RHEL 9 fails The default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of the AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961, section 5.1. This constraint is a blocker when migrating [1] an Identity Management (IdM) environment that is running in FIPS mode and in which the first server was installed on a RHEL 8.6 system or earlier, to RHEL 9 in FIPS mode. This is because there are no common encryption types between RHEL 9 and the previous RHEL versions, which commonly use the AES HMAC-SHA1 encryption types but do not use the AES HMAC-SHA2 encryption types. To work around the problem, enable the use of AES HMAC-SHA1 on the RHEL 9 servers: + [subs="quotes"] ---- update-crypto-policies --set FIPS:AD-SUPPORT ---- As a result, migration from FIPS RHEL 8 to RHEL 9 proceeds correctly. Note that there is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys on RHEL 7 and RHEL 8 servers. This will achieve FIPS 140-3 compliance on RHEL 9. However, this process will not be fully automated, because the design of Kerberos key cryptography makes it impossible to convert existing keys to different encryption types. The only way is to ask users to renew their passwords. [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/migrating_to_identity_management_on_rhel_9/assembly_migrating-your-idm-environment-from-rhel-8-servers-to-rhel-9-servers_migrating-to-idm-on-rhel-9 |
| Filip Hanzelka | 2023-02-10 09:11:34 UTC | Flags | needinfo?(jrische) | |
| Julien Rische | 2023-02-10 09:19:57 UTC | Flags | needinfo?(jrische) | |
| Filip Hanzelka | 2023-02-13 04:56:49 UTC | Doc Text | .Migrating IdM environment in FIPS mode that was initialized with RHEL 8.6 or earlier to RHEL 9 fails The default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of the AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961, section 5.1. This constraint is a blocker when migrating [1] an Identity Management (IdM) environment that is running in FIPS mode and in which the first server was installed on a RHEL 8.6 system or earlier, to RHEL 9 in FIPS mode. This is because there are no common encryption types between RHEL 9 and the previous RHEL versions, which commonly use the AES HMAC-SHA1 encryption types but do not use the AES HMAC-SHA2 encryption types. To work around the problem, enable the use of AES HMAC-SHA1 on the RHEL 9 servers: + [subs="quotes"] ---- update-crypto-policies --set FIPS:AD-SUPPORT ---- As a result, migration from FIPS RHEL 8 to RHEL 9 proceeds correctly. Note that there is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys on RHEL 7 and RHEL 8 servers. This will achieve FIPS 140-3 compliance on RHEL 9. However, this process will not be fully automated, because the design of Kerberos key cryptography makes it impossible to convert existing keys to different encryption types. The only way is to ask users to renew their passwords. [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/migrating_to_identity_management_on_rhel_9/assembly_migrating-your-idm-environment-from-rhel-8-servers-to-rhel-9-servers_migrating-to-idm-on-rhel-9 | .Adding a RHEL 9 replica in FIPS mode to an IdM deployment in FIPS mode that was initialized with RHEL 8.6 or earlier fails The default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of the AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961, section 5.1. This constraint is a blocker when adding a RHEL 9 Identity Management (IdM) replica in FIPS mode to a RHEL 8 IdM environment in FIPS mode in which the first server was installed on a RHEL 8.6 system or earlier. This is because there are no common encryption types between RHEL 9 and the previous RHEL versions, which commonly use the AES HMAC-SHA1 encryption types but do not use the AES HMAC-SHA2 encryption types. You can view the encryption type of your IdM master key by entering the following command on the server: + [subs="quotes"] ---- # kadmin.local getprinc K/M | grep -E '^Key:' ---- To work around the problem, enable the use of AES HMAC-SHA1 on the RHEL 9 replica: + [subs="quotes"] ---- update-crypto-policies --set FIPS:AD-SUPPORT ---- As a result, adding the RHEL 9 replica to the IdM deployment proceeds correctly. Note that there is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys on RHEL 7 and RHEL 8 servers. This will achieve FIPS 140-3 compliance on the RHEL 9 replica. However, this process will not be fully automated, because the design of Kerberos key cryptography makes it impossible to convert existing keys to different encryption types. The only way is to ask users to renew their passwords. |
| Abhinay Reddy Peddireddy | 2023-02-19 09:09:00 UTC | Flags | needinfo?(jrische) | |
| Julien Rische | 2023-02-27 13:56:10 UTC | Flags | needinfo?(jrische) | |
| Lenka Špačková | 2023-03-13 13:13:42 UTC | Doc Text | .Adding a RHEL 9 replica in FIPS mode to an IdM deployment in FIPS mode that was initialized with RHEL 8.6 or earlier fails The default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of the AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961, section 5.1. This constraint is a blocker when adding a RHEL 9 Identity Management (IdM) replica in FIPS mode to a RHEL 8 IdM environment in FIPS mode in which the first server was installed on a RHEL 8.6 system or earlier. This is because there are no common encryption types between RHEL 9 and the previous RHEL versions, which commonly use the AES HMAC-SHA1 encryption types but do not use the AES HMAC-SHA2 encryption types. You can view the encryption type of your IdM master key by entering the following command on the server: + [subs="quotes"] ---- # kadmin.local getprinc K/M | grep -E '^Key:' ---- To work around the problem, enable the use of AES HMAC-SHA1 on the RHEL 9 replica: + [subs="quotes"] ---- update-crypto-policies --set FIPS:AD-SUPPORT ---- As a result, adding the RHEL 9 replica to the IdM deployment proceeds correctly. Note that there is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys on RHEL 7 and RHEL 8 servers. This will achieve FIPS 140-3 compliance on the RHEL 9 replica. However, this process will not be fully automated, because the design of Kerberos key cryptography makes it impossible to convert existing keys to different encryption types. The only way is to ask users to renew their passwords. | .Adding a RHEL 9 replica in FIPS mode to an IdM deployment in FIPS mode that was initialized with RHEL 8.6 or earlier fails The default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of the AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961, section 5.1. This constraint is a blocker when adding a RHEL 9 Identity Management (IdM) replica in FIPS mode to a RHEL 8 IdM environment in FIPS mode in which the first server was installed on a RHEL 8.6 system or earlier. This is because there are no common encryption types between RHEL 9 and the previous RHEL versions, which commonly use the AES HMAC-SHA1 encryption types but do not use the AES HMAC-SHA2 encryption types. You can view the encryption type of your IdM master key by entering the following command on the server: [subs="quotes"] ---- # kadmin.local getprinc K/M | grep -E '^Key:' ---- To work around the problem, enable the use of AES HMAC-SHA1 on the RHEL 9 replica: [subs="quotes"] ---- update-crypto-policies --set FIPS:AD-SUPPORT ---- As a result, adding the RHEL 9 replica to the IdM deployment proceeds correctly. Note that there is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys on RHEL 7 and RHEL 8 servers. This will achieve FIPS 140-3 compliance on the RHEL 9 replica. However, this process will not be fully automated, because the design of Kerberos key cryptography makes it impossible to convert existing keys to different encryption types. The only way is to ask users to renew their passwords. |
| Lenka Špačková | 2023-03-13 15:19:29 UTC | CC | fhanzelk | |
| Flags | needinfo?(fhanzelk) | |||
| Filip Hanzelka | 2023-03-13 15:49:08 UTC | Flags | needinfo?(fhanzelk) | needinfo?(jrische) |
| Julien Rische | 2023-03-13 16:06:39 UTC | Flags | needinfo?(jrische) | |
| Florence Blanc-Renaud | 2023-04-21 08:30:10 UTC | CC | frenaud | |
| Alexander Sosedkin | 2023-04-26 09:52:39 UTC | Flags | needinfo?(fhanzelk) | |
| CC | asosedki | |||
| Filip Hanzelka | 2023-04-30 12:13:14 UTC | Doc Text | .Adding a RHEL 9 replica in FIPS mode to an IdM deployment in FIPS mode that was initialized with RHEL 8.6 or earlier fails The default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of the AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961, section 5.1. This constraint is a blocker when adding a RHEL 9 Identity Management (IdM) replica in FIPS mode to a RHEL 8 IdM environment in FIPS mode in which the first server was installed on a RHEL 8.6 system or earlier. This is because there are no common encryption types between RHEL 9 and the previous RHEL versions, which commonly use the AES HMAC-SHA1 encryption types but do not use the AES HMAC-SHA2 encryption types. You can view the encryption type of your IdM master key by entering the following command on the server: [subs="quotes"] ---- # kadmin.local getprinc K/M | grep -E '^Key:' ---- To work around the problem, enable the use of AES HMAC-SHA1 on the RHEL 9 replica: [subs="quotes"] ---- update-crypto-policies --set FIPS:AD-SUPPORT ---- As a result, adding the RHEL 9 replica to the IdM deployment proceeds correctly. Note that there is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys on RHEL 7 and RHEL 8 servers. This will achieve FIPS 140-3 compliance on the RHEL 9 replica. However, this process will not be fully automated, because the design of Kerberos key cryptography makes it impossible to convert existing keys to different encryption types. The only way is to ask users to renew their passwords. | .Adding a RHEL 9 replica in FIPS mode to an IdM deployment in FIPS mode that was initialized with RHEL 8.6 or earlier fails The default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of the AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961, section 5.1. This constraint is a blocker when adding a RHEL 9 Identity Management (IdM) replica in FIPS mode to a RHEL 8 IdM environment in FIPS mode in which the first server was installed on a RHEL 8.6 system or earlier. This is because there are no common encryption types between RHEL 9 and the previous RHEL versions, which commonly use the AES HMAC-SHA1 encryption types but do not use the AES HMAC-SHA2 encryption types. You can view the encryption type of your IdM master key by entering the following command on the server: [subs="quotes"] ---- # kadmin.local getprinc K/M | grep -E '^Key:' ---- To work around the problem, enable the use of AES HMAC-SHA1 on the RHEL 9 replica: [subs="quotes"] ---- update-crypto-policies --set FIPS:AD-SUPPORT ---- WARNING:: This workaround might violate FIPS compliance. As a result, adding the RHEL 9 replica to the IdM deployment proceeds correctly. Note that there is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys on RHEL 7 and RHEL 8 servers. This will achieve FIPS 140-3 compliance on the RHEL 9 replica. However, this process will not be fully automated, because the design of Kerberos key cryptography makes it impossible to convert existing keys to different encryption types. The only way is to ask users to renew their passwords. |
| Filip Hanzelka | 2023-04-30 12:13:55 UTC | Flags | needinfo?(fhanzelk) | |
| Amy Farley | 2023-05-02 12:48:38 UTC | CC | afarley | |
| Flags | needinfo?(jrische) | |||
| Vincent van Haften | 2023-05-25 21:01:53 UTC | CC | vvanhaft | |
| Eugene Keck | 2023-05-25 21:08:47 UTC | CC | ekeck | |
| Têko Mihinto | 2023-05-26 06:59:56 UTC | CC | tmihinto | |
| Filip Dvorak | 2023-05-30 13:12:32 UTC | QA Contact | ipa-qe | mpolovka |
| Red Hat Bugzilla | 2023-05-31 23:36:55 UTC | CC | fdvorak | |
| Julien Rische | 2023-07-11 07:43:38 UTC | Flags | needinfo?(jrische) | needinfo- |
Back to bug 2103327