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.
Two things:
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.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.
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:
- return a corrected URL that actually means something in the https://git.sr.ht/~nabijaczleweli/ratrun/refs/download/0b/ratrun-0b.ps format, or
- given that the GraphQL version appears to be 0.0.0, kill the
urlfield.Because as it stands, regardless of if we fill it out to match the HTTP-API-returned URL, it's still just pure padding.
