cracklib

Overview

CrackLib is a library for checking whether a password looks too easy to guess or too similar to dictionary words. In practice, it is used by password-setting tools and policy checks that need a simple local test before a password is accepted. The upstream project describes itself as “CrackLib Library and Dictionaries”, and its repository contains the library code together with dictionary-building content and scripts. (github.com)

For a Linux distribution, this package exists so that other components can reuse the same password-checking logic instead of reimplementing their own rules. Typical users are distribution maintainers, administrators who care about password policy, developers integrating authentication or account-management tooling, and CI/CD maintainers who need reproducible builds and package verification. The exact integration points in NiceOS should be verified against the built subpackages and their consumers. (manpages.debian.org)

Purpose and typical use cases

Common uses include:

• checking candidate passwords during account creation or password changes;
• providing a dictionary-based strength test in authentication workflows;
• supporting tooling that needs a local password quality check before accepting input.

A typical use pattern is that a higher-level program calls into CrackLib, receives either a weak-password message or a success result, and then applies its own policy on top. The exact packaging split and caller applications in NiceOS should be verified before relying on a particular integration path. (manpages.debian.org)

Upstream project

Upstream project page: cracklib/cracklib

The upstream repository shows the main project layout, including source code under src and dictionary-related material under words. NiceOS maintainers should treat upstream as the authoritative place to check for project layout changes, build instructions, and release notes that may affect packaging. (github.com)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic.
• SOURCES/ — source-manifest metadata used by the package.
• METADATA/ — repository metadata used by the packaging workflow.
• SBOM/ — software bill of materials data, when maintained for the package.

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/, so the repository stays small and only carries packaging metadata plus the references needed to reconstruct the source set. (github.com)

Source storage and integrity policy

NiceOS keeps the packaging repository focused on metadata and reproducible source references rather than storing large tarballs in Git. Before updating the package, maintainers should verify that the SOURCES/ manifests still point to the intended upstream source set and that any regenerated metadata matches the new upstream inputs.

Do not rely on a visual check of the repository tree alone. Confirm that the source list is complete and that any archive replacement, dictionary content change, or patch refresh is intentional. If the package uses generated files, verify whether they need regeneration and whether the regenerated output is stable enough to review cleanly.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check the following:

• whether upstream changed the source layout, build system, or dictionary-generation workflow;
• whether any files in SPECS/ need refresh because of changed build flags, file lists, or subpackage splits;
• whether SOURCES/ manifests need regeneration because the upstream source set changed;
• whether SBOM/ data, if present, needs a new refresh to stay aligned with the package contents;
• whether downstream patches still apply cleanly and still make sense for the current upstream tree;
• whether the package still builds with the intended toolchain and linker settings in NiceOS.

Risks to consider:

• generated dictionary or data files may change even when the code changes only slightly;
• build-time script behavior may differ across upstream releases;
• package consumers may depend on file paths or installed helper names, so file-list changes should be reviewed carefully.

If any of these points are unclear, NiceOS maintainers should verify them against the current spec file and upstream build instructions before merging the update. (github.com)

Build and verification checklist

Use this checklist for RPM maintenance work:

• review the upstream repository for build or layout changes;
• inspect the spec file for source references, patch application, and subpackage definitions;
• confirm that the SOURCES/ manifest matches the intended upstream inputs;
• regenerate packaging metadata only when needed, and review the diff carefully;
• build the SRPM and RPMs in a clean environment;
• run %check if the package defines one;
• inspect build logs for missing headers, deprecated compiler flags, or failing helper scripts;
• verify the installed file list against expectations;
• confirm that any dictionary or generated data files are reproducible in the build environment;
• review licensing and package metadata after the build.

References

• Upstream repository
• CrackLib man page
• pam_cracklib man page

Russian documentation

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

Dist-git repository notes

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