cyrus-sasl

Overview

Cyrus SASL is a general-purpose authentication library for client and server applications. In practice, it gives applications a standard way to use SASL mechanisms instead of hard-coding authentication logic into each project. The upstream documentation describes it as a glue layer between the application and the available authentication mechanisms. (cyrusimap.org)

In a Linux distribution, this package is typically present to provide the shared library and related files that other networked services and client tools need when they use SASL authentication. The exact set of consumers depends on the distribution and enabled build options, so NiceOS maintainers should verify the local package set before making assumptions.

Purpose and typical use cases

Typical use cases include:

• server software that offers SASL-based login or challenge-response authentication;
• client software that needs to authenticate against SASL-capable services;
• packaging a common authentication layer once, instead of duplicating mechanism handling in each application;
• enabling other packages in the distribution to link against or load SASL support at runtime.

Typical users of this package are:

• system administrators who maintain mail, directory, or other network services using SASL-based authentication;
• developers integrating authentication support into applications;
• build and CI/CD maintainers who need the development headers and runtime library to be available during package builds;
• security engineers reviewing authentication-related dependencies and packaging choices.

Upstream project

Upstream for this package is the Cyrus SASL project. Its official documentation and repository describe the library as the CMU Cyrus SASL implementation and provide reference material for administrators and programmers. (cyrusimap.org)

For distribution work, the important point is not the exact upstream release number, but the role of the project: a reusable authentication library that other software depends on.

Dist-git repository contents

This dist-git repository follows the standard RPM packaging layout:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source-related metadata and manifests used to track the expected upstream inputs;
• METADATA/ — repository metadata used by the dist-git tooling;
• SBOM/ — software bill of materials data when maintained for this package.

The repository is intended for packaging metadata, not for storing the full upstream source tree.

Source storage and integrity policy

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source integrity information in SOURCES/ manifests and related metadata. This keeps the dist-git repository small and focused on packaging, while still allowing maintainers to verify which upstream inputs belong to the package.

When updating the package, maintainers should check that the source manifest still matches the intended upstream tarball or other source input, and that any required integrity metadata has been refreshed consistently. Do not rely on copied files in the repository to infer what should be shipped.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should verify:

• whether the upstream project changed build requirements, configuration defaults, or supported mechanisms;
• whether the spec file needs refreshes for patches, conditional build flags, or file lists;
• whether SOURCES/ manifests or other source-tracking metadata need regeneration;
• whether SBOM/ data, if present, needs to be updated to reflect packaging changes;
• whether any downstream consumers in NiceOS depend on a specific library name, plugin layout, or file path;
• whether the update changes runtime behavior in a way that affects authentication flows.

Risks to consider:

• authentication packages can affect many dependent services even when the library change looks small;
• changes in mechanism support, plugin handling, or default paths may break dependent builds or runtime loading;
• packaging changes can alter which subpackages or files are available to consumers.

If a detail is uncertain, NiceOS maintainers should verify it against the current upstream sources and build logs before relying on it.

Build and verification checklist

For RPM maintenance, a practical update check should include:

• confirm the upstream source input is the one intended for the update;
• regenerate or refresh any required SOURCES/ manifest metadata;
• review the spec file for patch carryover, build conditionals, and file ownership changes;
• build the package in a clean mock or equivalent isolated environment;
• inspect build logs for new warnings, missing files, or dependency resolution changes;
• run the package's relevant test suite if one is available in the build environment;
• verify the produced RPM payload includes the expected shared library, development files, and any plugin or auxiliary files that the package is meant to ship;
• check that downstream consumers in the distribution still build and run against the updated package;
• review the generated SRPM and binary RPM contents before pushing the update.

References

• Cyrus SASL documentation
• SASL library reference
• Cyrus SASL quickstart guide
• Cyrus SASL GitHub repository

Russian documentation

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

Dist-git repository notes

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