Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Meta] Show projects only to people with access

Aperta
  • Qualcosa non va?
#506 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github, typescript
Ambito
authentication, authorization, backend-api-design

Direzione di ricerca

Start with the definitions in docs/terms.md and the “The team” section in docs/architecture.md; the issue says these must change first to define Access and Share. Then inspect the listed sub-issues in order and the existing ace share <channel> on|off command, which needs a new name. Done means project access follows the stated rules, the command refers to agent access, and the documentation explains the terms and known security limits.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Today every channel is broadcast across the tailnet, whatever the project. A teammate sees every project with a channel, including private repositories they can't read on GitHub and local folders (for example toddler-game). This adds access control by project.

Rules

  • Access to a project means you can see it and its channels, and read and post in them as teammates do today. There is one level. Whether teammates can invoke an agent is still decided per channel by the agent access toggle.
  • You have direct access to a project if:
    • it's backed by a GitHub repository and your GitHub login can read that repository (so public repositories are open to the whole team), or
    • it's a local folder on your own Mac.
  • A share gives access to the whole team or to one person, on top of GitHub. It opens the whole project: every person's channels in it, now and later. Forking a channel into a project of your own is how you keep work out of a shared project.
  • Only people with direct access can share or unshare a project. Access through a share can't be passed on.
  • The confirmation names whose channels the share exposes. For example: "Share starship with Alex? Alex will see every channel in it, including Terkel's and Luke's, and any created later."
  • On upgrade, existing projects become private. People with GitHub read access keep seeing repository projects. Local folders disappear for everyone else until someone shares them.

Enforcement (cooperative)

Access holds between hosts running unmodified Ace:

  • The host that runs a channel names each caller with tailscale whois. It refuses people without access, so local channel transcripts, diffs, and repository info never leave it.
  • Each host shows its owner only projects the owner can access. That covers the directory's listings, lobby subscriptions and events, and hosted channels.
  • Shares live in the directory, the team's shared cell. Every host reads them there, because a share has to apply to everyone's channels in the project, not only the sharer's.

Known security hole

This is not a boundary against a teammate who tampers with Ace:

  • The directory, lobbies, hosted channels, and compute service accept one team credential derived from ACE_SECRET, which every host holds. Anyone who copies ACE_SECRET can:
    • read every listing: channel names, summaries, and absolute project paths;
    • join any project's lobby;
    • watch and post in any hosted channel;
    • read and rewrite the share list.
  • Lobby names for local folders contain the host and path.
  • A peer host reports its owner's GitHub login from its own gh CLI. Nothing verifies it, so the GitHub read-access check trusts what the peer claims. Shares are stored by Tailscale login, which whois verifies.
  • Hosts on older versions don't enforce access. They keep serving their channels to every peer.

Closing the hole needs per-person credentials that the services verify. That's tracked in the last sub-issue.

Docs

The definition of Team in docs/terms.md and the section "The team" in docs/architecture.md say Ace has no team access controls. Both change first, with new terms Access and Share.

The name clashes with ace share <channel> on|off, which is the per-channel agent access toggle. That command needs a new name, for example ace agents <channel> on|off, so that "share" refers only to project access.

Sub-issues are listed in order.

Dogfooding: #5

Lingua principale
TypeScript
Stelle
1
Fork
0
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di githubnext/ace2

Tutte le issue di githubnext/ace2

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.