Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/AnimatedGTVR/abora-os/llms.txt

Use this file to discover all available pages before exploring further.

Abora OS follows a single supported release line model. Security fixes are applied to the current stable release and published in the next release — there is no backporting to older version lines. If you discover a security issue, please work with the maintainers privately before sharing details publicly so there is time to prepare and publish a fix first.

Supported Versions

Abora is currently on the DENALI 3.1.x line. Only this release line receives security fixes and vulnerability reports.
VersionSupported
3.1.x✅ Yes
v2.x❌ No
v1.x❌ No
Older releases❌ No
In practice this means the latest 3.1.x release is the one that receives fixes. If you are running an older version, upgrading to the current 3.1.x release is the appropriate remediation path.

Reporting a Vulnerability

Do not post full exploit details, proof-of-concept code, or reproduction steps in a public GitHub issue. Doing so gives attackers a window before a fix is available.
1

Use GitHub private vulnerability reporting

The preferred path is GitHub’s built-in private vulnerability reporting for this repository. Navigate to the Security tab on the Abora OS GitHub repo and select Report a vulnerability. This keeps the report visible only to maintainers until a fix is published.
2

Contact maintainers directly if private reporting is unavailable

If private vulnerability reporting is not enabled for the repository, reach out to the maintainers through the main project contact path before sharing any details publicly.
3

Include all relevant detail in your report

A thorough initial report reduces the number of follow-up questions and speeds up the response. Include:
  • Affected version — which 3.1.x release you were running
  • Where the issue occurs — the component, script, or configuration path involved
  • Steps to reproduce — the minimum sequence of actions that triggers the issue
  • Supporting evidence — logs, screenshots, or a proof of concept that helps explain the impact
  • Scope — whether you believe the issue affects the live ISO, the installer, the updater (sudo nixos update), or the installed system after boot

What to Expect After Reporting

Once a report is submitted, the standard response process is:
The maintainers will acknowledge receipt of the report within 7 days. If you do not hear back within that window, follow up through the same private channel you used to submit the report.
If the report lacks detail needed to reproduce or assess the issue, the maintainers will ask follow-up questions through the private reporting channel. Please keep the conversation in that channel until a fix is ready.
Once the report has been reviewed, the maintainers will either accept it and work on a fix, propose a mitigation if a full fix is not immediately feasible, or explicitly decline the report with an explanation (for example, if the behaviour is intentional or outside the threat model).

Fix and Disclosure Policy

If a report is accepted:
  • The fix targets the current supported release line3.1.x at present
  • The fix is published in the next release of that line
  • Disclosure of the vulnerability details happens at or after the release that contains the fix
Abora does not currently issue separate security advisories outside of release notes. Fix details will appear in the release notes for the version that resolves the issue.

Build docs developers (and LLMs) love