botan2

Overview

Botan 2 is a C++ cryptography library. Upstream describes it as a general-purpose library for production cryptography, with support for common building blocks such as TLS, X.509 PKI, public-key cryptography, hashes, authenticated encryption, hardware-backed key handling, and password hashing. It also provides C, C++, and Python APIs, plus a command-line interface. (botan.randombit.net)

In a Linux distribution, this package exists to supply the shared library, headers, command-line tools, and related metadata needed by other packages that build on Botan. Exact subpackages and build options are controlled by the RPM spec in this repository.

Purpose and typical use cases

Botan is typically used when software needs cryptographic primitives or higher-level protocol support without bundling its own crypto implementation. Common use cases include:

• application code that needs hashes, MACs, AEAD ciphers, or public-key operations;
• TLS- or X.509-related components;
• tools or services that need a crypto library provided by the distribution rather than a vendored copy;
• packaging and integration work where maintainers need a consistent system library for dependent software.

Typical users include:

• distribution maintainers who package or update the library;
• developers who build against Botan’s headers and libraries;
• security engineers reviewing crypto dependencies or library builds;
• CI/CD maintainers who need reproducible builds and basic verification steps;
• administrators who install the packaged tools or who manage dependent software on managed systems.

Upstream project

Upstream documentation is hosted on the Botan website. The project overview and handbook are the most useful references for package maintainers because they explain the library’s purpose, build model, user-facing documentation, and notes for distributors. (botan.randombit.net)

Botan is developed on GitHub. NiceOS maintainers should verify packaging assumptions against upstream documentation before making changes, especially when updating build options, enabled modules, or any compatibility-sensitive settings. (botan.randombit.net)

Dist-git repository contents

This dist-git repository contains the packaging sources, not the full upstream source tree.

• SPECS/ — RPM spec files and packaging logic.
• SOURCES/ — source manifests and other packaging metadata used to describe what should be fetched for the build.
• METADATA/ — repository metadata used by the dist-git workflow.
• SBOM/ — software bill of materials material, when maintained for this package.

The repository is organized so that maintainers can review packaging changes separately from upstream source material.

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. This allows the dist-git history to stay small and reviewable while still recording which upstream materials the build expects.

When updating the package, maintainers should verify that the manifests in SOURCES match the upstream source that will be built. Do not rely on a stale manifest when the upstream tarball, tag, or build input has changed.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether upstream release notes mention build-system changes, removed modules, renamed APIs, or migration notes that affect packaged consumers; (botan.randombit.net)
• whether the spec still enables the intended features and disables anything that should not be shipped in NiceOS;
• whether any generated packaging files need refresh, such as source manifests in SOURCES, patches, or other metadata that references upstream content;
• whether SBOM/ content, if present, still reflects the packaged outputs;
• whether downstream consumers may rely on ABI or API behavior that changed upstream.

Useful risks to consider:

• upstream build defaults may change;
• optional modules may be added, removed, or renamed;
• documentation or test expectations may no longer match the current upstream tree;
• changes in generated files can make a patch series or manifest stale.

If a detail is uncertain, NiceOS maintainers should verify it against upstream documentation or a local build before relying on it.

Build and verification checklist

For an RPM maintainer update, a practical checklist is:

1. Confirm that the upstream source referenced by SOURCES is the intended one.
2. Review upstream release notes and distributor notes for changes that affect packaging. (botan.randombit.net)
3. Inspect the spec for build flags, feature toggles, subpackages, and file ownership changes.
4. Regenerate or refresh packaging metadata if the upstream source layout changed.
5. Build the package in a clean environment.
6. Run the package test suite if enabled by the spec or by the build environment.
7. Check the generated RPM payload for unexpected libraries, tools, documentation, or examples.
8. Verify that the install paths, sonames, and devel files match downstream expectations.
9. Review any SBOM/ updates if the repository maintains them.
10. Test one or more dependent packages if the update could affect consumers.

References

• Botan project overview
• Botan handbook
• Botan API reference
• Botan notes for distributors

Russian documentation

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

Dist-git repository notes

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