Consider relaxing access constraints on `/api/users/{username}/keys`

[wiktor-k]

Feature Description

Hi,

I'm building an identity service (similar to https://keyoxide.org but based on SSH keys) and I'm looking for a way to get the keys without tokens with a CORS headers.

Just for the record both GitHub and Gitlab allow unauthenticated, CORS-ok access:

Gitlab:

$ curl -H Origin:http://example.com -i https://gitlab.com/api/v4/users/wiktor/keys
HTTP/2 200 
date: Wed, 24 Apr 2024 10:06:36 GMT
content-type: application/json
content-length: 1761
access-control-allow-methods: GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS
access-control-allow-origin: *
access-control-expose-headers: Link, X-Total, X-Total-Pages, X-Per-Page, X-Page, X-Next-Page, X-Prev-Page, X-Gitlab-Blob-Id, X-Gitlab-Commit-Id, X-Gitlab-Content-Sha256, X-Gitlab-Encoding, X-Gitlab-File-Name, X-Gitlab-File-Path, X-Gitlab-Last-Commit-Id, X-Gitlab-Ref, X-Gitlab-Size
access-control-max-age: 7200
...

[{"id":2938736,"title":"openpgp:0x64CFEBC4","created_at":"2018-12-31T23:22:23.809Z","expires_at":null,"key":"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC50X67d9QXRVTiVgVhuKO3CbDu76yV85Cp7CRwBVmv5nwEczFweT/p5XdTARjj25PiQRv0YMFIEdrh7LDB/lSgAcoIJptfHSSJzwd6tCMyXtgujtbz47oGhmZAzKvQl8xbxlZnhjxt9tjt9nPU+P1wIBJU7aOqx9k4kX25mP5HXeFZ1qNzPetwh9h5QzB/6f26iu1U004DdR2f27kBnzUNu/bUPLUI5hiFSxSXl6Oy3/y2srCUyQiUtDDD8498PiO+OZWNaz8xvZN2lyJLjy3dDWQP5y1GaEN2Jk5TdAxP/N/fXII/vZuRMFALhWupuLoytdUL7h27fubSnA6rKbJn Wiktor Kwapisiewicz (gitlab.com)","usage_type":"auth_and_signing"},{"id":6553087,"title":"openpgp:0x0529CE0A","created_at":"2021-01-05T07:17:04.934Z","expires_at":null,"key":"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILHCXBJYlPPkrt2WYyP3SZoMx43lDBB5QALjE762EQlc Wiktor Kwapisiewicz (gitlab.com)","usage_type":"auth_and_signing"},{"id":9644651,"title":"/usr/lib/pkcs11/libtpm2_pkcs11.so.0.0.0","created_at":"2022-05-30T10:42:15.495Z","expires_at":null,"key":"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQv2RJtGurpNLWyiGz9sSuX8agzV98gHW2ZG/7vFkIQrPlaYsd/OH1z7BZNeCHs5vcoq6c2Eh5s6a0vcH4n181TKfjgpbq4t7OFNygWBJplXIZvIlsY//UCxfp5ZdKWJfrYUu/0HeEv5r/7ZcpwF/omC97aM0ipmAeQ8QEGLfgGW427ATa/r2SFwK/4h0C+BTUnMj/YC/4KI/MPWA6x7RdAw+RbVjZd4kT2ZPXcUdruSqDQ4vSP/b8gERv1IjWUn+HHteRJgR2SwNmsuuT/Ko3FRFfXxXPV2yMEvUY2+DoU781VhZJl0aqpW5bIhlK5VE5rGvmMuE5S7XwYDM9V0Wl Wiktor Kwapisiewicz (gitlab.com)","usage_type":"auth_and_signing"},{"id":9713501,"title":"tpm@radon","created_at":"2022-06-09T19:13:11.340Z","expires_at":null,"key":"ecdsa-sha2-nistp384 AAAAE2VjZHNhLXNoYTItbmlzdHAzODQAAAAIbmlzdHAzODQAAABhBButvOpt5qRRPazVFSfV6a4A33eXtlVkXL7x4PHr2zryw1wGb7tzpuSTZKabJaTlSZP/Jpva2caGNNtoNbXVDisOsiS4/wSa3AJ2/PmxOcpv/lZcpCynKq4zDeogo+FxrA== Wiktor Kwapisiewicz (gitlab.com)","usage_type":"auth_and_signing"}]

GitHub:

$ curl -i https://api.github.com/users/castedo/ssh_signing_keys
HTTP/2 200 
server: GitHub.com
date: Mon, 16 Oct 2023 09:59:53 GMT
...
access-control-allow-origin: *
strict-transport-security: max-age=31536000; includeSubdomains; preload

[
  {
    "id": 164688,
    "key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIQdQut465od3lkVyVW6038PcD/wSGX/2ij3RcQZTAqt",
    "title": "ellersign2023",
    "created_at": "2023-09-20T12:05:12.685Z"
  }
]

Compare that with Gitea, that returns 401 (unauthenticated):

$ curl 'https://gitea.com/api/v1/users/minge/keys'   -H 'accept: application/json' -H Origin:http://example.com -i
HTTP/2 401 
date: Wed, 24 Apr 2024 10:11:56 GMT
content-type: application/json;charset=utf-8
content-length: 70
access-control-allow-origin: *
cache-control: max-age=0, private, must-revalidate, no-transform
server: Caddy
vary: Origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN

{"message":"token is required","url":"https://gitea.com/api/swagger"}

Note that the keys are already public via the other endpoint, which sadly is not CORS-enabled:

$ curl https://gitea.com/minge.keys -i
HTTP/2 200 
date: Wed, 24 Apr 2024 10:11:38 GMT
content-type: text/plain;charset=utf-8
content-length: 725
cache-control: max-age=0, private, must-revalidate, no-transform
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCo+x0KpXBUENNLk+VctUICG4+cgN5SsOr+KpUFrAmgKL7ql1Ti86TQK7bp694ciuspkLkT3HyrRiMND2hRUHexK+HHO35KGu8+MEj/yJREhLFOIicqOn0cz1r74V9hMrNYZO/uakBHJ5EDxZ2zVXs+fEtQjQYvOa3PW55vcRTeXXsUN2nRIzEiQMj6dpHdCz+is4iIMV9YiBhuXcvDSmag60fSYe437PZR4usBMTmYWwcdaTnzS4/swlGVGlEpP+xReJRyntt4WnelkphuYbgwe9BM5psWonbPf7r8e/s9lsOAsjgpZaySRlL85YSZlwGnswxLrw9gqTCpRr7KoVcjPPy4x5N5jghhah1DgPf0HrBT5LLkQCT9XJihAPP7qfnQcYzncR2FzHzCoQGdFoQHrz3VK/qRKNLqHe90yyHZGatfBfk/8TWkZ0DOJEl7BYL4vWUv9GuRsX1rxuPIz8ab5Pn2hKBDusFP8Mw6/1WaM1cB4eYIpHQcj+/xAMp9J4Q1oyh98MJUA0PDhTajoHiTsur31fZ7zqnTOOiOMtOhC42vFO5EO36hEqL8NZ1GA4VKK5Yj53CWnYF+OOSyFxMYd2yaqsjNaJ0SaLEaAcqBaYRutnD2ipHJcIatzebUch3RwdU2Sydf67yL/5dzvm9QWbeOV5+Gh1ZpBYj3sqXvYQ==

I think given what others do and the already-public aspect of the keys it would be OK to allow unauthenticated access to https://gitea.com/api/v1/users/{username}/keys and if that sounds OK for you I'm volunteering to implement it.

Screenshots

No response

[silverwind]

/<user>.keys and /<user>.pgp info is okay to expose. API has more metadata that some may consider sensitive like the key's comment.

Ideally you would fetch those in a client that does not require CORS, e.g. in the backend.

[wiktor-k]

Ideally you would fetch those in a client that does not require CORS, e.g. in the backend.

Yes, that's a workaround I could use but the point of my solution is not using any backend services as trusted third parties but doing it all in the browser. This has a couple of benefits: it's easier to self host for others and in general is less complex.

Additionally the JSON endpoint provides structured data, which is also beneficial.

I'm aware that this could be worked around but given other forges already having similar rules I hope implementing unauthenticated access would just be the cleanest solution.

As for the key comment maybe it can be omitted in unauthenticated requests but included in requests with tokens? I'm looking for just the key material and I'm okay with this adjustment (note that other forges just output that, as you can see in my samples above).

[silverwind]

As for the key comment maybe it can be omitted in unauthenticated requests but included in requests with tokens? I'm looking for just the key material and I'm okay with this adjustment (note that other forges just output that, as you can see in my samples above).

I guess I would be okay if the non-authenticated API returns the exact format that github does, with the stripped comment. It should be clearly documented that this specific API has a difference whether the request is authenticated or not.

[lafriks]

I hope the public does not mean unauthenticated for private instances? 🤔

[wiktor-k]

I hope the public does not mean unauthenticated for private instances? 🤔

It's the same kind of access that is available through the .keys endpoint (but with JSON+CORS):

$ curl https://codeberg.org/lafriks.keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAB+wCwJEbmp2zS0aREkMdUGyfinYTCsb56Cprbr+Oe1WMpsuf0efBUy5ZJ0AIfsfT40elnzyxCpw2m5WlzR1TgpEOMcuB21dqhqA5L10eoWjbMXf5N2fyeKMUguBjuIwemzRj2sIQwAoDY3FWfafrUwwswtbIBkZWT4kiwXwOqsXgzkqGf+w37oP0XhxF+HliN9qwx95RVQa9322ErLlRN4tsJs0qv6XyZGmyWO934ksPCsHXuPwz2iONXUWzf9SeTSJEfQyNup++LqMaXVbTggc+fNzJM5tyDAFLxbMSdVmbey7MAeluWLe5MKlBysFnlE68nXh8aoB11gr+w1+o6DTntbjjUlzpw5yTMnRMVHMOEDcBOv5ABaOU8D7jm45GnFtcH/hnPYecOWP639x7M20QGT4Z/9pN7WVlSyxW2lha2t2oi2Gn+5VEcN5YKsHKW7TyH1mg+miumwwR8Nvq93M7dnncA1+T/w1waJUriYGjYszqMMkhx/HVLo5ySdB2nsn0qkCP1/9RMn+3vVbyCiqeZOodo8iNRrdrwKJss9SH9AwHwodFfaoF0wgYbbGtB6frX1mRB1Z6UMlef4NomuPnXfMJxrrdFcbyyOIQQhzZg1EhoHF8BS5/laqw/DFg2xQ41cAVk8VludwBNeICI0ow+tR4wUyWeoA3cPQ==

(note no authentication tokens passed).

Or maybe I misunderstood your question?

[lafriks]

Or maybe I misunderstood your question?

I mean it should be still inaccessible if gitea instance is set to always require authentication (REQUIRE_SIGNIN_VIEW=true)

[wiktor-k]

I mean it should be still inaccessible if gitea instance is set to always require authentication (REQUIRE_SIGNIN_VIEW=true)

Yeah, just to be crystal clear: I don't want to relax that. Just provide the same info under the same rules as .keys but in JSON+CORS. Nothing more.

[lafriks]

PR title should be fixed that as it is quite misleading "unauthenticated access"

[wiktor-k]

PR title should be fixed that as it is quite misleading "unauthenticated access"

Okay, what do you suggest? .keys is available to users who are not logged in (example above), that's why I used unauthenticated. Is there a better terminology for such an access in Gitea?

[florent4014]

It would be very helpful to be able to allow public access to users' public keys. I've been using Gitlab and Gitea for some time now and i was able to do so in Gitlab (https://gitlab.domain.lan/user.keys).

Maybe put a toggle that each user can freely allow or not.

[techknowlogick]

@florent4014 I have some good news for you. That is already possible. This is in regards to changes in access to the API endpoint.