Admin access to the fork repo (BB-4257)

Issue #4056 open
created an issue

I have a main repo that is only private and I have some peoples with a fork of this repo.

When someone create a fork of my private main repo I should have admin access that is not deletable to there fork repo. This way if I want to delete the fork or control what is done by this fork I can manage it.

I have an employe with 2 forks from my main repo and this employee is not working for me anymore. So I would like to delete theses 2 repo but I don't have access.

Thank you

Comments (47)

  1. Marcus Bertrand staff

    While the UI could, in theory, provide this sort of control, nothing would stop a user with a local clone of your repository from just manually forking it by pushing it up into their own account. We will open a ticket for investigating this in the UI, but please keep in mind this caveat.

  2. Andy Fleming

    I have the same situation here - the main repo was forked by a team member who has now finished working with us, and I can't delete the fork in his account.

    While I understand that they could have previously made an offline copy or local clone, it would still be nice to have the option, similar to revoking access or removing someone from a team, to delete or revoke access to the fork.

  3. pamanseau reporter

    This is mandatory for a company that deals with employées that fork source code. The owner of the main repo should be able to delete or revoke rights on all forks.

    I still don't understand why this is not implemented yet.

  4. Jimmy Ngu

    I don't understand why you guys would need this. It might soothe your paranoia, but will not do anything else.

    Chunks of your project (ideas / features / library) are probably "borrowed" from projects that your employees had worked before elsewhere. The ability to control the flow of codes is an illusion.

    Just think about it. There are just too many ways they can do this they really want to. It's like renting a movie to somebody, the the guy makes a copy and you want to have "some sort" of control over his copy.

    Cool story bro ;)

    Once you remove his access to the main repo he can no longer access new updates from the main repo. Continuous improvement is always the best way to protect your intellectual property. The pirate copy loses its value as soon as you have a new release.

    If you're still paranoid, attach a copyright license to the project or make them sign an NDA.

  5. Jonathan Cruz

    @Ruben Stolk It's easy to talk lightly about something which doesnt concern you and of which you could never understand the concequences without taking a look at the particular situation. First @Jimmy Ngu talks about his personal philosphy. Then he is suggesting prevention measures, which are obviously not very helpful when you are past that stage. #verysmart ;) And now i tagged you @Ruben Stolk @Ruben Stolk ... Three times! And tell Steve that he should have let Bill sign an NDA.

  6. Jimmy Ngu

    Well enlighten us then @Jonathan Cruz how will this feature solve your particular situation? So far I don't see any valid arguments from you on how this feature could makes any sense. Keep telling yourself that everything is fine once you've deleted the forked repo, if it helps you sleep at night.

  7. Luís Henrique Faria

    Of course this does not remove access to the code that someone has copied, but this still would be a nice feature. The user may not have made copy of the code somewhere. Why give him time to think and do this later? Different people have different needs. The fact that some people are looking for this feature only proves it.

  8. Andrew Campher

    There is hope though, how we do it in our organisation is we create our own private fork then give developers write access to the fork. So they never create their own forks. Then as for procedure you also need to give them read access to the main repo whereby they pull in latest code. You are then able to control the testing / Pull requests yourself from the new private fork - working smoothly for a couple of months now. If the developer is no more just remove him from accessing your main and fork.

  9. Jimmy Ngu

    I respectfully disagree on what @Luís Henrique Faria had said. I think it's mostly the lack of understanding on a distributed SCM system. And the reason why this feature was marked as "wontfix" almost 2 years ago.

    A fork has no different than a clone onto your local machine, aside from the convenience of access control. A fork is just a clone done on the server side.

    That's why we work with Pull Requests when collaborating. Only the gatekeeper, code reviewer and owner should have WRITE access. And all your testing / CI setup should (hopefully) be only hooked on to the controlled repo, not forks.

    Denying access to a fork is, as I've said before, an illusion of control. Since

    a) You can't deny access to a local clone (a "fork"), b) All developers will have a local cloned copy of the code during dev. c) Those who want to refer to the code later on as reference (or malicious reasons) would have kept them. d) And what's stopping them from, oh say, creating another repo on their account and pushing the code there (which is also a "fork") which you have zero control or knowledge about.

    You're worrying about 99% of the legit & honest people that worked with you, would do with your code. To me, that's no greater insult to a developer's professionalism and plain old paranoia.

    That's why coming up with SOPs that include removing user access from a fork that you own (like how @Andrew Campher described) is really unnecessary. It creates complications to the workflow and trains a mind to think of a client-server SCM system while working on a distributed SCM system. It just makes no sense.

    Removing access from an ex-staff / ex-developer from the main repo is enough to ensure the "safety" of your code (if there's such a thing). Other safety measure will need to come in a form of agreement or other legal bindings.

  10. Luís Henrique Faria

    I fully understand your point of view, @Jimmy Ngu, but still not agreeing.

    My point is that just because a particular measure will not guarantee the security of the code that it should not be taken. If it can, in some circumstances, help prevent a problem, it must be available and, in my opinion, this is the case here. I am not advocating that it is a perfect solution for the security of our code, but is a little help.

  11. Jimmy Ngu

    That's cool by me @Luís Henrique Faria. If it works for you, it works for you :)

    I'm just pointing out that this is not an actual "security" measure. Thinking that it is one, actually makes it a security flaw. It makes you think that you're safe when you're actually not. It makes you ignore the importance of things like a simple NDA, that might actually lower the chance of a code leak. It might not stop a code leak per se, but it will give you a significant advantage when seeking any legal restitution, which is a much effective deterrent compared to what this feature can offer.

    This feature is nothing more than a smoke screen that makes people believe that they are that much safer. And I think it's actually "safer" to NOT implement this feature at all. I would be surprise to see any reputable hosted SCM service actually implementing this kind of feature.

    Human factor is always the weakest link in software security. I understand it's hard to convince people (e.g. management) that this is how things are. And sadly sometimes even harder for tech people.

    But that's the fact. And I do hope I can convince some of you to work with facts rather than false impressions.

  12. MaxG

    @Jimmy Ngu - well, Github does that:

    I know Github is a competitor, but you can't deny that it is a "reputable hosted SCM service".

    Besides this, If I work for ten different companies and fork ten projects, should I still have access to all the ten projects after quitting all these jobs? That is a recipe for copying :)

  13. Kevin Stanton

    @Jimmy Ngu while you are correct, there's nothing said feature could do to revoke someone's access to a local fork or clone, there is still value to implementing it. Here's why:

    It is possible that while the former employee themselves has no malicious intent, another scenario is one in which a hacker gains access to their (possibly orphaned) bitbucket account (i.e. through a password breach elsewhere and they've used the same password on multiple sites). In this instance, a fork of a former employee may lie dormant for years and still have sensitive information that an attacker could use. And you are saying to your customers, "tough shit, you can't do anything about this."

    Your argument basically is like a former renter with a copy of a key to an apartment. You're saying that they've already got a copy of the key, so changing the lock is pointless because that person already has been inside the apartment before and knows what's inside it. Even though that key might be stolen or used by someone else who hasn't signed a legal agreement.

    Please implement this feature.

  14. Guillaume Simard


    GitHub's solution is nice, elegant and makes perfect sense.

    Our use case: Everyone can clone the repository and put it on his job computer. Employees are well aware that they should not copy the code onto a personal computer or upload it on, say, GitHub.

    When someone leaves the company, we keep his computer. Sure, if he wants to hurt the company he can leak the source code, upload it to a private bitbucket repository or do whatever he wants. But let's assume he's a good guy.

    If he were to fork the repository, we wouldn't be able to do anything about that private fork. It's just as if he had a copy of the code on a private computer (which we do not allow.. remember we assume he's a good guy).

    If we could delete private forks of repositories made by users that are no longer with us, we could avoid this situation.

    We realize that this is not a security feature but sadly due to the current state of private repository forks we have to resort to disabling forks.. and this sucks.

    I hope you understand our current situation and that you take this use case into consideration when evaluating this feature request.

  15. Hatem Nassrat

    Thats the current state @Guillaume Simard - this issue is about changing that behaviour so that bitbucket is usable for private companies. Bitbucket is the goto for private repos, or at least should win that space easily, having this feature would make it go the extra mile.

  16. Manuel Baleato


    I've just started setting up Bitbucket teams for use in my organisation as we transition from TFS and the lack of this feature has me wondering if I've chosen the right solution. Maybe I should look at GitHub.

  17. olimits7

    What's the status of this issue?

    My developer forked my private repo but I can't see his forked repo at all. When I go under his profile it doesn't show me his forked repo like it does on Github.

  18. conan chen

    We have bitbucket server commercial version installed.

    As an Bitbcket system administrator, I need to clear/remove the forked repositories no used any more.

    But now I can not see the forked repositories!

  19. Moritz Becker

    I would expect this to work exactly as described in This way, owners can ensure to stay in control of their code when using a forking workflow.

    At the moment, I don't see how a private organization could implement a forking workflow using bitbucket without risking that employees create forks in their private accounts, effectively causing the upstream repository owner to lose control over this fork. If there was a way to restrict the target space of forks to the team space it would not be such a big issue any more.

  20. Log in to comment