Repository navigation
docs: a regulated-lab pack under docs/regulated - #109
Merged
Merged
Conversation
Seven documents for an ISSM or an assessment team deciding whether Trinity can run inside an accredited boundary. Documentation only: no lib/ change, no behaviour change, no control asserted that the tree does not already implement. The rule the pack is written to is that every claim names a path in this repository and anything without one says NOT IN TREE. A census over the finished files resolves 59 distinct cited paths and all 59 exist. Three passages are quoted verbatim from the tree rather than paraphrased: the two mix task moduledocs and the CMVP paragraph in docs/fips-leg.md. What the pack refuses to claim, in its own words: not FedRAMP authorized, not CMMC certified, not a HIPAA attestation, and NIST has evaluated nothing here. Where docs/fips-leg.md cites CMVP certificate #4857 it is a Red Hat module's certificate, cited so a reader can check their own host, and that document already says Trinity does not claim the binaries are the same or claim a validation. crypto-inventory.md repeats the qualification rather than softening it, and every certificate cell reads UNKNOWN. The honest gaps are written as gaps. There is no allow-list of approved models in the tree, so data-flow.md says enforcement is configuration control and egress policy rather than code. No KMS or HSM adapter exists behind the key seam. Nothing forwards logs. No witness or transparency service exists, so a reader who does not trust the host cannot detect backdated forgery. incident.md leaves every contact as TODO, deliberately: a blank gets filled and an invented name gets used. authorization-boundary.md states the standalone limit rather than leaving it to be discovered: Trinity is judge, actor and scribe in one process, which is strong evidence to a reader who accepts the host was not compromised and no evidence at all to one who does not. Signed-off-by: Ayla Croft <aylacroft@proton.me>
"The adapter itself is NOT IN TREE" was too strong and it was wrong. An adapter does ship: Trinity.Authority.Local. Grepping the behaviour resolves two files, lib/trinity/authority/local.ex and a test fixture at test/support/authority/adapters.ex. Corrected to: the seam is in the tree, selection happens once at boot from TRINITY_AUTHORITY, one implementation ships and it is Local, and no adapter other than Local ships in this tree. An external authority adapter lives in another repository and nothing in mix.exs or mix.lock depends on one, which an assessor can confirm from the dependency list rather than from the page. Checked while correcting it: the only occurrence of the platform name anywhere in mix.exs, mix.lock, config/ or lib/ is the forbidden-name list inside the name check that exists to fail the build if such a name appears. Not a dependency. The parallel claim about the key seam holds unchanged: one implementation of Trinity.Keys, lib/trinity/keys/local.ex, so no KMS or HSM adapter is in the tree. README gains one sentence: this pack documents the gap; it does not close it. Signed-off-by: Ayla Croft <aylacroft@proton.me>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Seven documents for an ISSM or an assessment team deciding whether Trinity can run inside an accredited boundary. Documentation only. No
lib/change, no behaviour change, no control asserted that the tree does not already implement.The rule it is written to
Every claim names a path in this repository. Anything without one says NOT IN TREE.
A census over the finished files resolves 59 distinct cited paths, and all 59 exist. Three passages are quoted verbatim rather than paraphrased, checked word for word with whitespace normalised: the two mix task moduledocs and the CMVP paragraph in
docs/fips-leg.md.What it refuses to claim
Not FedRAMP authorized. Not CMMC certified. Not a HIPAA attestation. No SOC 2, no HITRUST, no third-party audit. Sudo Apt Holdings LLC is not a Business Associate by virtue of anyone running the binary. NIST has evaluated, certified and endorsed nothing here.
Where
docs/fips-leg.mdcites CMVP certificate #4857, that is a Red Hat module's certificate, cited so a reader can check their own host. That document already says Trinity does not claim the binaries are the same or claim a validation.crypto-inventory.mdrepeats the qualification rather than softening it, and every certificate cell reads UNKNOWN.The gaps are written as gaps
data-flow.mdsays so, and says enforcement is configuration control and egress policy rather than code.incident.mdleaves every contact as TODO, deliberately. A blank gets filled; an invented name gets used.The one paragraph an assessor should read first
authorization-boundary.mdstates the standalone limit rather than leaving it to be discovered: Trinity is judge, actor and scribe in one process. That is strong evidence to a reader who accepts the host was not compromised, and no evidence at all to one who does not. Regulated use requires an external authority adapter, which is NOT IN TREE and is downstream work per ADR-0008.Files
README.mdauthorization-boundary.mdcustomer-responsibility-matrix.mddata-flow.mdincident.mdreceipts-verify.mdcrypto-inventory.mdNot merged, as instructed.