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

Closed
opened 2023-02-14 13:07:49 +01:00 by Arnd Marijnissen · 10 comments

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

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.
Author
Owner

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.

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

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

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.
Author
Owner

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..
Author
Owner

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.

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.

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.

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.
Author
Owner

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

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

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.
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: infrastructure/blender-projects-platform#33
No description provided.