feature: HTTPS based deploy keys #840

@kgraefe commented on GitHub (May 16, 2019):

I think it would be nice to have both per-account and per-organization access tokens.

@kgraefe commented on GitHub (May 16, 2019): I think it would be nice to have both per-account and per-organization access tokens.

GiteaMirror commented

@DjSni commented on GitHub (Aug 16, 2019):

I think it would be nice to have both per-account and per-organization access tokens.

i agree with you, but you should be able to set for each token which rights the token has.
For example, only read rights, read and write rights...
But I hope this will be implemented soon.

@DjSni commented on GitHub (Aug 16, 2019): > I think it would be nice to have both per-account and per-organization access tokens. i agree with you, but you should be able to set for each token which rights the token has. For example, only read rights, read and write rights... But I hope this will be implemented soon.

GiteaMirror commented

@Snck3rs commented on GitHub (Jun 23, 2020):

would be a great feature! i hope someone will be found to implement that.
Great work, btw!

@Snck3rs commented on GitHub (Jun 23, 2020): would be a great feature! i hope someone will be found to implement that. Great work, btw!

GiteaMirror commented

@multicast commented on GitHub (Jun 18, 2021):

https based deploy key per organization would also be interesting, as well as ssh deploy key per organization would simplify many setups.
currently I had to create "technical" user to achieve this and make it a member of the team/organization. The organization admin should be able to generate such tokens or mark keys as deploy keys for organization or multiple repositories.

@multicast commented on GitHub (Jun 18, 2021): https based deploy key per organization would also be interesting, as well as ssh deploy key per organization would simplify many setups. currently I had to create "technical" user to achieve this and make it a member of the team/organization. The organization admin should be able to generate such tokens or mark keys as deploy keys for organization or multiple repositories.

GiteaMirror commented

@skorokithakis commented on GitHub (Sep 2, 2021):

Yes please, HTTPS cloning with tokens would be great for times where adding an SSH key is inconvenient.

@skorokithakis commented on GitHub (Sep 2, 2021): Yes please, HTTPS cloning with tokens would be great for times where adding an SSH key is inconvenient.

GiteaMirror commented

@vbichov commented on GitHub (Dec 2, 2021):

this issue is open for almost 5 years - what are the chances this will actually be implemented?

@vbichov commented on GitHub (Dec 2, 2021): this issue is open for almost 5 years - what are the chances this will actually be implemented?

GiteaMirror commented

@lunny commented on GitHub (Dec 2, 2021):

I think it's not very difficult, if the token is a user's personal access token. We need to change here https://github.com/go-gitea/gitea/blob/main/routers/web/repo/http.go#L113 and create a new implementation of https://github.com/go-gitea/gitea/blob/34b5436ae1af2735546bb519a950eabf4990212d/services/auth/interface.go#L23 only for SmartHTTP routers.

@lunny commented on GitHub (Dec 2, 2021): I think it's not very difficult, if the token is a user's personal access token. We need to change here https://github.com/go-gitea/gitea/blob/main/routers/web/repo/http.go#L113 and create a new implementation of https://github.com/go-gitea/gitea/blob/34b5436ae1af2735546bb519a950eabf4990212d/services/auth/interface.go#L23 only for SmartHTTP routers.

GiteaMirror commented

@silverwind commented on GitHub (Dec 2, 2021):

It should generate a unique token per-repo, not re-use a user's personal token. But I guess the implementation can probably share some of code with the personal token mechanism, like the generation part.

@silverwind commented on GitHub (Dec 2, 2021): It should generate a unique token per-repo, not re-use a user's personal token. But I guess the implementation can probably share some of code with the personal token mechanism, like the generation part.

GiteaMirror commented

@lunny commented on GitHub (Dec 2, 2021):

It should generate a unique token per-repo, not re-use a user's personal token. But I guess the implementation can probably share some of code with the personal token mechanism, like the generation part.

Share it between projects

One key could be used for multiple repositories, one repositories could also have multiple keys.

@lunny commented on GitHub (Dec 2, 2021): > It should generate a unique token per-repo, not re-use a user's personal token. But I guess the implementation can probably share some of code with the personal token mechanism, like the generation part. > Share it between projects One key could be used for multiple repositories, one repositories could also have multiple keys.

GiteaMirror commented

2025-11-02 03:38:32 -06:00

@skorokithakis commented on GitHub (Dec 2, 2021):

@lunny I disagree, sharing one key for multiple repositories is the job of the personal token. A deployment key is bound to a single repo, and you may have multiple keys for one repo.

@skorokithakis commented on GitHub (Dec 2, 2021): @lunny I disagree, sharing one key for multiple repositories is the job of the personal token. A deployment key is bound to a single repo, and you may have multiple keys for one repo.

GiteaMirror commented

@silverwind commented on GitHub (Dec 2, 2021):

One key could be used for multiple repositories, one repositories could also have multiple keys.

That would be different to how deploy keys currently work (which are 1 per repo IIRC), but I guess one layer of indirection via a dropdown of selectable deploy keys (ssh and http) would be nice to have, but not required initially imho.

Also, it would present an issue regarding ownership of shared deploy keys. Would it be users/orgs who own it? would they be global? I think we can sidestep such questions by first binding them only to the repo.

@silverwind commented on GitHub (Dec 2, 2021): > One key could be used for multiple repositories, one repositories could also have multiple keys. That would be different to how deploy keys currently work (which are 1 per repo IIRC), but I guess one layer of indirection via a dropdown of selectable deploy keys (ssh and http) would be nice to have, but not required initially imho. Also, it would present an issue regarding ownership of shared deploy keys. Would it be users/orgs who own it? would they be global? I think we can sidestep such questions by first binding them only to the repo.

GiteaMirror commented

2025-11-02 03:38:32 -06:00

@TomFreudenberg commented on GitHub (Dec 2, 2021):

I agree to @skorokithakis

If you will use such deploy keys - I guess you will use https - so you will deploy your repo on several instances - each instance could have its own key per repo

@TomFreudenberg commented on GitHub (Dec 2, 2021): I agree to @skorokithakis If you will use such deploy keys - I guess you will use https - so you will deploy your repo on several instances - each instance could have its own key per repo

GiteaMirror commented

2025-11-02 03:38:32 -06:00

@multicast commented on GitHub (Dec 2, 2021):

Share it between projects

One key could be used for multiple repositories, one repositories could also have multiple keys.

I fully agree. One https token (or ssh key) should be usable in more repositories, and one repository should be able to have more tokens (ssh keys). Some of them read-only, some read-write. Also a per-organization tokens (keys) should exist. Now I have to solve it via some bot account, even this is not enough often.

Currently I can have an ssh deploy key in a repository (and enable write access if necessary), so my production servers can use the ssh key when pulling from host e.g. git.corp. Since the deploy key cannot be reused in other repo, I am forced to use the ssh config file:

Host foo.git.corp
  IdentityFile ~/.ssh/foo
Host bar.git.corp
  IdentityFile ~/.ssh/bar
Host *.git.corp
  Hostname git.corp
  User git

If the project is composed from dozens of repos, I need dozens keys, one for every new repo. Reusing one deploy key for several repos would be a valuable feature, and the same applies for the https token.
If all repos for particular project are grouped in an organization, this would make use case for the per-organization deploy key (or https token).
Replicating the production setup to run independently an integration, q&a, or a test environment makes perfect sense not to share ssh key with production. That's why more deploy keys are already possible per repo (and so more https tokens must be possible too).

I do not use above setup any more - instead of managing multiple keys, on multiple servers, in multiple environments, I have a bot and that bot is an organization member or collaborator. It's enough to use bot's private key instead of mine or managing dozens of keys. Replacing this with single https token would make things incredibly simpler.

Do not limit an https token (or a deploy key) to single repo. It should work, potentially with different privilege level, for multiple other repos. If somebody "overloads" the key or token with access to a too-many repos, the key or token has more "power", but it means you can also revoke/invalidate a key or token from all repos efficiently.

@multicast commented on GitHub (Dec 2, 2021): > > > Share it between projects > > One key could be used for multiple repositories, one repositories could also have multiple keys. I fully agree. One https token (or ssh key) should be usable in more repositories, and one repository should be able to have more tokens (ssh keys). Some of them read-only, some read-write. Also a per-organization tokens (keys) should exist. Now I have to solve it via some bot account, even this is not enough often. Currently I can have an ssh deploy key in a repository (and enable write access if necessary), so my production servers can use the ssh key when pulling from host e.g. `git.corp`. Since the deploy key cannot be reused in other repo, I am forced to use the ssh config file: ``` Host foo.git.corp IdentityFile ~/.ssh/foo Host bar.git.corp IdentityFile ~/.ssh/bar Host *.git.corp Hostname git.corp User git ``` If the project is composed from dozens of repos, I need dozens keys, one for every new repo. Reusing one deploy key for several repos would be a valuable feature, and the same applies for the https token. If all repos for particular project are grouped in an organization, this would make use case for the per-organization deploy key (or https token). Replicating the production setup to run independently an integration, q&a, or a test environment makes perfect sense not to share ssh key with production. That's why more deploy keys are already possible per repo (and so more https tokens must be possible too). I do not use above setup any more - instead of managing multiple keys, on multiple servers, in multiple environments, I have a bot and that bot is an organization member or collaborator. It's enough to use bot's private key instead of mine or managing dozens of keys. Replacing this with single https token would make things incredibly simpler. Do not limit an https token (or a deploy key) to single repo. It should work, potentially with different privilege level, for multiple other repos. If somebody "overloads" the key or token with access to a too-many repos, the key or token has more "power", but it means you can also revoke/invalidate a key or token from all repos efficiently.

GiteaMirror commented

2025-11-02 03:38:33 -06:00

@techknowlogick commented on GitHub (Dec 2, 2021):

Tbh I use bot accounts for this so I can assign exactly which repos/orgs they have access to.

@techknowlogick commented on GitHub (Dec 2, 2021): Tbh I use bot accounts for this so I can assign exactly which repos/orgs they have access to.

GiteaMirror commented

2025-11-02 03:38:33 -06:00

@multicast commented on GitHub (Dec 2, 2021):

Me too, but sometimes you I have a "3rd party" for single or few closely related repos, for which the https token is the only way (i.e. no ssh access, so no deploy keys). having a thousands 3rd parties means thousands of bot accounts versus simple https token. The 3rd party can be a single server or a cluster, not actualy a human, obviously.

@multicast commented on GitHub (Dec 2, 2021): Me too, but sometimes you I have a "3rd party" for single or few closely related repos, for which the https token is the only way (i.e. no ssh access, so no deploy keys). having a thousands 3rd parties means thousands of bot accounts versus simple https token. The 3rd party can be a single server or a cluster, not actualy a human, obviously.

GiteaMirror commented

@multicast commented on GitHub (Dec 2, 2021):

I just found a bot account issue #13044, which helps using bot accounts, but is still not a replacement for https tokens.

@multicast commented on GitHub (Dec 2, 2021): I just found a bot account issue #13044, which helps using bot accounts, but is still not a replacement for https tokens.

GiteaMirror commented

@silverwind commented on GitHub (Dec 3, 2021):

Yes, I also use "bot" style accounts to share one "deploy token" for multiple repos. But sharing such tokens with access to multiple repos is not a good practice security-wise because if one system gets compromised, more data is at risk than it needs to be.

So I would even prefer if a HTTPS deploy token is only valid for a single repo, just like SSH deploy keys currently are.

@silverwind commented on GitHub (Dec 3, 2021): Yes, I also use "bot" style accounts to share one "deploy token" for multiple repos. But sharing such tokens with access to multiple repos is not a good practice security-wise because if one system gets compromised, more data is at risk than it needs to be. So I would even prefer if a HTTPS deploy token is only valid for a single repo, just like SSH deploy keys currently are.

GiteaMirror commented

@MrSuicideParrot commented on GitHub (Dec 3, 2021):

Bot accounts are a hacky way to minimise this problem and not the solution.
This issue has been open for 4 years and in my point of view, this is the only major feature that is missing when compared with gitlab and GitHub.
Thus, I don't understand why this feature isn't a priority...

@MrSuicideParrot commented on GitHub (Dec 3, 2021): Bot accounts are a hacky way to minimise this problem and not the solution. This issue has been open for 4 years and in my point of view, this is the only major feature that is missing when compared with gitlab and GitHub. Thus, I don't understand why this feature isn't a priority...

GiteaMirror commented

@lunny commented on GitHub (Dec 3, 2021):

Vote:

🚀 One key one repo
👍 One key could be used for multiple repositories, one repository could also have multiple keys.
🎉 Just keep to use bot account
❤️ One repository can have multiple keys but they can't be reused on another repo.

Or if you have any other options, please let me know.

@lunny commented on GitHub (Dec 3, 2021): Vote: - 🚀 One key one repo - 👍 One key could be used for multiple repositories, one repository could also have multiple keys. - 🎉 Just keep to use bot account - ❤️ One repository can have multiple keys but they can't be reused on another repo. Or if you have any other options, please let me know.

GiteaMirror commented

@mgax commented on GitHub (Dec 6, 2021):

Or if you have any other options, please let me know.

GitHub allows you to set multiple deployment keys per repo, but you're not allowed to reuse a key on multiple repos (which is a royal pain). Also, GitHub only allows SSH deployment keys, it would be great to have HTTPS deployment keys too. So, for completeness sake, there can be another option, one repository can have multiple keys but they can't be reused on another repo. Not that I'm advocating for it :)

@mgax commented on GitHub (Dec 6, 2021): > Or if you have any other options, please let me know. GitHub allows you to set multiple deployment keys per repo, but you're not allowed to reuse a key on multiple repos (which is a royal pain). Also, GitHub only allows SSH deployment keys, it would be great to have HTTPS deployment keys too. So, for completeness sake, there can be another option, _one repository can have multiple keys but they can't be reused on another repo_. Not that I'm advocating for it :)

GiteaMirror commented

@lunny commented on GitHub (Dec 6, 2021):

Or if you have any other options, please let me know.

GitHub allows you to set multiple deployment keys per repo, but you're not allowed to reuse a key on multiple repos (which is a royal pain). Also, GitHub only allows SSH deployment keys, it would be great to have HTTPS deployment keys too. So, for completeness sake, there can be another option, one repository can have multiple keys but they can't be reused on another repo. Not that I'm advocating for it :)

Added as a new vote option.

@lunny commented on GitHub (Dec 6, 2021): > > Or if you have any other options, please let me know. > > GitHub allows you to set multiple deployment keys per repo, but you're not allowed to reuse a key on multiple repos (which is a royal pain). Also, GitHub only allows SSH deployment keys, it would be great to have HTTPS deployment keys too. So, for completeness sake, there can be another option, _one repository can have multiple keys but they can't be reused on another repo_. Not that I'm advocating for it :) Added as a new vote option.

GiteaMirror commented

@DjSni commented on GitHub (Dec 6, 2021):

Would like to set a 🥇 but i can´t. I can only set 👍, 👎,😄,🎉,😕,❤️,🚀,👀
Thanks

@DjSni commented on GitHub (Dec 6, 2021): Would like to set a 🥇 but i can´t. I can only set 👍, 👎,😄,🎉,😕,❤️,🚀,👀 Thanks

GiteaMirror commented

@lunny commented on GitHub (Dec 6, 2021):

Would like to set a 🥇 but i can´t. I can only set 👍, 👎,😄,🎉,😕,❤️,🚀,👀 Thanks

Changed to ❤️

@lunny commented on GitHub (Dec 6, 2021): > Would like to set a 🥇 but i can´t. I can only set 👍, 👎,😄,🎉,😕,❤️,🚀,👀 Thanks Changed to ❤️

GiteaMirror commented

@jerrykan commented on GitHub (Dec 6, 2021):

Would like to set a 1st_place_medal but i can´t. I can only set +1, -1,smile,tada,confused,heart,rocket,eyes Thanks

Changed to heart

what about 💯 ? It isn't a valid option either.

@jerrykan commented on GitHub (Dec 6, 2021): > > Would like to set a 1st_place_medal but i can´t. I can only set +1, -1,smile,tada,confused,heart,rocket,eyes Thanks > > Changed to heart what about :100: ? It isn't a valid option either.

GiteaMirror commented

@silverwind commented on GitHub (Dec 10, 2021):

Can't vote 💯, but it's definitely my favorite. Keep it simple and secure, at least initially. More flexibility can be added later and such stuff could then also apply for SSH-based deploy keys.

@silverwind commented on GitHub (Dec 10, 2021): Can't vote 💯, but it's definitely my favorite. Keep it simple and secure, at least initially. More flexibility can be added later and such stuff could then also apply for SSH-based deploy keys.

GiteaMirror commented

@lunny commented on GitHub (Dec 10, 2021):

@jerrykan @silverwind Don't know why I can. Changed to 🚀

@lunny commented on GitHub (Dec 10, 2021): @jerrykan @silverwind Don't know why I can. Changed to 🚀

GiteaMirror commented

@multicast commented on GitHub (Dec 11, 2021):

@silverwind - I fully agree with security-wise practice of not sharing keys. but one key/token per repo forces me to share key on multiple clients. so, security-wise, repo must have possibility of more keys.

on the other side, sharing single key/token for multiple repos puts them all at the same risk when a key/token is compromised. but possibility to reuse the key/token in multiple repos does not require you to do so. you can still follow policy of not reusing the key. but where appropriate, greatly simplifies setups.

@techknowlogick - I also agree that a bot account is workaround, not a solution.

@multicast commented on GitHub (Dec 11, 2021): @silverwind - I fully agree with security-wise practice of not sharing keys. but one key/token per repo forces me to share key on multiple clients. so, security-wise, repo must have possibility of more keys. on the other side, sharing single key/token for multiple repos puts them all at the same risk when a key/token is compromised. but possibility to reuse the key/token in multiple repos does not require you to do so. you can still follow policy of not reusing the key. but where appropriate, greatly simplifies setups. @techknowlogick - I also agree that a bot account is workaround, not a solution.

GiteaMirror commented

@MarZab commented on GitHub (Feb 7, 2022):

Could the deploy sha key be used to validate a token generated and signed using the private key ?

To expand on this idea, imagine we have something like a JWT:

{
   validUntil: "2021-10-01-10-10-10",  // iso like date
   repository: "a-repo", // limit to a repo
   privileges: "read,write" // limit to certain actions
}

We sign and base64 encode the token and produce a link:

git clone https://jwt:<JWT_LIKE_TOKEN>@<GITLAB_INSTANCE_URL>/<USERNAME_OR_GROUPNAME/<REPO_NAME>.git

The server would validate it using the deploy sha key and apply the permission set.

This way there is no additional management for the keys, they keep the same access levels and are added/removed with the deploy sha key - but we get this extra level of configurability we can use to produce really specific access tokens.

@MarZab commented on GitHub (Feb 7, 2022): Could the deploy sha key be used to validate a token generated and signed using the private key ? To expand on this idea, imagine we have something like a JWT: ``` { validUntil: "2021-10-01-10-10-10", // iso like date repository: "a-repo", // limit to a repo privileges: "read,write" // limit to certain actions } ``` We sign and base64 encode the token and produce a link: ``` git clone https://jwt:<JWT_LIKE_TOKEN>@<GITLAB_INSTANCE_URL>/<USERNAME_OR_GROUPNAME/<REPO_NAME>.git ``` The server would validate it using the deploy sha key and apply the permission set. This way there is no additional management for the keys, they keep the same access levels and are added/removed with the deploy sha key - but we get this extra level of configurability we can use to produce really specific access tokens.

GiteaMirror commented

@benedictjohannes commented on GitHub (Jul 14, 2022):

Is there any fork already working on this? I'd be interested to implement it with "One key could be used for multiple repositories, one repository could also have multiple keys."

@benedictjohannes commented on GitHub (Jul 14, 2022): Is there any fork already working on this? I'd be interested to implement it with "One key could be used for multiple repositories, one repository could also have multiple keys."

GiteaMirror commented

@manuelchichi commented on GitHub (Nov 9, 2022):

Any update on this feature?

@manuelchichi commented on GitHub (Nov 9, 2022): Any update on this feature?

GiteaMirror commented

@netthier commented on GitHub (Apr 4, 2023):

This would also be useful for fine-grained control over the Gitea container registry, as it does not support SSH authentication, only HTTP(S).

@netthier commented on GitHub (Apr 4, 2023): This would also be useful for fine-grained control over the Gitea container registry, as it does not support SSH authentication, only HTTP(S).

GiteaMirror commented

@cwchristerw commented on GitHub (Jun 1, 2023):

This is maybe related to https://github.com/go-gitea/gitea/pull/24767

@cwchristerw commented on GitHub (Jun 1, 2023): This is maybe related to https://github.com/go-gitea/gitea/pull/24767

GiteaMirror commented

@Jamesits commented on GitHub (Jun 9, 2023):

Fine-grained API tokens would be great. Rather than having deploy keys shared between projects, would it be better to just have bot accounts that are PAT&SSH keys only, no UI login, no SSO? This allows sharing keys between projects. We also want different username and profile pictures for these bot accounts, so that CI released packages does not say they are uploaded by some human.

(BTW, do allow a bot account to have multiple PAT and SSH keys so credential rotating can be implemented in an easier way. )

@Jamesits commented on GitHub (Jun 9, 2023): Fine-grained API tokens would be great. Rather than having deploy keys shared between projects, would it be better to just have bot accounts that are PAT&SSH keys only, no UI login, no SSO? This allows sharing keys between projects. We also want different username and profile pictures for these bot accounts, so that CI released packages does not say they are uploaded by some human. (BTW, do allow a bot account to have multiple PAT and SSH keys so credential rotating can be implemented in an easier way. )

GiteaMirror commented

@HammyHavoc commented on GitHub (Mar 24, 2024):

Is anyone currently working on this? Just hit this problem and might be interested in taking it on. Any rough stuff or notes anyone has about it would be appreciated.

@HammyHavoc commented on GitHub (Mar 24, 2024): Is anyone currently working on this? Just hit this problem and might be interested in taking it on. Any rough stuff or notes anyone has about it would be appreciated.

GiteaMirror commented

@multicast commented on GitHub (Mar 24, 2024):

I am not, even I miss this feature. Is it worth to summarize the target? Or settle on the winner - https://github.com/go-gitea/gitea/issues/2051#issuecomment-985647044

@multicast commented on GitHub (Mar 24, 2024): I am not, even I miss this feature. Is it worth to summarize the target? Or settle on the winner - https://github.com/go-gitea/gitea/issues/2051#issuecomment-985647044

GiteaMirror commented

@lesinigo commented on GitHub (Mar 25, 2024):

IMHO sharing the same project deploy key between multiple use cases should be avoided at all costs for security reasons (as @multicast also said). This brings us to the requirement of supporting more than one key per project.

Personally I'm against sharing the same "key" between multiple projects, I'd prefer the "bot account" approach, that would also probably be easier to implement since the logic and UI to manage which projects can be accessed by which users is already there.

Still, simple "deploy tokens" for projects, with read only access and with the ability to create more than one for each project, would probably solve 90% of use cases out there and can co-exist with a future "bot account" implementation. Gitlab does the same too, for example.

@lesinigo commented on GitHub (Mar 25, 2024): IMHO sharing the same project deploy key between multiple use cases should be avoided at all costs for security reasons (as @multicast also said). This brings us to the requirement of supporting more than one key per project. Personally I'm against sharing the same "key" between multiple projects, I'd prefer the "bot account" approach, that would also probably be easier to implement since the logic and UI to manage which projects can be accessed by which users is already there. Still, simple "deploy tokens" for projects, with read only access and with the ability to create more than one for each project, would probably solve 90% of use cases out there and can co-exist with a future "bot account" implementation. [Gitlab does the same too](https://docs.gitlab.com/ee/user/project/deploy_tokens/), for example.

GiteaMirror commented

@multicast commented on GitHub (Mar 25, 2024):

Bot accounts are already possible and are certainly workaround

they must be specialy secured (password, key, api tokens...)
they steal the first level of namespace used by users or organizations
they clutter the list of instance users, members of the repository, organization or team
to change their public key or token, you must login to them
to create account a developer needs enough privileges (or bother admin)
overtime, nobody remembers who created or "owns" the bot12345 and if it can be deleted
managing bot's properties via command line or API needs bot's own credentials
accounts can be in an external corporate system (SAML, LDAP...) the gitea admin has no easy control of.

Tokens or keys:

your (developer) account is probably already secured
no additional namespace pollution or any user lists with new entry
changing your keys can be done yourself
removing repository or the organization also removes key/token association
should be naturally managed using API or tea command line (with your credentials)

Using the same "key" for multiple projects is not sharing. It's empowering the key for having access to more, often tightly related repositories (e.g. subtree or submodules). Allowing to reuse key or token does not block your preferred approach - feel free to use any key or token only once, have different per each repo.

Preventing reuse of a repo-based deploy public ssh key from accessing more than one repo, or blocking a token access to multiple repositories, implies creation of many keys or tokens and their management on clients accessing Gitea. Allowing single powerful token to access multiple repositories also allows (e.g. after a compromise) to revoke, delete or update single key and effectively block access of the old token wherever it ever had access to.

The winner says it all: One key could be used for multiple repositories, one repository could also have multiple keys

@multicast commented on GitHub (Mar 25, 2024): Bot accounts are already possible and are certainly workaround - they must be specialy secured (password, key, api tokens...) - they steal the first level of namespace used by users or organizations - they clutter the list of instance users, members of the repository, organization or team - to change their public key or token, you must login to them - to create account a developer needs enough privileges (or bother admin) - overtime, nobody remembers who created or "owns" the bot12345 and if it can be deleted - managing bot's properties via command line or API needs bot's own credentials - accounts can be in an external corporate system (SAML, LDAP...) the gitea admin has no easy control of. Tokens or keys: - your (developer) account is probably already secured - no additional namespace pollution or any user lists with new entry - changing your keys can be done yourself - removing repository or the organization also removes key/token association - should be naturally managed using API or tea command line (with your credentials) Using the same "key" for multiple projects is not sharing. It's empowering the key for having access to more, often tightly related repositories (e.g. subtree or submodules). Allowing to reuse key or token does not block your preferred approach - feel free to use any key or token only once, have different per each repo. Preventing reuse of a repo-based deploy public ssh key from accessing more than one repo, or blocking a token access to multiple repositories, implies creation of many keys or tokens and their management on clients accessing Gitea. Allowing single powerful token to access multiple repositories also allows (e.g. after a compromise) to revoke, delete or update single key and effectively block access of the old token wherever it ever had access to. The winner says it all: _One key could be used for multiple repositories, one repository could also have multiple keys_

GiteaMirror commented