~sircmpwn/git.sr.ht#370: 
uploadArtifact() returns Artifact with obviously fake URL

Consider the given:

$ curl -F operations='{ "query": "mutation($file: Upload!) {uploadArtifact(repoId: 210654, revspec: \"test\", file: $file) { id, created, filename, checksum, url} }", "variables": {"file": null} }' -F map='{"0":["variables.file"]}}' -F 0=@a https://git.sr.ht/query | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   806  100   224  100   582    440   1143 --:--:-- --:--:-- --:--:--  1583
{
  "data": {
    "uploadArtifact": {
      "id": 3232,
      "created": "2022-10-31T22:14:21.793509Z",
      "filename": "a",
      "checksum": "sha256:87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7",
      "url": "https://patchouli.sr.ht/git.sr.ht//a"
    }
  }
}
$ curl -F operations='{ "query": "mutation($file: Upload!) {uploadArtifact(repoId: 210654, revspec: \"test\", file: $file) { id, created, filename, checksum, url} }", "variables": {"file": null} }' -F map='{"0":["variables.file"]}}' -F 0=@b https://git.sr.ht/query | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   805  100   223  100   582    400   1044 --:--:-- --:--:-- --:--:--  1445
{
  "data": {
    "uploadArtifact": {
      "id": 3233,
      "created": "2022-10-31T22:15:20.59545Z",
      "filename": "b",
      "checksum": "sha256:0263829989b6fd954f72baaf2fc64bc2e2f01d692d4de72986ea808f6e99813f",
      "url": "https://patchouli.sr.ht/git.sr.ht//b"
    }
  }
}

What's the point of the URL here?

Admittedly, even on the old POST /api/repos/voreutils/artifacts API that did return an actual non-fake URL, like https://patchouli.sr.ht/git.sr.ht/artifacts/~nabijaczleweli/tzpfms/tzpfms-v0.3.1-manual.ps, which is still useless because it prompts for credentials, but at least that pretends it did something.

Status
REPORTED
Submitter
~nabijaczleweli
Assigned to
No-one
Submitted
1 year, 5 months ago
Updated
1 year, 5 months ago
Labels
No labels applied.

~bitfehler 1 year, 5 months ago

Two things:

  1. This seems to be a misunderstanding. The URL has always been the internal storage URL, it is not meant for outside use. AFAIU the public URL of an artifact is predetermined (https://git.sr.ht/~<user>/<repo>/refs/download/<tag>/<filename>), hence there is no need to return it (besides potentially convenience?). Admittedly, this is documented neither for the old nor the new API, so I'll submit a patch at least for the new API to do so.

  2. That said, this is indeed currently broken in GraphQL, because unlike in the old API, the GraphQL resolver does not add artifacts/<user>/<repo> to the prefix. I'll submit a patch for that as well, but it's unfortunately not quite trivial, so I'll need some time to prepare a test environment with repos and artifacts.

~nabijaczleweli 1 year, 5 months ago*

I think it was correct until I found it was equally correct to guess the URL without auth, which I posted privately to Drew as msgid <20200820213847.voimtr2f7ymf7ckh@tarta.nabijaczleweli.xyz>, and resulted in this advisory and this git.sr.ht commit.

This URL, as returned by the HTTP API is equally meaningless as the broken URL returned by the GraphQL one, and has been for >2yrs. Given that, I think it very much makes sense to:

Because as it stands, regardless of if we fill it out to match the HTTP-API-returned URL, it's still just pure padding.

Register here or Log in to comment, or comment via email.