search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
43.08k stars 5.31k forks source link

Cannot Change Repository Fork Visibility to Match Upstream Repository #31386

Open inferenceus opened 3 weeks ago

inferenceus commented 3 weeks ago

Description

When an upstream repository changes its visibility after forking it, the forked repository does not automatically switch to match, and cannot be manually changed.

Gitea Version

1.22.0

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

2.45.2

Operating System

Gentoo Linux

How are you running Gitea?

Installed from Gentoo Linux's official gentoo repository using operating system package manager.

Database

PostgreSQL

kemzeb commented 3 weeks ago

If I understand your problem, I believe you are saying that a forked repository does not automatically change its visibility to match the original repository when its visibility is changed? If this is the case, I believe this is actually expected behavior.

GitHub also does this, where their docs explain that "public repository's forks will remain public in their own separate repository network even after the upstream repository is made private".

inferenceus commented 3 weeks ago

What is even the point of this behaviour? When someone has access to a private repository, they could just manually copy the code or take screenshots etc; it's not security or privacy. Everyone in a private repository should be trusted to begin with.

I don't want my fork to be private; I was forced to make it private. Now, the upstream repository has gone public and my fork remains private, preventing anyone from seeing changes I've made without me submitting a pull request to upstream, which I don't always want to do.

It makes no sense for the system to work this way. Can this be disabled? If not, there ought to be a feature for this.

inferenceus commented 3 weeks ago

To add to my previous comment, I could simply clone the upstream repository (not as a fork), and have that public, while having a reference to where I got the original code from, exposing the contents of the upstream repository. This forced-visibility rule is simply a hindrance.

kemzeb commented 3 weeks ago

I see what you mean. I was not aware that forks (both in GitHub and Gitea) cannot change their visibility. In the case of GitHub, it seems this is due to a potential security concern rather than an arbitrary design decision. I haven't been able to find any docs explaining this security problem but found this StackOverflow answer that seems to suggest that attackers can gain access to private source code. It seems to concern their "repository networks" concept (where a "network" appears to be some form of space optimization that GitHub implemented to handle the case of storing many forks). I also found discussions opened about this fork visibility decision.

In regards to Gitea, it doesn't look like we implement a similar optimization when looking at repo-related code in the data layer. I can't speak on what decision should be made here since I'm not yet familiar with the implementation details related to forks, so I'll leave it up to those who are to decide.