feat(content-node): CID allowlist and takedown denylist for the public gateway
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 30/100
Direzione di ricerca
Start with dependency #71 and the spike it produces; the issue does not identify implementation files or tests. Decide whether Kubo configuration, a reverse proxy rule, or a Boxo-based gateway fits the spike, then trace how the audit collection and provenance storage provide allowed CIDs and how admins maintain the denylist. Done means unlisted and denylisted CIDs are refused, with behavior covered by a test.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
Make sure the public gateway only serves platform-published content and can drop content on request.
Estimated size: M
Motivation
Otherwise the gateway is an open proxy to the IPFS network at our cost.
Proposal
- Implement in the form the spike recommends (reverse-proxy rule, Kubo setting or a small Boxo-based gateway).
- Allowlist fed from the audit collection and the provenance storage references; denylist maintained by admins.
Acceptance criteria
- A request for a CID not on the allowlist is refused.
- Denylisted CIDs are refused even if allowlisted.
- Behavior is covered by a test.
Technical notes and risks
- Conditional: if the spike shows Kubo configuration is enough, adapt the scope to that.
Dependencies
- #71
Part of #43. Ground rules for the content layer: no secrets in the repo, content-layer failures must never block or discard quantum execution, and tests and docs ship with every PR.
- Lingua principale
- Python
- Stelle
- 2
- Fork
- 4
- Merge medio
- 5h 19m
- PR unite (30g)
- 11
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di QMeshPy/distributed-quantum
-
enhancement good first issue helia storage tier-1
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
QMeshPy/distributed-quantum#53 ·
I maintainer di solito rispondono entro 1 giorno
-
chain-integration enhancement payments research-spike tier-2
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
QMeshPy/distributed-quantum#78 ·
I maintainer di solito rispondono entro 1 giorno
-
chain-integration enhancement payments research-spike tier-2
Difficoltà 3/5 1-2 giorni Idoneità per principianti 66/100
QMeshPy/distributed-quantum#77 ·
I maintainer di solito rispondono entro 1 giorno
-
chain-integration enhancement payments tier-2
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
QMeshPy/distributed-quantum#76 ·
I maintainer di solito rispondono entro 1 giorno
-
documentation good first issue kubo storage tier-1
Difficoltà 2/5 1-3 ore Idoneità per principianti 42/100
QMeshPy/distributed-quantum#75 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di QMeshPy/distributed-quantum
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
MISP/misp-workbench#496 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100
fossasia/visdom-dev#69 ·
I maintainer di solito rispondono entro 3 giorni
-
[Bug] Parameters named like a property break to_xcal()Forse già presa @atharvasalunke1267 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
collective/icalendar#2018 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno