CORS headers on the public index (sysand.com) so browser-based clients can consume it directly

Sysand Feature Requests
1

Hi! First off, thanks for sysand and for publishing the index protocol as a clean spec (design/index-protocol.md). Being able to browse the index, search the published projects, and one-click-install a digest-verified kpar entirely client-side is a cool experience.

The problem: the read-side endpoints on sysand.com don’t send CORS headers, so browsers block cross-origin fetch() of the index. Verified against:

  • https://sysand.com/sysand-index-config.json
  • https://sysand.com/index/index.json
  • https://sysand.com/index/<publisher>/<name>/versions.json
  • https://sysand.com/index/<publisher>/<name>/<version>/project.kpar

None of these include Access-Control-Allow-Origin in responses (tested with an Origin: request header). During development I can work around this with a local dev-server proxy, but my deployment target is a static host. There is no server to proxy through, so browser-based clients are simply locked out of the public index.

The request: add Access-Control-Allow-Origin: * to the read-side static index tree — the discovery document, index.json, versions.json, and the per-version .project.json / .meta.json / project.kpar. Rationale:

  • These are public, immutable, GET-only artifacts; ACAO: * on them carries no credential or CSRF exposure, and it’s the established practice for package registries consumed by web tooling (crates.io’s index/static endpoints, npm’s registry, jsDelivr, etc.).
  • The protocol’s own Section 10 digest commitments already give end-to-end integrity regardless of transport, so nothing about the trust model changes.
  • If any of these responses redirect to an object store/CDN (which Section 2 explicitly permits), the redirect target would need the header as well.

Two smaller related thoughts, take or leave:

  1. It might be worth a sentence in the index protocol itself (Section 2 Implementability or Section 11 Server obligations) RECOMMENDING CORS on the read-side tree, so all conforming index servers are browser-reachable by default — it fits the “serve-able from an ordinary static file server” design goal nicely.
  2. The write-side API (v1/upload, token exchange) can of course stay CORS-restricted; this request is only about the read side.

Thanks for considering it

2

Hi Blake,

Thanks for the report! We will look into adding CORS headers, but it can take a couple of weeks due to holidays.

Andrius

3

Hey @Blake_Regalia! Great to hear about this!

I’ve now relaxed CORS, so browsers should permit fetching content for users on other websites to fetch packages from sysand.com. Both the webserver response itself (which typically redirects) and the object storage backend that serves various project files to have permissive ACAO response headers.