GOpenCSR security and disclosure policy

How this relates to the Gelhaus Solutions policy

GOpenCSR is covered by Gelhaus Solutions' vulnerability disclosure policy, and everything in it applies here: how to report, the response times, the safe harbour, credit and identifiers. This page adds what is particular to GOpenCSR: what is in scope, what matters most, and what testing must never do. GOpenCSR signs people in to GOpenCDR, GOpenCNR and itself, approves Tier 0's changes, runs the councils and keeps the one transparency log, so a flaw here reaches all three services, and people who never agreed to be part of a test depend on it.

GOpenCSR is part of the scope of the Gelhaus Solutions CVE Numbering Authority programme, with full coverage, and identifiers are assigned as the disclosure policy describes.

How to report

Email contact@gplatform.org, or file the report through GAdvisory. Both start the same process. For anything sensitive, encrypt with the key whose fingerprint is on the disclosure policy. Please do not open a public issue.

Put "GOpenCSR" in the subject line, and "urgent" as well where the report concerns sign-in, four-eyes approvals, the transparency log or a signing key. Those are read first.

GOpenCSR's security.txt, at https://csr.gplatform.org/.well-known/security.txt, points to this page, and so does the footer of every GOpenCSR page.

What is in scope

• The portal at csr.gplatform.org, and the API front door at csr.gplatform.org/api/{cdr,cnr,csr}/v1 with its API keys.
• Sign-in and the OpenID Connect provider through which GOpenCDR and GOpenCNR sign people in: passwords, passkeys, recovery, sessions and tokens.
• Step-up and the signing step, including automation keys registered under a passkey.
• Four-eyes approvals and solo mode.
• The councils and motions machinery: seats, ballots, sponsor votes and their secrecy, confidential motions and confidential votes, community motions and petitions, and the Joint Council.
• Cases, sanctions screening and its holds, and the abuse relay at relay.csr.gplatform.org.
• Audiences.
• Consent records.
• The transparency log at csr.gplatform.org/tlog, its checkpoints, its verifier and its witnesses.
• The shared code GOpenCSR publishes for the other services: the agent core library that GOpenCNR's agents and GOpenCDR's mirror agent are built on, and the identity and policy clients.

What we most want to hear about

1. Any way into somebody else's account: through sign-in, recovery, passkeys, sessions or the OpenID Connect flow, including any way to make GOpenCDR or GOpenCNR accept a code or token issued for somebody else or for another service.
2. Any way around step-up or the signing step: acting where a fresh passkey is required without one, or getting a change signed that differs from what the signing step showed.
3. Any way to approve one's own four-eyes request, to get a Tier 0 change through without the approval it needs, or to make an approval given alone appear without its "decided alone" flag.
4. Any way to make the transparency log show different histories to different people, or to make a verifier accept an entry or a checkpoint it should refuse.
5. Any way to learn the members of an audience, or a network endpoint, from the salted hashes in the log or from anything else GOpenCSR shows, or for one member of an audience to learn who else is in it.
6. Any way to read a confidential motion, a sealed vote or the name of a sponsor before the council's next session.
7. Any way for an API key to gain Tier 0 permissions, to decide an approval or to manage keys.
8. Any way for standing earned in one product to count toward another product's seats, votes, candidacies, support or petitions.
9. Any way to use the abuse relay to learn a holder's real address, or to unmask a holder in any other way.
10. Any way for anybody but the holder and Tier 0 to learn that a sanctions review exists, or to see a holder's legal name and country or a screening outcome tied to a holder.

Rules for testing

GOpenCSR serves people who never agreed to be tested on, and much of what it records is public and permanent. Research here has rules of its own, on top of those in the disclosure policy.

• Test only with your own accounts, your own holders and your own resources.
• No denial of service. Do not load-test, flood or try to exhaust the portal, the API front door, the sign-in endpoints, the transparency log or the relay, and do not create accounts in bulk.
• Do not test against other members' accounts, holders, resources, audiences, cases or relay addresses, and do not send test mail through another holder's relay.
• Keep in mind what cannot be taken back. A signed change or a ballot you cause is in the transparency log for good, and a comment, a motion or support sent to a council is public. Use as few of them as you need to show the problem, and ask us before you test anything that would reach a live council.
• Access only what you need to show the problem. If you reach other people's data, stop, keep none of it, and tell us.
• No social engineering of our staff, of council members or of other members, no physical attacks, and nothing aimed at our own hardware, including the key store and the network behind it.
• Keep the details private until the coordinated date.

Research within these rules is welcome, and the safe harbour in the disclosure policy covers it.

What is out of scope

• Findings in third-party software we run unmodified, such as PostgreSQL, Temporal, HashiCorp Vault, Next.js, Tessera or Stalwart. Report those to the project; we will help, and we will apply the fix.
• Findings in what GOpenCDR or GOpenCNR do with a request once it has passed the front door, and in the programs they build on the agent core. Those fall under the GOpenCDR security and disclosure policy and the GOpenCNR security and disclosure policy. If you are not sure where a finding belongs, send it here, and we pass it on.
• Findings that need an already compromised device, administrative access to a router, hub or mirror you do not operate, or a victim who installs something unusual, unless GOpenCSR makes them worse.
• Output of automated scanners without a demonstrated impact, missing headers without an impact, and rate limits working as described.
• Abuse by a holder, such as phishing under a name or scanning from an address, which goes to abuse@gplatform.org under the abuse and sanctions policy.

If a key may be compromised

If you believe one of GOpenCSR's keys may be exposed, such as the transparency log's checkpoint key, the key that signs sign-in tokens, or the secrets behind API keys and audit records, write at once, with "Key" in the subject line. Tier 0 can act immediately under its emergency procedure, which may only suspend or tighten, never loosen. Every emergency action is published in the transparency log and reviewed afterwards.

If it is your own passkey or automation key, remove it from your account at once, and tell us if a change you did not make was signed with it.

Problems that are not vulnerabilities

A sign-in that fails, a checkpoint that stops advancing, a witness that stops cosigning or a mail that never arrives is not always a vulnerability, but we want to hear about it just as quickly. Write to the same address.