From 11d5d2b9536433e5d9a0cb636aa7221dcfefd28e Mon Sep 17 00:00:00 2001 From: thisisjun786 <259586770+thisisjun786@users.noreply.github.com> Date: Mon, 7 Sep 2026 13:44:08 +0000 Subject: [PATCH] Prepare public contribution and security reporting guidance --- .github/README.md | 26 ++++++++++ README.md | 12 ++--- SECURITY.md | 39 +++++---------- docs/CI.md | 46 ++++++++++-------- docs/PUBLICATION.md | 116 +++++++++++++++++++++----------------------- docs/VALIDATION.md | 21 +++----- 6 files changed, 133 insertions(+), 127 deletions(-) create mode 100644 .github/README.md diff --git a/.github/README.md b/.github/README.md new file mode 100644 index 0000000..f614be3 --- /dev/null +++ b/.github/README.md @@ -0,0 +1,26 @@ +# Contributing to Lina + +[POLICY](../POLICY.md) is the authority for development, checks, merges and +releases. Start with [CONTRIBUTING](../CONTRIBUTING.md) for setup and verification; +[the project README](../README.md) explains Lina and how to run it. + +- [Open an issue](https://github.com/thisisjun786/lina/issues/new/choose) for a bug, + feature, compatibility report or design decision. The [issue forms](ISSUE_TEMPLATE) + show the information to include; small fixes do not require an issue first. +- [Open a pull request](https://github.com/thisisjun786/lina/compare) + targeting `dev`. Follow the [PR template](PULL_REQUEST_TEMPLATE.md): explain the + problem, resulting behavior, checks actually run and material limitations. +- Report vulnerabilities through the private route in [SECURITY](../SECURITY.md), + keeping exploit details and user data out of public issues and logs. + +`dev` is the default integration branch. Behavior changes start with a failing +regression test. Before merging, the current candidate must pass `dev-gate`, be +up to date with its target, have no conflicts and have resolved review conversations. +Use merge commits only; do not bypass protection. Required approving reviews are +zero, while confirmed defects still need resolution. + +[CI operation](../docs/CI.md) explains the checks and branch protections; +[validation](../docs/VALIDATION.md) defines their acceptance limits. A future +same-repository `dev -> main` promotion requires explicit owner instruction, +release notes and `release-gate`. Source checks do not authorize publication or +deployment. diff --git a/README.md b/README.md index e3a96ba..b8189d0 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,6 @@ LINA는 Codex를 실행 엔진으로 사용하는 개인 에이전트 시스템 하나의 장기 대화를 유지하며, 별도의 Codex 코딩 작업을 관리합니다. 프로바이더 계정, 인증 정보, 사용 가능한 모델 목록은 OpenCodex에서 관리합니다. -현재 공개 전 로컬 소스 후보이며, 이 준비 작업에서 저장소나 릴리스를 공개하지 않았습니다. 개발·머지 규칙은 [POLICY.md](POLICY.md), 기여 절차와 이슈·PR 작성법은 [CONTRIBUTING.md](CONTRIBUTING.md), CI 구성과 GitHub 적용 절차는 [CI 안내](docs/CI.md)에 있습니다. 기본 런타임 구조는 [Codex 실행 구조](docs/CODEX_RUNTIME.md)에서 확인할 수 있습니다. @@ -191,7 +190,7 @@ bun run lint 확인한 외부 프로젝트의 버전과 라이선스, 서비스 사용과 코드 재배포·수정의 구분은 [외부 소프트웨어 고지](THIRD_PARTY_NOTICES.md)를 참고하세요. -## 라이선스와 공개 준비 +## 라이선스와 출처 Lina의 자체 소스 코드·문서·유지관리자가 작성한 페르소나 프리셋 텍스트와 확인된 아바타 9개·앱 아이콘 2개는 보유 권리 범위에서 @@ -205,8 +204,7 @@ Lina의 자체 소스 코드·문서·유지관리자가 작성한 페르소나 사용자의 대화·메모리·인증 정보와 개인 설치에서 변경한 페르소나는 이 소스의 라이선스 부여나 공개 범위에 포함하지 않습니다. -이 소스는 **공개 전 로컬 후보**입니다. [공개 준비 체크리스트](docs/PUBLICATION.md)는 -권리·보안 신고 경로·개인 식별 정보 검토와 별도 공개 승인 조건을 기록합니다. -공개 대상은 개인 운영 이력과 기존 Git·호스팅 이력을 포함하지 않는 별도 검토된 소스여야 합니다. -취약점 제보는 현재 이용 가능한 경로와 제한을 설명한 [SECURITY.md](SECURITY.md)를 -따르세요. +Lina는 독립적인 소스 프로젝트입니다. 소스와 이력의 공개 범위, 권리·개인정보 검토 기준은 +[공개 안내](docs/PUBLICATION.md)에 있습니다. 소스 공개와 릴리스·배포는 별도 절차이며, +검증 결과는 해당 소스와 실행 환경을 기준으로 확인합니다. +취약점은 [SECURITY.md](SECURITY.md)의 비공개 경로로 제보해 주세요. diff --git a/SECURITY.md b/SECURITY.md index 75bbbba..fa85c7f 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,39 +1,26 @@ # Security reporting -This source candidate is prepared locally and has not been published by this preparation. There is no public security-support release -matrix or guaranteed response time. Include the affected commit or installed -release ID so the maintainer can reproduce a report against the right version. +Include the affected commit or installed release ID so the maintainer can +reproduce a report against the right version. There is no guaranteed response time +or security-support release matrix. ## Reporting route -When **Security → Advisories → Report a vulnerability** is available on this -repository's GitHub page, use it to submit a private report. GitHub documents the -[enablement requirement](https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/configure-vulnerability-reporting/configure-for-a-repository). - -No newly hosted repository or reporting feature has been activated by this local -preparation. A dedicated security email address is not designated here. - -Existing collaborators should contact the repository owner through the private -channel used to arrange their repository access and request a confidential -handoff before sending vulnerability details. If you have no such channel, do -not guess an address from commit metadata. This interim route applies during -private development; a public reporting feature is not required to continue -private preparation. - -At an explicitly authorized public visibility change, the maintainer must -immediately enable GitHub private vulnerability reporting, read back its enabled -state, and verify that the **Report a vulnerability** button is available to -reporters. These are coupled activation steps, not a promise that the feature is -already active. Do not announce public activation as complete until they pass. -If enablement fails, report public activation as incomplete and resolve the -failure before declaring it complete. See the -[publication checklist](docs/PUBLICATION.md) for the owner-controlled sequence. +Submit vulnerabilities through GitHub's +[private reporting form](https://github.com/thisisjun786/lina/security/advisories/new), +also reached through **Security → Advisories → Report a vulnerability**. + +If the form is unavailable, open an +[issue requesting a private contact route](https://github.com/thisisjun786/lina/issues/new) +without vulnerability details. Wait for a confidential handoff before sharing the +report. No dedicated security email address is designated here; do not infer one +from commit metadata. Do not put exploit details, credentials, private transcripts, or user data in public issues, pull requests, discussions, or CI logs. A repository issue is visible to its readers and is not a dedicated confidential reporting channel. -## What to include after arranging private contact +## What to include in a private report - Affected revision, operating system, runtime mode, and relevant dependency versions. - Minimal reproduction using synthetic data, expected and observed behavior, diff --git a/docs/CI.md b/docs/CI.md index 9050c4b..8149be9 100644 --- a/docs/CI.md +++ b/docs/CI.md @@ -1,7 +1,8 @@ # CI operation and activation [POLICY.md](../POLICY.md) owns the rules. This page maps those rules to commands -and GitHub settings. It is not evidence that remote protection is already active. +and GitHub settings. Keep verification evidence with the corresponding PR or +release record. ## Checks @@ -59,42 +60,47 @@ JavaScript or prove live exploitability. ## Activation -The local source candidate has no newly activated GitHub settings or hosted CI -results. For an explicitly authorized repository, configure and verify the -following target settings after the checked-in workflow is available: +`dev` is the default branch and the target for normal contributions. `main` has +not been created; it is reserved for a future owner-authorized release promotion. +Public source activation does not include creating `main` or promoting a release. + +Keep the following protection settings in place and verify them from GitHub +after any settings or visibility change: | Setting | `dev` | `main` | | --- | --- | --- | +| Protection mechanism | Classic branch protection | Active ruleset targeting `refs/heads/main` | | Required check | `dev-gate` | `release-gate` | | Check producer | GitHub Actions, app ID `15368` | GitHub Actions, app ID `15368` | | Up-to-date base and PR required | Yes | Yes | | Required approving reviews | 0 | 0 | -| Resolved conversations and admin enforcement | Yes | Yes | +| Resolved conversations | Required | Required | +| Bypass | Admin enforcement; no bypass | Zero bypass actors | | Force pushes and branch deletion | Blocked | Blocked | -Merge commits are enabled; squash/rebase merging and automatic merge are disabled. -Required linear history is off. These are intended settings; their presence in -this document does not establish remote enforcement or a green candidate. +The ruleset for future `main` is active even while the branch is absent. Its strict +`release-gate` requirement also applies when creating the branch; there is no +first-branch exemption or bypass procedure. -For a newly created repository, land the CI contribution files through a checked -PR, then apply the settings above and re-read them from GitHub. Bind checks to -GitHub Actions rather than accepting a matching check name from any producer. -Do not bypass a required check to bootstrap it. Setting the default to `dev` -exposes its contribution templates and makes integration the ordinary PR base. +Merge commits are the only enabled merge method. Squash/rebase merging, automatic +merge and required linear history are off. Actions use a read-only default token +and cannot create or approve pull requests. Bind required checks to GitHub Actions +so a matching name from another producer cannot satisfy protection. -Visibility remains a separate owner decision. Public activation must enable and -verify the confidential reporting route immediately; -see [publication preparation](PUBLICATION.md) and [SECURITY.md](../SECURITY.md). -Re-read protection after a visibility change. Admins who can edit repository -settings can change the policy itself; the restrictions above are not immutable. +Verify hosted checks against the actual PR candidate; checked-in workflows and +local results do not establish a hosted result. Public activation also requires +reporter-visible access to the private route in [SECURITY.md](../SECURITY.md), as +described in [publication guidance](PUBLICATION.md). Administrators with settings +access can change the rules themselves; the protections are not immutable. Before any merge, re-read the PR head/base, required checks, draft status, mergeability and unresolved conversations. Match the reviewed head when invoking the merge action (`gh pr merge --merge --match-head-commit ` is one option). Strict status checks cover target-branch movement; an expected-head argument alone protects only the source branch. Refresh checks when either input changes. -After promotion, reconcile the new `main` merge commit into `dev` through a PR -before the next promotion; do not use a direct push to synchronize branches. +After a future authorized promotion, reconcile the new `main` merge commit into +`dev` through a PR before the next promotion; do not use a direct push to +synchronize branches. ## Failures and changes to CI diff --git a/docs/PUBLICATION.md b/docs/PUBLICATION.md index 1624e8f..8131644 100644 --- a/docs/PUBLICATION.md +++ b/docs/PUBLICATION.md @@ -1,13 +1,10 @@ -# Publication preparation +# Public source and publication -Status: **LOCAL CANDIDATE — PREPARED FOR REVIEW, NOT PUBLISHED**. -This preparation does not create a GitHub repository, activate its settings or CI, -change visibility, publish an artifact, or deploy a service. Final candidate checks -and the exact publication action remain separate under [POLICY](../POLICY.md). - -Codex is the sole supported execution engine. Product contracts and future scope -are documented in [runtime](CODEX_RUNTIME.md), [plans](PLANNING.md) and -[validation](VALIDATION.md). +Lina is an independent Apache-2.0 project with Codex as its sole execution engine. +[POLICY](../POLICY.md) owns publication and release authority. This guide defines +what belongs in the public source and what evidence to retain when publishing it. +Product contracts and future scope are documented in [runtime](CODEX_RUNTIME.md), +[plans](PLANNING.md) and [validation](VALIDATION.md). ## License and provenance @@ -19,65 +16,62 @@ are documented in [runtime](CODEX_RUNTIME.md), [plans](PLANNING.md) and nine avatars and two app icons in the owner's 2026-09-07 attestation, to the extent of the rights held. Dependencies, upstream services, and third-party material retain their own terms. -- [Third-party notices](../THIRD_PARTY_NOTICES.md) pin the reviewed upstream +- [Third-party notices](../THIRD_PARTY_NOTICES.md) identify reviewed upstream sources and distinguish HTTP integration from copying or distributing software. They are a scoped record, not a complete transitive dependency or ancestry audit. -- [Persona provenance](../data/personas/README.md) explains the 18 original - source digests, current content digests, and the authored SOUL and CHARACTER modifications. - It also records the owner's explicit confirmation of directly creating/generating - all nine avatars and both app icons and holding their input rights. That - attestation and the scoped Apache-2.0 grant resolve the recorded image blocker. - Hashes identify the covered files; no creation tool or specific input is inferred. +- [Persona provenance](../data/personas/README.md) preserves original source + digests, current content digests, and authored SOUL and CHARACTER modifications. + It records the owner's confirmation of directly creating/generating all nine + avatars and both app icons and holding their input rights. Hashes identify the + covered files; no creation tool or specific input is inferred. - User conversations, memory, credentials, and adopted/customized personas in a user's installation are outside the project license grant and source export. ## Source and history boundary -This candidate contains portable product plans under `docs/plans`, authored source -resources and public third-party notices. Private operational records, session -handoffs, screenshots and archival repository references are excluded. Persona -provenance keeps original import digests; current digests identify edited bytes. -Synthetic fixtures and documented default/loopback configuration are examples, -not disclosures of a private installation. - -A clean working tree does not erase existing Git or hosting history. The export -must start from a separately reviewed root, without inherited commits, branches, -tags, reflogs, remotes, PRs, issues or Actions records. Preserve the original -private source and its backup separately. Do not merge, fetch or copy private -history or operational records into the public candidate. Ignore rules do not -untrack files already in the index: inspect the final tracked-file set explicitly. - -Detailed privacy scans, metadata comparisons and backup receipts stay outside -the candidate. Pattern scans are leads for contextual review, not proof that all -unknown identifiers or secrets are absent. Review all selected blobs, commit -identities, image metadata and any new hosting attachments before publication. -Keep required copyright, licensing and public source attribution intact. - -## Final review and activation - -Each unchecked item needs evidence for the exact final candidate. This page does -not inherit earlier test totals, hosted results or repository settings. - -- [ ] Verify source files, all local Markdown targets, 18 current persona digests, - retained original digests, image identity and distribution notices. -- [ ] Review current files and binary metadata for secrets and private identifiers; - verify generated operational records are excluded from the tracked export. -- [ ] Create and inspect the independent root history and commit identity; verify - no private history, remotes or additional refs enter the export. -- [ ] Run source, dependency, secret and isolated installation checks from - [VALIDATION](VALIDATION.md); retain exact-candidate evidence privately. -- [ ] Present the exact new-repository/publication operation for explicit owner - approval, preserving the original repository's private history. -- [ ] On authorized hosting, apply and read back default branch, merge methods, - required checks and protections using [CI activation](CI.md#activation). - New hosted checks must run against their actual candidate. -- [ ] At public activation, enable and verify the confidential reporting route - described in [SECURITY](../SECURITY.md), including reporter-visible access. -- [ ] Verify the published files and settings, and keep release promotion, - package/container publication and deployment within their separately approved scope. - -No new GitHub repository, settings, hosted CI result or public reporting route is -claimed by this local preparation. A failed activation step remains incomplete. +Publish portable product plans, authored source resources and public third-party +notices. Keep private operational records, session handoffs, screenshots and +personal environment metadata out of the source and hosting attachments. +Synthetic fixtures and documented default or loopback configuration must remain +clearly identifiable as examples. Preserve required copyright, licensing and +public source attribution. + +Public source history begins at an independently reviewed root. Do not import +private history or operational records into it. A clean working tree does not +establish that history is safe to publish: inspect the tracked-file set, commits, +identities, branches and tags, as well as PRs, issues, Actions logs and attachments. +Ignore rules do not remove already tracked files. + +Review selected files and binary metadata in context. Pattern scans identify +items for review; they cannot prove the absence of every unknown identifier or +secret. Keep detailed privacy findings and backup records outside the public +repository. Public evidence must be redacted without losing the information +needed to assess the result. + +## Review and activation + +Before publishing source or changing visibility: + +1. Review the exact files and history being published. Verify Markdown links, + persona digests, image identity, redistribution rights and retained notices + using [VALIDATION](VALIDATION.md). +2. Record source, dependency, secret and applicable installation checks against + that revision. Include commands, outcomes and limits; distinguish local checks + from hosted checks on the PR's combined merge candidate. +3. Confirm owner authorization for the publication action. Apply and read back + the default branch, merge methods, required checks and protections described + in [CI activation](CI.md#activation); recheck them after visibility changes. +4. Enable GitHub private vulnerability reporting and verify reporter-visible + access to the form linked in [SECURITY](../SECURITY.md). A configured setting + alone does not prove that a reporter can submit privately. +5. Inspect the published files and contributor entry points. Record the relevant + hosted results and settings verification without exposing private records. + +Retain evidence with the corresponding PR or release record. Report failed, +skipped and unrun checks distinctly; this guide does not replace those results. +Source publication does not authorize a release promotion, tag, package or +container publication, deployment, provider calls or changes to installed data. +Any such action follows its own owner authorization and acceptance evidence. ## Reproducible documentation checks diff --git a/docs/VALIDATION.md b/docs/VALIDATION.md index 2529c62..fb97d24 100644 --- a/docs/VALIDATION.md +++ b/docs/VALIDATION.md @@ -1,6 +1,6 @@ # Validation scope -This page defines reproducible checks and acceptance boundaries for the source candidate. It does not carry forward private session reports or assert that historical test totals, hosted checks, installed services or provider behavior validate this candidate. Publication remains pending under [PUBLICATION](PUBLICATION.md). +This page defines reproducible checks and acceptance boundaries for a source revision. Record results for the exact code and environment tested, and limit release claims to that evidence. [PUBLICATION](PUBLICATION.md) covers source review and publication requirements. ## Source checks @@ -16,7 +16,7 @@ bun scripts/ci/audit.ts bash scripts/ci/secrets.sh ``` -The history scanner requires readable Git history; a disconnected candidate without its first reviewed commit cannot use an empty history scan as proof. Scan candidate files separately during preparation, then scan the final export history and metadata. Dependency auditing queries the configured advisory source. Source tests use synthetic temporary data and local fakes; they do not qualify live model services. +The history scanner requires readable Git history; an empty or incomplete scan is not proof of a clean history. Inspect the final tracked files and metadata as well as the commits being published. Dependency auditing queries the configured advisory source. Source tests use synthetic temporary data and local fakes; they do not qualify live model services. Record the exact source revision or file digest set, command, exit code and material warnings with each result. Failed, skipped and unrun checks remain distinct. Hosted checks validate their combined merge candidate; local results do not activate GitHub protections. @@ -38,18 +38,13 @@ Live scripts under [scripts/qa](../scripts/qa) may require accounts, inference a ## Documentation and provenance -Check every local Markdown file target after moving plans. Persona source records keep the original `sha256` and verify current bytes against `currentSha256`; see the runnable check in [PUBLICATION](PUBLICATION.md). Preserve image and license bytes. Review identifying strings in context: synthetic examples, loopback/default configuration and public third-party attribution differ from personal environment records. +Check local Markdown targets and section anchors in changed documents. Persona source records keep the original `sha256` and verify current bytes against `currentSha256`; use the [reproducible check](PUBLICATION.md#reproducible-documentation-checks) for persona, avatar and icon digests. Preserve image and license bytes. Review identifying strings in context: synthetic examples, loopback/default configuration and public third-party attribution differ from personal environment records. Automatic semantic history, selective live restore, external-service export, the Electron redesign, multi-message delivery, clipboard additions, desktop provisioning, image integration and the world/feed engine require their own implementation evidence. Planning documents are acceptance requirements, not evidence that these features ran. -## Local source preparation, 2026-09-07 +## Upgrade checks -The public candidate removes personal source identifiers and uses configured -Honcho user peers rather than a maintainer-specific override. Fleet-derived peer -configuration is validated so the user cannot alias the agent observer. -[Existing Honcho installations](../deploy/honcho/README.md#agent-scopes-and-readiness) -retain their actual peer ID when upgrading; no external data migration is included. - -Final source commands, export identity, privacy findings and private-backup -receipts are recorded by the preparing maintainer. New GitHub checks and settings -must be verified on the actual new repository before public activation. +For [existing Honcho installations](../deploy/honcho/README.md#agent-scopes-and-readiness), +verify that upgrades retain the configured user peer ID and reject an ID that +aliases the agent observer. Source installation does not migrate external memory +data; test any migration separately within its authorized scope.