security · the whole picture
Odyssey is maintained by one anonymous person. It makes no difference whether I'm called John or Giovanni — you don't need to know my name. Trust is not based on identity. It is based on reliability, and reliability is based on verifiability.
Nothing on this page asks for your faith. Every claim below can be checked by you, by anyone, with public tools I do not control. This is what a serious project owes its users — stated plainly, limits included.
The full security model below, without marketing. Most distributions offer one or two of these layers; Odyssey combines all of them — open recipes, reproducible builds, two cross-signed keys, a public transparency log, per-package malware scanning, and an off-server monitor that warns you, not just me. Read any section, or verify any claim yourself.
01 · PHILOSOPHY
Most distributions ask you to trust a name, a foundation, a brand. Odyssey can't do that — it has no name to offer. So it does the opposite: it removes the need to trust the maintainer at all.
Several independent mechanisms make this real. Open recipes let you read how every package is built. Reproducible builds let you rebuild a package and confirm it matches, byte for byte. A public transparency log, run by the Linux Foundation, records every signature permanently where anyone can audit it. And two cross-signed keys make any key compromise both visible and impossible to exploit silently. None of these depend on believing me.
The honest consequence: an anonymous maintainer who lets you verify everything is more accountable than a named one who asks you to take their word. You don't know who I am. You know exactly what I do.
02 · KEY MANAGEMENT
Odyssey uses two signing keys. Both belong to the same maintainer and together form one trust chain. Neither is tied to any personal identity.
.sig2 files). xbps refuses any unsigned package.
.cosign.bundle files).
STORAGE
Private keys live offline: on an encrypted USB stick kept disconnected, with a second copy in an encrypted personal vault. They are never on the server, never in a public repository, never in plaintext. The passphrase is held in a password manager, not reused anywhere else.
ROTATION
The keys are not rotated on a schedule. For a single-maintainer project, scheduled rotation adds ceremony without adding safety. The keys are long-lived and are only replaced if lost or compromised — stated openly, rather than promising a rotation that wouldn't happen.
IF A KEY IS LOST
A new key is generated, its public half is published here and on Forgejo, and the change is announced in a notice signed by the surviving key. Old public keys are kept on this page, marked retired, so previously signed packages remain verifiable.
THE PUBLIC KEYS
Both keys, and the attestation that links them, are published at code.odysseylinux.org/nobody/odyssey-keys.
03 · MUTUAL ATTESTATION
This is the part most independent distributions don't do. Odyssey's two keys cross-sign each other: a single statement is signed by both the RSA repository key and the ECDSA cosign key, so each one cryptographically vouches for the other. That single design choice gives two concrete guarantees.
01 · DETECTION
Every signature lands in a public, append-only log run by the Linux Foundation. A signature I never made would appear there for everyone to see. Misuse cannot stay silent.
02 · REVOCATION
If one key is stolen, the second key signs an authoritative revocation notice. An attacker holding one key cannot forge that notice — they would need both. Trust can be re-established without trusting me.
Together: a stolen key can't act unseen, and it can't prevent its own revocation. That is verifiable detection of compromise — not a promise that it won't happen, but a guarantee that if it does, you'll know and the damage can be cut off cleanly, by mathematics rather than by my word.
VERIFY THE ATTESTATION YOURSELF
The signed statement and both signatures are public. Confirm that each key really vouches for the other:
# get the files
git clone https://code.odysseylinux.org/nobody/odyssey-keys
cd odyssey-keys
# 1 — verify the cosign (ECDSA) signature + Rekor record
cosign verify-blob --key cosign.pub \
--bundle odyssey-key-attestation.txt.cosign.bundle \
odyssey-key-attestation.txt
# 2 — verify the ether-repo (RSA) signature
base64 -d odyssey-key-attestation.txt.xbps-sig.b64 > sig.bin
openssl dgst -sha256 -verify ether-repo.pub \
-signature sig.bin odyssey-key-attestation.txt
Both must pass. If they do, you have proof — not my assurance — that these two keys belong together. Trust a new or replacement key only if it is announced through both this page and the Forgejo repository.
04 · SUPPLY CHAIN
Every package carries a signature recorded in Sigstore's Rekor —
an append-only public log operated by the Linux Foundation. You verify it with
cosign, a standard tool used by npm, PyPI and Kubernetes,
written by Sigstore, not by me.
DOWNLOAD THE PACKAGE AND ITS BUNDLE
curl -LO https://repo.odysseylinux.org/odyssey-repo/x86_64/PACKAGE.xbps curl -LO https://repo.odysseylinux.org/odyssey-repo/x86_64/PACKAGE.xbps.cosign.bundle
VERIFY SIGNATURE + TRANSPARENCY LOG
cosign verify-blob --key cosign.pub \
--bundle PACKAGE.xbps.cosign.bundle \
PACKAGE.xbps
# -> Verified OK
If it returns Verified OK, the package is exactly what I signed, and that
signature exists in the public log. You can also read the log entry directly — pull
its index from the bundle and query rekor.sigstore.dev.
That record is permanent. I cannot remove or alter it.
WHAT EACH PACKAGE GUARANTEES
Upstream checksum is pinned in the public recipe — you get the genuine upstream binary. The repackaging is reproducible — rebuild it and the hash matches, proving nothing was injected during packaging. The recipe is public on Forgejo — you see how.
ONE COMMAND, AND INDEPENDENT REBUILDS
To make this effortless, every package's hash is published in a single
signed manifest — odyssey-challenge.json —
and a small tool, odyssey-challenge, verifies any package against it
in one command. The same tool lets anyone rebuild a package from source and
publish their own signed attestation that the hash reproduces — independent confirmation
that doesn't rest on my word at all.
05 · PACKAGE SCANNING
A signature proves a package is authentic. It says nothing about what the package does. So before any package is signed and published, it passes through an automated safety scan — a layer that reads the contents and looks for malicious behaviour, not just confirms the wrapper is sealed.
WHAT IT INSPECTS
The scan runs in layers: pattern matching with YARA, binary capability analysis with capa, an inventory of every installed file and embedded network address, and — most importantly — a diff against the previous version of the same package. It looks for credential and SSH-key access, reverse shells, download-and-execute install scripts, cryptocurrency miners, persistence hooks, and hardcoded command-and-control addresses.
THE POISONED-UPDATE DEFENCE
The version diff is the part that matters most. Every update is compared to the last published build: if a routine new version suddenly gains a capability it never had — reading SSH keys, contacting a new domain, rewriting an install script — the scan flags it. This is the defence against the hardest attack to spot: a trusted package that ships malicious code inside what looks like an ordinary update.
THE GATE
If a package is flagged, it is not signed and does not enter the repository. Full stop. The block happens before publication, so a suspect package never reaches you.
NOTHING IS HIDDEN — EXCEPT THE RULES
The full scan record is public, flags included. If a flagged package later appears as cleared, it means a human examined it by hand and verified the alarm was a false positive — never the system quietly overriding itself. But the exact rules, thresholds and patterns are deliberately not published: making the detection logic public would let an attacker craft a payload to slip through it. The tools are open; their tuning is not. That is operational security, stated openly rather than hidden.
06 · CONTINUOUS ENFORCEMENT
Cryptography and two cross-signed keys are necessary — but on their own they are not enough. Signing a package proves what it is; it does not, by itself, tell anyone when something has gone wrong. A repository can be tampered with; a key can be abused — far harder than people think, but no honest project calls it impossible. The questions that actually matter to you are simpler: who notices, how fast, and what happens to users in between?
Odyssey's answer is an enforcement layer that runs continuously, and runs independently of the servers it watches.
OFF THE SERVER, ON PURPOSE
The monitor does not run on the machine that hosts the repository. That would be pointless — whoever compromised the server would compromise the watchdog along with it, and could simply switch off the alarm. It runs on separate infrastructure, holds its own copy of the public keys, and believes nothing the package server tells it except what verification proves.
WHAT IT CHECKS, EVERY FEW HOURS
On a fixed schedule it re-fetches every covered package and verifies its hash
against the signed manifest and its cosign signature
against the public key — and it checks the state of the signing keys themselves.
A tampered package, a broken signature, an unexpected key: any of these is a failure,
and a failure is never silent.
01 · ALERT
A maximum-priority alert hits every mailbox I keep, with an escalation that places a direct call to my personal number. There is no path where a compromise sits unnoticed for long.
02 · RESPONSE
The repository goes down, keys are rotated, credentials changed, affected signatures revoked, and clean packages regenerated from source. Containment first; restoration second.
The window between a compromise and the response is measured in hours, not weeks. For an attacker that turns an already hard target into one with almost nothing to gain: the cost of breaking in stays high and the payoff expires fast.
USERS ARE WARNED, NOT JUST ME
The alerts aren't only mine to receive. Anyone running Odyssey can opt in from the Software Center: if the monitor ever reports a compromise, subscribers get the same notification by email, immediately. You don't have to follow the project to learn that something went wrong — it comes to you.
SEE IT FOR YOURSELF
The latest result is public, always. The status page shows the current integrity verdict and when the last check ran — so you can confirm the system is being watched, rather than take my word that it is.
07 · INFRASTRUCTURE
Odyssey's public services all run over TLS. The site and Forgejo use Let's Encrypt; the package repository sits behind a CDN, which also keeps the origin address private.
Every Odyssey domain enforces a modern TLS configuration and a set of HTTP security headers — HSTS, frame denial, content-type pinning, a strict content policy on the static site. Login endpoints are rate-limited against brute force.
08 · PRIVACY & DATA
The operating system ships with zero telemetry — nothing phones home. The website does not track or profile visitors: no analytics, no third-party scripts, no advertising, ever.
The forum keeps only the minimum needed to run accounts — an email address and a hashed password. No behavioural tracking, no data sold or shared. Odyssey accepts no sponsorships and no paid placements of any kind.
09 · VULNERABILITY DISCLOSURE
Report it privately — do not open a public forum thread, since that would expose the issue before it can be fixed. Write to:
Include what you found, how to reproduce it, and how I can reach you. As a single maintainer I can't promise a fixed timeline, but serious reports are taken seriously and handled as fast as one person honestly can. Good-faith research is welcome.