Konsensus/Hukukça handles identity-adjacent qualification evidence and publishes cryptographically verifiable voting records. Report suspected vulnerabilities privately before opening an issue or publishing technical details.
Email security and privacy reports to gizlilik@hukukca.org.
Include, when safe:
- a concise description and affected component, route, protocol artifact, or release;
- reproducible steps using synthetic data;
- the likely confidentiality, integrity, availability, or verification impact;
- the exact public commit/deployment/policy identifiers involved; and
- redacted logs or screenshots only when necessary.
Do not send live credentials by ordinary email. In the initial report, omit or redact database URLs, API tokens, session cookies, OAuth codes, verifier state, one-time codes, private email receipts, private keys, passkey material, witness run tokens, canary secrets, and non-public personal records. The maintainers can arrange a safer transfer method if evidence is required.
Do not test against another person's account, qualification record, vote, or email address. Do not degrade production availability, trigger bulk email, alter public records, rotate keys, or test cloud IAM without explicit written authorization.
Until the first stable release, only the commit currently serving production
and the latest main branch are supported. Include the source SHA from
/.well-known/hukukca-source.json when reporting a production issue. A branch
or preview deployment may contain unreleased changes and is not automatically a
supported production version.
Reports are especially useful when they demonstrate:
- bypass of authentication, origin checks, rate limits, or administrator authorization;
- acceptance of a vote without the required active eligibility, challenge, user confirmation, passkey delegation, or valid signature;
- replay, cross-question/cross-choice substitution, protocol downgrade, or ambiguous policy/key selection;
- forged or insufficiently checked Confidential Space PKI attestation, receipt, release canary, eligibility assertion, acceptance, adjudication, or tree head;
- Merkle inclusion/consistency errors, transparency rollback/split-view acceptance, or witness monotonic-state loss;
- ability to rewrite or delete published proof evidence or closed tallies;
- use of exportable or unauthorized signing keys in production;
- source/build/deployment evidence that accepts omitted, added, or altered runtime bytes;
- a workload-identity or IAM condition that permits an unexpected repository, workflow, environment, deployment, service account, or principal;
- database role/RLS/default-privilege paths that exceed the documented runtime, migration, or backup contract;
- leakage of private qualification material, claimed emails, session data, authentication codes, or secrets; or
- deletion/account flows that destroy evidence needed to verify an already published vote.
Confidential Space proves execution policy and email control inside the pinned workload. It does not perform or attest the public bar-registry lookup. The eligibility assertion proves which content-addressed evidence and reviewer decision the configured authority signed; reviewers must still evaluate that authority and evidence under the published policy.
A valid inclusion proof establishes membership in one signed transparency tree head. It does not establish global freshness. Compare against independently witnessed later heads before relying on a latest-state claim.
The production Vercel workload identity identifies the configured team, project, and production environment. It does not currently identify an exact deployment digest or Git commit. The guarded release and public provenance records independently bind provider-stored bytes and the promoted alias; report any path that lets an unverified deployment use signing authority or serve as a trusted rollback target.
The project does not promise voter anonymity. Public identity and registry evidence are part of the Hukukça qualification policy; private operational receipts and authentication material are not.
Do not treat a policy, source hash, public key, or witness key served only by the same potentially compromised site as an independent trust anchor. Obtain pins from the reviewed source release or another independently administered channel.
The current private repository history must not be published in place. The
publication procedure and remaining white-label boundaries are documented in
docs/public-repository-readiness.md.
Once a public source release exists, compare its exact source and artifact
records with the live /.well-known/ records rather than assuming that the
default branch is what production runs.
Maintainers should acknowledge a report without restating sensitive evidence, preserve relevant immutable records, assess whether vote publication or key rotation must be frozen, and coordinate remediation before disclosure. Suspect transparency or signing-key incidents must preserve witness state, signed heads, release records, aliases, IAM evidence, and provider logs before recovery work.
Operational runbooks live in: