Policy: Decide what to do with 'private accounts' and 'private repos' #33

New Issue

Arnd Marijnissen · 2023-02-14T13:07:49+01:00

Arnd Marijnissen commented

2023-02-14 13:07:49 +01:00

Already there seems to have been someone who's set User visibility to 'private' on projects.blender.org. Next to this, they have also set up a private repo.

This introduces the question, however, if we should permit 'private' user-visibility at all; and especially if we should consider private repositories to be a valid thing.

Note that the settings for the current deployment are:

10 repository limit set 'globally'
New users get repo-limit set to -1, which then translates to global setting.

We should likely consider:

1 repository limit for new users
5 repo limit set globally as 'catch all'
20+ repo limit set on organisation 'blender'
Set user-visibility to public

Already there seems to have been someone who's set ```User visibility``` to 'private' on projects.blender.org. Next to this, they have also set up a private repo. This introduces the question, however, if we should permit 'private' user-visibility at all; and especially if we should consider private repositories to be a valid thing. Note that the settings for the current deployment are: * 10 repository limit set 'globally' * New users get repo-limit set to -1, which then translates to global setting. We should likely consider: * 1 repository limit for new users * 5 repo limit set globally as 'catch all' * 20+ repo limit set on organisation 'blender' * [x] Set user-visibility to public

Arnd Marijnissen added the

help wanted

label 2023-02-14 13:07:49 +01:00

Brecht Van Lommel commented

2023-02-14 13:36:10 +01:00

I think we should disallow private accounts and repositories entirely, assuming there is an option for that. If not we could considering adding that configuration option.

I don't think limiting number of repositories more is good, because a regular Blender contributor can easily need 5 forks to contribute to various things. The issue is not in the number of repositories.

I think we should disallow private accounts and repositories entirely, assuming there is an option for that. If not we could considering adding that configuration option. I don't think limiting number of repositories more is good, because a regular Blender contributor can easily need 5 forks to contribute to various things. The issue is not in the number of repositories.

Arnd Marijnissen commented

2023-02-14 13:42:40 +01:00

We could set limit to 1 for any new user so that they can at least clone blender and create pull-requests from any branches they care to make.

If a user is a regular contributor, he/she'd likely part of the 'blender' organisation (i am assuming this is the policy?). The blender-repository would have a high (or no) limit.

We could set limit to 1 for any new user so that they can at least clone blender and create pull-requests from any branches they care to make. If a user is a regular contributor, he/she'd likely part of the 'blender' organisation (i am assuming this is the policy?). The blender-repository would have a high (or no) limit.

Brecht Van Lommel commented

2023-02-14 13:48:11 +01:00

But what problem would we be solving by limiting the number of repositories to less than 10?

Brecht Van Lommel commented

2023-02-14 14:13:12 +01:00

For users I guess we can do:

[service]
ALLOWED_USER_VISIBILITY_MODES = public,limited

For repositories I could not find an option.

For users I guess we can do: ``` [service] ALLOWED_USER_VISIBILITY_MODES = public,limited ``` For repositories I could not find an option.

Arnd Marijnissen commented

2023-02-14 14:32:36 +01:00

The issue with allowing anyone to create as many repositories as possible is that a simply 'clone, clone, clone, clone, clone' action of for example blender/blender will fill up the disks of the machine in no time before you even realize that somebody's adding a 1GiB disk-filler with each click. This is perhaps even quicker when somebody uses the API.

In essence, you're allowing an easy way for someone to do a DDoS on projects.blender.org while only requiring a blender-id.

Though I imagine that gitea'd only let you clone a repo once; not multiple times.. making exploitation of this a little less quick. It'd still be possibly by cloning other people's clones..

The issue with allowing anyone to create as many repositories as possible is that a simply 'clone, clone, clone, clone, clone' action of for example blender/blender will fill up the disks of the machine in no time before you even realize that somebody's adding a 1GiB disk-filler with each click. This is perhaps even quicker when somebody uses the API. In essence, you're allowing an easy way for someone to do a DDoS on projects.blender.org while only requiring a blender-id. Though I imagine that gitea'd only let you clone a repo once; not multiple times.. making exploitation of this a little less quick. It'd still be possibly by cloning other people's clones..

Arnd Marijnissen commented

2023-02-14 14:47:05 +01:00

I have added the ALLOWED_USER_VISIBILITY_MODES = public,limited setting to the current app.ini. It'll be in effect upon next restart. We'll just need to un-privatize the Orkspalter user.. Will do this , informing him about it, too.

I have added the ```ALLOWED_USER_VISIBILITY_MODES = public,limited``` setting to the current app.ini. It'll be in effect upon next restart. We'll just need to un-privatize the Orkspalter user.. Will do this , informing him about it, too.

Brecht Van Lommel commented

2023-02-14 16:06:58 +01:00

Creating a fork should use hard links and not take up much space, until someone starts modifying it and then it will gradually take up more space. So not sure this is really an issue.

Over time many people really will need ~5 repositories, we should not make that something that they have to go and ask permission for. 10 is not that much more and gives some headroom.

Creating a fork should use hard links and not take up much space, until someone starts modifying it and then it will gradually take up more space. So not sure this is really an issue. Over time many people really will need ~5 repositories, we should not make that something that they have to go and ask permission for. 10 is not that much more and gives some headroom.

Matti-Ranta commented

2023-02-14 18:06:16 +01:00

An upcoming PR may also be of interest for you https://github.com/go-gitea/gitea/pull/21820 instead of limiting on number of repos, you can also limit on total repo size for a user.

👍 2

Arnd Marijnissen commented

2023-02-16 09:37:07 +01:00

The user-visibility-setting's been set and gitea's been reloaded.

Brecht Van Lommel added the

policy

label 2023-03-13 11:27:33 +01:00

Brecht Van Lommel commented

2023-03-23 10:13:10 +01:00

I think we can close this. Control over repo size and disabling private repositories entirely would be good, and when they become available in Gitea we can enable such features.

But I don't think there is anything we have to spend time on here until we encounter a problem.

I think we can close this. Control over repo size and disabling private repositories entirely would be good, and when they become available in Gitea we can enable such features. But I don't think there is anything we have to spend time on here until we encounter a problem.

Brecht Van Lommel closed this issue

2023-03-23 10:13:11 +01:00

Sign in to join this conversation.