Make adding Collaborators requiring confirmation on the invited collaborator #11746

Open
opened 2025-11-02 09:46:32 -06:00 by GiteaMirror · 6 comments
Owner

Originally created by @Andre601 on GitHub (Sep 28, 2023).

Feature Description

As of right now, adding a Collaborator to a repository is done so without any kind of acceptance on the invited user's end.

I see this as a risky thing to have. While it may make things easier in terms of adding new collaborators can it also increase the risk with users being added to repository they don't want to be. Especially when the user in question is automated for certain features.

To give a personal example: I use Renovate with a dedicated user account to keep my dependencies updated.
One feature it has is "autodiscover" meaning it automatically detects and manages dependencies of repositories the Account has write access on.
I was interested in that feature as it would allow me to not having to constantly add new repositories to keep track of, but with how the collaborator adding works in Gitea is this a too high risk as users could simply add the account to their repository, causing higher usage of the backend-software and perhaps even API rate limits or similar.
Having the invitation of collaborators require a confirmation by the invited user would reduce this risk as users couldn't just add the account to whatever.

The invite should probably expire after 24 hours or a similar timeframe to not waste storage space on the database, as low as it may be.

I also tested this on try.gitea.io and the problem exists on it.

Screenshots

No response

Originally created by @Andre601 on GitHub (Sep 28, 2023). ### Feature Description As of right now, adding a Collaborator to a repository is done so without any kind of acceptance on the invited user's end. I see this as a risky thing to have. While it may make things easier in terms of adding new collaborators can it also increase the risk with users being added to repository they don't want to be. Especially when the user in question is automated for certain features. To give a personal example: I use Renovate with a dedicated user account to keep my dependencies updated. One feature it has is "autodiscover" meaning it automatically detects and manages dependencies of repositories the Account has write access on. I was interested in that feature as it would allow me to not having to constantly add new repositories to keep track of, but with how the collaborator adding works in Gitea is this a too high risk as users could simply add the account to their repository, causing higher usage of the backend-software and perhaps even API rate limits or similar. Having the invitation of collaborators require a confirmation by the invited user would reduce this risk as users couldn't just add the account to whatever. The invite should probably expire after 24 hours or a similar timeframe to not waste storage space on the database, as low as it may be. I also tested this on [try.gitea.io](https://try.gitea.io) and the problem exists on it. ### Screenshots _No response_
GiteaMirror added the proposal/acceptedtype/proposal labels 2025-11-02 09:46:32 -06:00
Author
Owner

@silverwind commented on GitHub (Sep 29, 2023):

GitHub initially also had this without confirmation, but since I think 2-3 years they have this confirmation. I think it's definitely needed.

IIRC, what GitHub does is create a notification for the invited user, which presents them a simple fullscreen page:

               Username has invited you to org/repo

                [Accept (green)] [Decline (gray)]
@silverwind commented on GitHub (Sep 29, 2023): GitHub initially also had this without confirmation, but since I think 2-3 years they have this confirmation. I think it's definitely needed. IIRC, what GitHub does is create a notification for the invited user, which presents them a simple fullscreen page: ``` Username has invited you to org/repo [Accept (green)] [Decline (gray)] ```
Author
Owner

@silverwind commented on GitHub (Sep 29, 2023):

One issue I forsee is bot accounts. When inviting a bot account, they must automatically accept the invitation because a bot account should be assumed to not be logged in by a user who could confirm this dialog.

While a invitation is pending, the collaboration status should show "Pending Invitation", ideally with a tooltip indicating time until expiry.

24h expiration is too short and would be annoying. I would at least make it 10 days, for example when a user is on short absence. Find out what the expiry time on GitHub. Likely make it configurable.

@silverwind commented on GitHub (Sep 29, 2023): One issue I forsee is bot accounts. When inviting a bot account, they must automatically accept the invitation because a bot account should be assumed to not be logged in by a user who could confirm this dialog. While a invitation is pending, the collaboration status should show "Pending Invitation", ideally with a tooltip indicating time until expiry. 24h expiration is too short and would be annoying. I would at least make it 10 days, for example when a user is on short absence. Find out what the expiry time on GitHub. Likely make it configurable.
Author
Owner

@lunny commented on GitHub (Sep 29, 2023):

One issue I forsee is bot accounts. When inviting a bot account, they must automatically accept the invitation because a bot account should be assumed to not be logged in by a user who could confirm this dialog.

While a invitation is pending, the collaboration status should show "Pending Invitation", ideally with a tooltip indicating time until expiry.

24h expiration is too short and would be annoying. I would at least make it 10 days, for example when a user is on short absence. Find out what the expiry time on GitHub. Likely make it configurable.

Maybe the invitation should be sent via both email and UI notification.

@lunny commented on GitHub (Sep 29, 2023): > One issue I forsee is bot accounts. When inviting a bot account, they must automatically accept the invitation because a bot account should be assumed to not be logged in by a user who could confirm this dialog. > > While a invitation is pending, the collaboration status should show "Pending Invitation", ideally with a tooltip indicating time until expiry. > > 24h expiration is too short and would be annoying. I would at least make it 10 days, for example when a user is on short absence. Find out what the expiry time on GitHub. Likely make it configurable. Maybe the invitation should be sent via both email and UI notification.
Author
Owner

@Andre601 commented on GitHub (Sep 29, 2023):

Maybe the invitation should be sent via both email and UI notification.

That would be the best solution here. Maybe also allow a user to define in the settings whether they only want notifications or also e-mails for invites.

Also, to clarify, I assume you mean automated user accounts with "Bots"? Because for me Bots are actual, dedicated bot accounts and not user accounts with automation.

@Andre601 commented on GitHub (Sep 29, 2023): > Maybe the invitation should be sent via both email and UI notification. That would be the best solution here. Maybe also allow a user to define in the settings whether they only want notifications or also e-mails for invites. Also, to clarify, I assume you mean automated user accounts with "Bots"? Because for me Bots are actual, dedicated bot accounts and not user accounts with automation.
Author
Owner

@silverwind commented on GitHub (Sep 29, 2023):

Yes, I mean automation accounts that I create for deployments. They have an app token to clone repos where they are collaborator, but otherwise they never log in. Adding a confirmation for them would be slightly annoying.

I guess we would need a flag on these accounts in the admin panel to mark them as such, maybe "Non-user account"? Or maybe a per-user setting to automatically accept invitations.

@silverwind commented on GitHub (Sep 29, 2023): Yes, I mean automation accounts that I create for deployments. They have an app token to clone repos where they are collaborator, but otherwise they never log in. Adding a confirmation for them would be slightly annoying. I guess we would need a flag on these accounts in the admin panel to mark them as such, maybe "Non-user account"? Or maybe a per-user setting to automatically accept invitations.
Author
Owner

@evenpsiq commented on GitHub (Feb 3, 2025):

Any update on this? We're going through a security review, and on a server where users are private, I can brute-force try adding collaborators and they automatically get added in to my repo as I find them. If they accidentally mix this up with one of their own repos, they'll end up putting files in my repo (and with me potentially stealing their information). Without confirmation they would have no idea that this is a phishing attempt. Once I have all the user accounts mapped out, I can also create thousands of repos and add all the users to all of them, potentially creating havoc. Fun! :)

@evenpsiq commented on GitHub (Feb 3, 2025): Any update on this? We're going through a security review, and on a server where users are private, I can brute-force try adding collaborators and they automatically get added in to my repo as I find them. If they accidentally mix this up with one of their own repos, they'll end up putting files in my repo (and with me potentially stealing their information). Without confirmation they would have no idea that this is a phishing attempt. Once I have all the user accounts mapped out, I can also create thousands of repos and add all the users to all of them, potentially creating havoc. Fun! :)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#11746