Issue #4056 open

Admin access to the fork repo (BB-4257)

pamanseau
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 (32)

  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

    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 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

    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 @beeblebrox3. 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. Max Galbusera

    Jimmy Ngu - well, Github does that:

    https://help.github.com/articles/deleting-a-private-fork-of-a-private-user-repository/

    https://help.github.com/articles/deleting-a-private-fork-of-a-private-organization-repository/

    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. Fabio Carneiro

    Kevin Stanton nice point of view, +1.

    This feature also allows a code integration for example to test code submitted as pull request from a fork by giving read permissions in the main repo. Something that can't be achieved other way.

  15. Log in to comment