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.

Sign up for GitHub

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

Jump to bottom

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

Open
wiktor-k opened this issue Apr 24, 2024 · 3 comments · May be fixed by #30717
Open

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

wiktor-k opened this issue Apr 24, 2024 · 3 comments · May be fixed by #30717
Labels
proposal/accepted We have reviewed the proposal and agree that it should be implemented like that/at all. type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@wiktor-k
Copy link
Contributor

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
@wiktor-k wiktor-k added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Apr 24, 2024
@lunny lunny added the proposal/accepted We have reviewed the proposal and agree that it should be implemented like that/at all. label Apr 24, 2024
@silverwind
Copy link
Member

silverwind commented Apr 24, 2024 •
edited

/<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
Copy link
Contributor Author

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
Copy link
Member

silverwind commented Apr 24, 2024 •
edited

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.

wiktor-k added a commit to wiktor-k/gitea that referenced this issue Apr 26, 2024
@wiktor-k
api: Allow unauthenticated access to user's SSH keys
69afd9d 
This patch relaxes constraints on getting user's SSH keys via the JSON
API. The same has been allowed by both GitHub and Gitlab and the output
is already readable via http://domain/user.keys endpoint.

The benefit of allowing it via the API are twofold: first this is
a structured output and second it can be CORS-enabled.

As a privacy precaution the `Title` property is set to an empty string
if the request is unauthenticated.

Fixes: go-gitea#30681
@wiktor-k wiktor-k linked a pull request Apr 26, 2024 that will close this issue
Open
wiktor-k added a commit to wiktor-k/gitea that referenced this issue Apr 29, 2024
@wiktor-k
api: Allow unauthenticated access to user's SSH keys
693db80 
This patch relaxes constraints on getting user's SSH keys via the JSON
API. The same has been allowed by both GitHub and Gitlab and the output
is already readable via http://domain/user.keys endpoint.

The benefit of allowing it via the API are twofold: first this is
a structured output and second it can be CORS-enabled.

As a privacy precaution the `Title` property is set to an empty string
if the request is unauthenticated.

Fixes: go-gitea#30681
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
proposal/accepted We have reviewed the proposal and agree that it should be implemented like that/at all. type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

api: Allow unauthenticated access to user's SSH keys wiktor-k/gitea
3 participants
@lunny @silverwind @wiktor-k