Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gateway: add trustless-only mode #225

Closed
lidel opened this issue Mar 26, 2023 · 1 comment · Fixed by #252
Closed

gateway: add trustless-only mode #225

lidel opened this issue Mar 26, 2023 · 1 comment · Fixed by #252
Assignees
Labels
dif/hard Having worked on the specific codebase is important dif/medium Prior experience is likely helpful need/triage Needs initial labeling and prioritization P2 Medium: Good to have, but can wait until someone steps up topic/gateway Issues related to HTTP Gateway

Comments

@lidel
Copy link
Member

lidel commented Mar 26, 2023

What

There should be a way to only expose response types required by trustless mode.

The trustless-only mode must have two key features:

  • client is provided with ability to fetch all information necessary for verifying and deserializing data (Block, CAR, and ipfs-record from IPIP-351) end-to-end.
  • it is impossible to make a mistake and send request that delegated trust to gateway
  • when enabled, trusted responses are disabled
  • for example, if someone sends request without explicit Accept or ?format, gateway returns HTTP error 501 Not Implemented stating only verifiable response types are supported

How

TBD, we need some sane defaults that also account for users of library not shooting themselves in the foot if they do nothing.

  • Only trustless responses by default
    • add implicit exception for localhost / 127.0.0.1 / ::1)
    • enabling trusted responses require explicit opt-in per hostname

Why

Hard lessons from project Rhea / Saturn about the tyranny of the default. Exposing deserialized responses in cases where a project only needs a subset of the entire gateway spec creates a surface for abuse.

It is way, way less work for everyone if boxo/gateway library provides a single configuration option to allow deserialized responses on non-localhost hostnames.

@lidel lidel added P2 Medium: Good to have, but can wait until someone steps up dif/hard Having worked on the specific codebase is important dif/medium Prior experience is likely helpful need/triage Needs initial labeling and prioritization topic/gateway Issues related to HTTP Gateway labels Mar 26, 2023
@lidel lidel moved this to Todo in @lidel's IPFS wishlist Mar 26, 2023
@hacdias hacdias self-assigned this Mar 27, 2023
@hacdias hacdias moved this to 🥞 Todo in IPFS Shipyard Team Mar 27, 2023
@hacdias hacdias moved this from 🥞 Todo to 🏃‍♀️ In Progress in IPFS Shipyard Team Apr 3, 2023
@hacdias hacdias moved this from 🏃‍♀️ In Progress to 🔎 In Review in IPFS Shipyard Team Apr 3, 2023
@hacdias
Copy link
Member

hacdias commented Apr 3, 2023

Whoop whoop #252

@github-project-automation github-project-automation bot moved this from Todo to Done in @lidel's IPFS wishlist May 29, 2023
@github-project-automation github-project-automation bot moved this from 🔎 In Review to 🎉 Done in IPFS Shipyard Team May 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dif/hard Having worked on the specific codebase is important dif/medium Prior experience is likely helpful need/triage Needs initial labeling and prioritization P2 Medium: Good to have, but can wait until someone steps up topic/gateway Issues related to HTTP Gateway
Projects
No open projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants