The "openssh" package is currently shipping a binary at "/usr/libexec/openssh/ssh-keysign" which is owned by the "ssh_keys" group: ``` $ stat /usr/libexec/openssh/ssh-keysign File: /usr/libexec/openssh/ssh-keysign Size: 334248 Blocks: 656 IO Block: 4096 regular file Access: (2555/-r-xr-sr-x) Uid: ( 0/ root) Gid: ( 999/ssh_keys) ``` However the specfile does create the "ssh_keys" group with a dynamic group ID at install time: ``` %pre getent group ssh_keys >/dev/null || groupadd -r ssh_keys || : ``` This means that across different installs/composes the numeric GID of the file may vary arbitrarily (in the example above it got "999"). This poses a problem from the point of view of OS content reproducibility. It also causes issues to systems doing out-of-band composes (e.g. ostree or other image-based technologies). For these reasons, it would be better to get a static GID allocated for the "ssh_keys" group in Fedora.
As I didn't hear any positive/negative feedback here, I went ahead and formally brought this to the attention of FPC with a static GID request as described in https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_soft_static_allocation. The static GID request ticket for the "ssh_keys" group is at https://pagure.io/packaging-committee/issue/1188.
What should be done from my side? I agree it's a good idea.
Nothing for the moment. Once the GID allocation is confirmed and the exact number confirmed, the specfile will need to be updated to start using that in the `groupadd` call.
FEDORA-2022-c2a1a8c16b has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c2a1a8c16b
FEDORA-2022-c2a1a8c16b has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.