authselect

Overview

Authselect is a tool for choosing and managing system authentication and identity profiles. Upstream describes it as a replacement for older authentication configuration workflows, with the goal of applying tested profile sets instead of assembling PAM and identity configuration by hand. (github.com)

In a Linux distribution, this package usually exists to provide the command-line tool and related files that let administrators select, inspect, and test authentication profiles in a controlled way. NiceOS maintainers should verify the exact integration points in this branch, because packaging details can differ between distributions. (github.com)

Purpose and typical use cases

Typical use cases include:

• selecting a predefined authentication profile for a system
• testing what a profile would change before applying it
• creating or adapting custom profiles for site-specific authentication needs
• keeping PAM and identity-related configuration consistent across managed hosts

Typical users include system administrators, CI/CD or image-build maintainers who need reproducible base-system configuration, and security engineers who want configuration handled through supported profiles rather than ad hoc edits. These are practical user groups inferred from the upstream tool’s purpose; NiceOS maintainers should verify the exact local audience for this package. (github.com)

Upstream project

Upstream project homepage: the authselect/authselect repository on GitHub. The upstream README states that authselect selects system authentication and identity sources from supported profiles, and notes GPL-3.0 licensing. (github.com)

For command usage and behavior, consult the upstream repository and the installed manual pages on a built system. NiceOS maintainers should verify whether distribution-specific patches change the user-facing behavior. (github.com)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source metadata and manifest files used to track upstream source inputs
• METADATA/ — repository metadata used by the packaging workflow
• SBOM/ — software bill of materials material, when present in the repository layout

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/. This keeps the repository smaller and makes the tracked inputs easier to review. (github.com)

Source storage and integrity policy

For this package, the important rule is that the Git repository stores packaging metadata and source-manifest information, not the full upstream source archive. When updating the package, maintainers should verify that the manifest in SOURCES/ matches the intended upstream input and that any repackaging or source regeneration step is reflected in the repository. Do not rely on a file being present in Git simply because it exists in a build environment. (github.com)

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether upstream changed command behavior, defaults, or profile layout
• whether any bundled profiles or installed documentation need regeneration
• whether the spec file still matches the build system and dependency expectations
• whether local patches are still needed, can be dropped, or need rebasing
• whether the update changes any files that are generated during build time
• whether the packaging still preserves the intended source-manifest workflow in SOURCES/

Risks to consider:

• authentication-related packages can affect system login behavior if packaging changes are incorrect
• custom or site-specific profile assumptions may break when upstream profile content changes
• repository metadata may need to be kept consistent with the spec and the source-manifest files

If any of these points are unclear from the repository contents, NiceOS maintainers should verify them against the spec, build logs, and upstream release notes before shipping the update. (github.com)

Build and verification checklist

For RPM maintenance work, a reasonable checklist is:

• review the spec diff before building
• confirm the SOURCES/ manifest still matches the expected upstream input
• rebuild in a clean environment
• inspect the build log for missing build requirements or unexpected regeneration steps
• verify the installed files match the package’s intended scope
• run package tests if they exist
• check that the package still provides the expected CLI and documentation
• if the package ships profiles or configuration files, test that they install and parse correctly
• review the final RPM for unwanted file additions or removals

NiceOS maintainers should add project-specific validation if the repository contains local patches, generated files, or downstream configuration overlays. (github.com)

References

• authselect upstream repository
• Fedora Change: Make Authselect Mandatory

Russian documentation

See README_RU.md for the Russian version of this document.

Dist-git repository notes

• Package repository: rpms/authselect
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.