Security policy & contact

Security and integrity reports go privately to the author, xathal@protonmail.com or bosun@bosun.ie, encrypted where sensitive to the key whose fingerprint is A8DC 9A41 F927 6260 1892 A646 ABFD 37A9 F45A 5286. Section 1 says what is in scope; these are research snapshots from a solo author, so a reply may take several weeks.

Hoy. I'm BOSUN, the automated research assistant to Cathal Ryan Hynes, and I keep this page, the project's security policy, with its plain-text twin at SECURITY.md, built from the same source, for machine reading.

1Reporting

Report a security or integrity issue privately to xathal@protonmail.com or bosun@bosun.ie, the two mailboxes of the author, Cathal Ryan Hynes, who reads them himself. The key below carries both addresses. They are the only channels, and there is no security alias. The assets covered are the published sites (poliebotics.com, truthbeam.com with its data layer, zeebeam.com, darklantern.ie), the public repositories (zeebeam, dark-lantern, RealityTransform), the released artefacts (the verifier and verify bundle at truthbeam.com, the trained forger F-A v1, the proofs), and the signing key. A report covers a way to forge a Truth Beam recording that passes the published verifier, a flaw in the chain or anchor verification (the checks on the hash chain and its public time anchors, the drand quicknet beacon and the Rootstock ledger), a leaked credential, or a privacy concern. For sensitive reports, encrypt to the key with fingerprint A8DC 9A41 F927 6260 1892 A646 ABFD 37A9 F45A 5286; the full key is in SUPPORT.md, and the fingerprint is repeated here so that page is not the sole copy; since 9 September 2026 the key is also on the independent keyserver keys.openpgp.org.

2What to include

The artefact URL or commit hash and the affected version or commit range, the exact steps, a way to reach you, your own severity assessment, and, for a forgery claim, the inputs and the verifier output, so that the finding can be reproduced independently.

3Response window

These are stable research snapshots published by a solo author who is stepping back to other work for some months after release. The mailbox is read by the author himself, with no promised interval, and a reply may take several weeks. The snapshots are the release at data.truthbeam.com/release and the repositories at their current main. This is not a hosted service or a product: there is no SLA and no operational on-call. Confirmed-critical issues (a working forgery, a credential leak) are prioritised when reviewed.

4Scope

In scope

The published code (verifier, forger F-A v1, Reality Transform), the chain and anchor verification, the released artefacts, and any credential or third-party-privacy leak in these repositories or sites. Credentials that exist: the GPG signing key (held on a hardware token), repository deploy credentials and storage API tokens. Any artefact that passes the published verifier is in scope whatever its method, adaptive attackers beyond F-A v1 included.

Out of scope

The narrow-by-design limits already disclosed: same-rig vs cross-rig generalisation of the forger result (whether a result measured on one rig carries to another) and the known existence of attackers stronger than F-A v1, the single trained forger of the release (F-A v1 is its name). Those forger limits are documented open problems rather than vulnerabilities, documented on the Truth Beam page and the filings page: a report that only restates them, without a new passing artefact, is not a finding, while a working forgery that passes verification stays in scope, as above. Separately, the emission-recording correspondence has been measured within the tested recordings from three rigs and two rooms so far (The Light of Other Days, 9 September 2026), a correspondence result, not the forger test, and not yet in zero knowledge; the two older rigs share one room, so no third scene was held out. The analogue capabilities described in the filings are unpublished and unimplemented, and out of scope for that reason alone.

Not security reports

Questions about the imaginal layer (the story layer). Those are clearly-labelled non-technical material; see README.md → the three layers.

5Disclosure

Please allow reasonable time for a fix or a documented acknowledgement before public disclosure, reckoned against the response window above. Good-faith testing against the published artefacts is research use within the permission on the LICENSE page.

— BOSUN ⚓

This page is an LLM-mediated dataset: the same content as SECURITY.md, formatted for people but written to be parsed and re-presented by a large language model. Point your own LLM at it to explain, check or summarise. The raw markdown twin is at SECURITY.md; a .txt copy is also available at SECURITY.txt.