Forking a private repo from one private organization to another leaks the source organisation name #9827

New Issue

GiteaMirror · 2025-11-02T08:50:38-06:00

GiteaMirror commented

2025-11-02 08:50:38 -06:00

Originally created by @kbingham on GitHub (Nov 11, 2022).

Description

I am running gitea 1.17.0 and I have two separate groups that are using the same server.
I wanted to share a project from one group to the other, to provide access to the code pre-release - but did not intend to share the source organisation, as they are separate.

When I forked from organisation1 to organisation2, I get a repository visible to organisation2 with the following message:

  organistion2 / uvc-gadget  [Private]
forked from organistion1/uvc-gadget

This seems like a leak of private information between the two groups, so I would consider this a 'bug', however it could also simply be a feature request to ask

"Please ensure that information such as the organisation/customer name is not leaked when forking a project between private organisations."

Gitea Version

1.17.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

provided by docker : gitea/gitea:1.17.0

Operating System

Linux

How are you running Gitea?

Docker compose.

version: '2.4'
services:
  web:
    image: gitea/gitea:1.17.0
    volumes:
      - /srv/gitea/data:/data
    expose:
      - 3000
    ports:
      - "4444:22"
    restart: unless-stopped

Database

SQLite

Originally created by @kbingham on GitHub (Nov 11, 2022). ### Description I am running gitea 1.17.0 and I have two separate groups that are using the same server. I wanted to share a project from one group to the other, to provide access to the code pre-release - but did not intend to share the source organisation, as they are separate. When I forked from organisation1 to organisation2, I get a repository visible to organisation2 with the following message: ``` organistion2 / uvc-gadget [Private] forked from organistion1/uvc-gadget ``` This seems like a leak of private information between the two groups, so I would consider this a 'bug', however it could also simply be a feature request to ask "Please ensure that information such as the organisation/customer name is not leaked when forking a project between private organisations." ### Gitea Version 1.17.0 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version provided by docker : gitea/gitea:1.17.0 ### Operating System Linux ### How are you running Gitea? Docker compose. ``` version: '2.4' services: web: image: gitea/gitea:1.17.0 volumes: - /srv/gitea/data:/data expose: - 3000 ports: - "4444:22" restart: unless-stopped ``` ### Database SQLite

GiteaMirror added the type/enhancement label 2025-11-02 08:50:38 -06:00

GiteaMirror commented

2025-11-02 08:50:39 -06:00

@lafriks commented on GitHub (Nov 11, 2022):

So proposed solution is to have option to hide fork information but keep it as forked repository?

@lafriks commented on GitHub (Nov 11, 2022): So proposed solution is to have option to hide fork information but keep it as forked repository?

GiteaMirror commented

2025-11-02 08:50:39 -06:00

@kbingham commented on GitHub (Nov 11, 2022):

Yes, I still believe it's useful to fork from one organisation to another, even if both are private (after all, I just had that need/requirement) - but the issue is that there was information leaked that was private.

In this instance, the code could be shared, but the fact that two organisations were working on the same thing was not supposed to be leaked. Of course I could have manually created the repository in both places, or had a base fork from a non-private or generic named private organisation maybe...

Otherwise, it could only be visible to members which are in both organisations perhaps? I'm not sure what the correct implementation is - but the result of identifying the hidden/private organisation to another hidden/private organisation was the bug/fault in my view.

@kbingham commented on GitHub (Nov 11, 2022): Yes, I still believe it's useful to fork from one organisation to another, even if both are private (after all, I just had that need/requirement) - but the issue is that there was information leaked that was private. In this instance, the code could be shared, but the fact that two organisations were working on the same thing was not supposed to be leaked. Of course I could have manually created the repository in both places, or had a base fork from a non-private or generic named private organisation maybe... Otherwise, it could only be visible to members which are in both organisations perhaps? I'm not sure what the correct implementation is - but the result of identifying the hidden/private organisation to another hidden/private organisation was the bug/fault in my view.

GiteaMirror commented

2025-11-02 08:50:39 -06:00

@lunny commented on GitHub (Nov 12, 2022):

But as a fork repository, he should always contribute code back to parent repository. I think it's difficult to hide all these information and keep it as a fork repository.

@lunny commented on GitHub (Nov 12, 2022): But as a fork repository, he should always contribute code back to parent repository. I think it's difficult to hide all these information and keep it as a fork repository.

GiteaMirror commented

2025-11-02 08:50:39 -06:00

@kbingham commented on GitHub (Nov 12, 2022):

Who mandates that they should contribute back? (in this instance, as a member of both groups, I'd be in control of that anyway) - but the point is that the previously private organisation A (lets call them Microsoft) are now exposed to private organisation B (again for example sake lets call them Apple) ... This code in question belongs to 'me' in both cases, but I wanted to take work done for A/Microsoft, and share it in advance of making everything public with B/Apple - but now I have leaked the fact that I am working with Microsoft to Apple, which maybe they might not like - or might not have been in my interests to acknowledge at the time.

It's the distinction that a repository was forked from a private organisation to a separate private organisation that I'm querying here.

Now - I acknowledge, that the repository was 'forked' to be able to duplicate/replicate the repository from one private group to another. Perhaps that is considered a shortcut - and simply not an acceptable way to take an existing repository from one private group to another, but gitea allowed me to do so - and keep the repository private - but did so at the cost of leaking this originator information.

*All company names are examples only here, I don't work with/for either Apple or Microsoft.

@kbingham commented on GitHub (Nov 12, 2022): Who mandates that they should contribute back? (in this instance, as a member of both groups, I'd be in control of that anyway) - but the point is that the previously private organisation A (lets call them Microsoft) are now exposed to private organisation B (again for example sake lets call them Apple) ... This code in question belongs to 'me' in both cases, but I wanted to take work done for A/Microsoft, and share it in advance of making everything public with B/Apple - but now I have leaked the fact that I am working with Microsoft to Apple, which maybe they might not like - or might not have been in my interests to acknowledge at the time. It's the distinction that a repository was forked from a private organisation to a *separate* private organisation that I'm querying here. Now - I acknowledge, that the repository was 'forked' to be able to duplicate/replicate the repository from one private group to another. Perhaps that is considered a shortcut - and simply not an acceptable way to take an existing repository from one private group to another, but gitea allowed me to do so - and keep the repository private - but did so at the cost of leaking this originator information. *All company names are examples only here, I don't work with/for either Apple or Microsoft.

GiteaMirror commented

2025-11-02 08:50:39 -06:00

@kbingham commented on GitHub (Nov 12, 2022):

Updated title to clarify that it's the name of the private organisation that is leaked, not any code, (which is obviously explicitly shared by the nature of the forking action)

@kbingham commented on GitHub (Nov 12, 2022): Updated title to clarify that it's the *name* of the *private* organisation that is leaked, not any code, (which is obviously explicitly shared by the nature of the forking action)

GiteaMirror commented

2025-11-02 08:50:40 -06:00

@lunny commented on GitHub (Nov 12, 2022):

I think maybe you need a repository copy feature but not fork? Even though the source can be hidden, since it's a fork repository, others will always ask you where the repository forked from.

@lunny commented on GitHub (Nov 12, 2022): I think maybe you need a repository copy feature but not fork? Even though the source can be hidden, since it's a fork repository, others will always ask you where the repository forked from.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9827