apparmor

Overview

AppArmor is a Linux application security system that uses mandatory access control to confine programs and reduce the impact of software flaws or compromised systems. In a Linux distribution, this package typically exists to provide the user-space tools and policy-related components needed to work with AppArmor on supported systems. (launchpad.net)

Purpose and typical use cases

This package is useful when a system needs to:

• manage AppArmor policy and related user-space tooling;
• load, inspect, or troubleshoot application confinement profiles;
• support administrators who maintain restricted services or desktop applications;
• support developers and CI/CD maintainers who need to test software under confinement;
• support security engineers who review or adapt policy for a specific workload.

The exact set of packaged components can vary by distribution policy, so NiceOS maintainers should verify the spec file and built subpackages before relying on a specific runtime or administrative role.

Upstream project

Upstream AppArmor development is organized in the AppArmor project on GitLab, and the project website is published at apparmor.net. The upstream project describes AppArmor as a user-space development project for Linux application security. (gitlab.com)

Dist-git repository contents

This RPM dist-git repository is organized as follows:

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

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source-integrity metadata in SOURCES/ manifest files, which lets maintainers verify what should be fetched without checking large archives into Git.

Source storage and integrity policy

For this package, source integrity is tracked through the manifests stored in SOURCES/. The repository should be treated as a packaging control plane, not as a full mirror of upstream release artifacts.

Before updating the package, NiceOS maintainers should verify that:

• the spec still points to the intended upstream source and patch set;
• the SOURCES/ manifest files match the expected upstream inputs;
• any patch series still applies cleanly and is still needed;
• any generated metadata or helper files are updated when the upstream layout changes;
• the license information in the spec remains correct and complete;
• any optional components enabled by the spec are still appropriate for NiceOS.

If the upstream layout changes, maintainers should check whether SOURCES/, SBOM/, or spec-side file lists need regeneration. If the package ships policy files or helper scripts, review them for behavior changes before importing a new upstream release.

NiceOS maintenance notes

When preparing an update, a maintainer should usually check the following:

• whether the upstream project renamed, moved, or retired any policy or helper files;
• whether the spec needs refreshed patches, dropped patches, or new build-time conditionals;
• whether the package still builds with the distro toolchain and enabled hardening flags;
• whether tests or sanity checks need adjustment because of upstream changes;
• whether any packaging-generated metadata should be regenerated after source or file-list changes;
• whether the update affects system behavior, confinement policy, or the handling of existing local profiles.

Potential risks to consider:

• policy changes can alter how existing applications are confined;
• file layout changes can break packaging scripts or installed file lists;
• upstream build-system changes can affect reproducibility or subpackage split logic;
• broad policy updates may require review by security or desktop maintainers, depending on where the package is used.

Build and verification checklist

For RPM maintenance, a practical checklist is:

1. Review upstream release notes, tags, or commit history for packaging-relevant changes. (gitlab.com)
2. Verify that the SOURCES/ manifest files still match the expected upstream inputs.
3. Confirm that the spec file applies cleanly with the current patch set.
4. Run the package build in a clean mock or equivalent build root.
5. Check build logs for missing files, failed tests, or unexpected feature toggles.
6. Inspect the produced RPMs for file ownership, permissions, and subpackage split.
7. Validate package metadata, dependency declarations, and license fields.
8. If the package installs policy, run a basic functional check on a test system or container before pushing.
9. Compare installed files against the spec and repository metadata to make sure no unexpected paths were added or removed.

References

• AppArmor project on GitLab
• AppArmor website
• AppArmor project overview in Launchpad

Russian documentation

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

Dist-git repository notes

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