argon2

Overview

Argon2 is a library and reference implementation for the Argon2 password-hashing algorithm. Upstream describes it as the reference C implementation of Argon2, the function that won the Password Hashing Competition. In practice, the package is used wherever software needs to hash passwords, derive keys from passwords, or work with Argon2-formatted hashes. (github.com)

For a Linux distribution, this package typically exists to provide the shared library, headers, and related build artifacts needed by other packages that depend on Argon2. NiceOS maintainers should verify the exact file layout and subpackages produced by the spec before relying on that assumption.

Purpose and typical use cases

Typical uses include:

• password storage in applications and services
• password-based key derivation
• command-line testing or verification of Argon2 parameters and outputs
• linking from other software that needs a local Argon2 implementation

Typical users include:

• application developers integrating password hashing or key derivation
• system administrators managing software that stores password verifiers
• security engineers reviewing password-hashing parameters and packaging choices
• CI/CD maintainers building or testing dependent software

Argon2 is parameterized by time cost, memory cost, and parallelism. NiceOS maintainers should check the upstream documentation and package defaults if update work depends on any specific parameter profile. (github.com)

Upstream project

Upstream project: P-H-C/phc-winner-argon2 on GitHub. The upstream repository states that it is the reference C implementation of Argon2 and points to the Argon2 specification document for design and rationale. (github.com)

Upstream documentation and references that are useful when reviewing package updates:

• project repository and README
• Argon2 specification PDF

Dist-git repository contents

This dist-git repository is organized as a standard RPM packaging tree:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source-control metadata and manifest files used to describe external sources
• METADATA/ — package metadata used by the packaging workflow
• SBOM/ — software bill of materials material, if present for this package

The repository intentionally does not store large upstream source archives in Git. Instead, source integrity is tracked through manifest files in SOURCES/. That keeps the repository lightweight and makes the packaging workflow depend on external source fetching plus manifest verification rather than vendoring large archives here.

Source storage and integrity policy

The source policy for this package is simple: do not commit large upstream archives to the Git repository. Keep only the metadata and manifests needed to identify the approved upstream source set.

When reviewing a package update, NiceOS maintainers should verify that:

• the manifest in SOURCES/ matches the intended upstream source set
• the spec still points to the correct source layout
• any changes in upstream packaging inputs are intentional
• local patches, if any, are still needed and still apply cleanly

Do not rely on unstated assumptions about the source contents. If a source-related detail is uncertain, verify it before using it in a release process.

NiceOS maintenance notes

Before updating this package, check the following:

• upstream project status and whether the relevant repository or release process has changed
• whether the spec needs refresh for new build tooling, install paths, or file lists
• whether SOURCES/ manifests need regeneration because upstream source inputs changed
• whether SBOM/ needs to be updated to reflect the current packaged material
• whether any downstream patch still applies cleanly and is still justified
• whether build flags, test execution, or installed artifacts changed in a way that affects dependent packages

Risks to consider:

• upstream layout changes that alter installed library names, headers, or helper tools
• packaging drift if the spec assumes file locations that changed upstream
• accidental inclusion of untracked or outdated source metadata
• stale patch sets or local overrides that hide upstream behavior changes

Build and verification checklist

For RPM maintainers, a practical update check looks like this:

• review the upstream changelog or release notes before importing a new source set
• compare the current spec with the upstream build instructions
• refresh SOURCES/ manifests if the approved source inputs changed
• confirm the spec still produces the expected subpackages and installed files
• build the SRPM and RPMs in a clean environment
• run the package test suite if the spec enables one
• inspect the build log for warnings about missing files, deprecated flags, or changed install paths
• verify that the resulting artifacts match the expected library, headers, and helper programs for this package
• check that SBOM data, if maintained, still matches the packaged output

References

• P-H-C/phc-winner-argon2
• Argon2 specification PDF

Russian documentation

See README_RU.md for the Russian documentation.

Dist-git repository notes

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