4 ms·

But nothing is stopping them from cloning and pushing up to BitBucket or a private git hosting service. You merely have the appearance of cleanliness with none

But nothing is stopping them from cloning and pushing up to BitBucket or a private git hosting service. You merely have the appearance of cleanliness with none of the security. The only way to really protect yourself is with a contract that stipulates the repo and any clones a contractor may have access to must be destroyed upon termination of the contract.

sevensor 9y ago
For that matter, what's stopping them from pushing a clone to Github instead of forking through Github's web interface?
snowwrestler 9y ago
This has nothing to do with security. Would you upload secrets into a private Github repo? I wouldn't. Private repos are not more secure than public repos. Github is a tool for collaboration. The point of a private repo is to manage who you are collaborating with. Once I don't want to collaborate with someone anymore, there is no reason for them to have a Github fork of my code anymore. As I said, it's cleaner. I'm fully aware that they can save a local copy (did you read my 3rd paragraph above?), and of the importance of contracts.
- andrewstuart2 9y ago
  Access control is 100% security. If you have a private GitHub repo, you have uploaded secrets. All that code is your secret. You pay GitHub to protect all the copies they know about, but you are fooling yourself if you rely on that after you've given access to that private repo away. You fundamentally can't revoke knowledge, just future access.
  - snowwrestler 9y ago
    No, secrets are pieces of information that you could use to compromise my production environment--like passwords or private keys. Those should never be uploaded to Github, period.
    - andrewstuart2 9y ago
      You're talking about credentials. Secrets are often credentials, but more generally refer to anything confidential.
      - onenite 9y ago
        Code doesn’t necessarily have to be confidential. “Secret recipe” algorithms, maybe. It’s about trade-offs. If you must have “trade secrets” amongst your code, perhaps you can keep that code available only to whom you trust will follow your wishes with it, and have separate repos to share wherein you do not care as much about collaborators “stealing” the code. As soon as you let someone into your codebase, almost anything can happen, right? There are cases where it would make sense to sacrifice risks related to code-copying in order to have faster/better development. Also, what’s stopping anyone working at ANY company from taking the company code and doing whatever they want? Code is seldom everything.
  - deleted 9y ago
    [deleted]
  - abiox 9y ago
    as far as i can tell, they didn't speak to "revoking knowledge", and did speak to "future access"... so your comment reads strangely to me.
jrochkind1 9y ago
Heck, nothing is stopping them from cloning and pushing to _github_ as an independent repo. Except if that were as easy and obvious as forking, the OP wouldn't be complaining about it, heh.
abiox 9y ago
> But nothing is stopping them from cloning and pushing up to BitBucket or a private git hosting service. ...which is not a github fork, and not what they're talking about.
InclinedPlane 9y ago
"Nothing"? Obviously that's untrue. There are many things stopping them. Professionalism, for example. There's "nothing" stopping someone at a job from printing every single one of their corporate emails and putting them into a binder to save forever, even after they've left the position. Nothing except professionalism, a sense of business ethics, the law, and the fact that it's a huge hassle. This seems like a problem that's not a problem. If you are working in a private repo then there should be some formalized arrangement on who owns the code and who doesn't, and that would be the originator of the private repo. If, for some reason, that relationship is less clear, then as you say other contributors can just create their own clones of the repo elsewhere. If the obvious relationship is one of collaborative ownership, then a public repo is the obvious choice.

sevensor 9y ago

For that matter, what's stopping them from pushing a clone to Github instead of forking through Github's web interface?

snowwrestler 9y ago

This has nothing to do with security. Would you upload secrets into a private Github repo? I wouldn't. Private repos are not more secure than public repos. Github is a tool for collaboration. The point of a private repo is to manage who you are collaborating with. Once I don't want to collaborate with someone anymore, there is no reason for them to have a Github fork of my code anymore. As I said, it's cleaner. I'm fully aware that they can save a local copy (did you read my 3rd paragraph above?), and of the importance of contracts.

andrewstuart2 9y ago
Access control is 100% security. If you have a private GitHub repo, you have uploaded secrets. All that code is your secret. You pay GitHub to protect all the copies they know about, but you are fooling yourself if you rely on that after you've given access to that private repo away. You fundamentally can't revoke knowledge, just future access.
- snowwrestler 9y ago
  No, secrets are pieces of information that you could use to compromise my production environment--like passwords or private keys. Those should never be uploaded to Github, period.
  - andrewstuart2 9y ago
    You're talking about credentials. Secrets are often credentials, but more generally refer to anything confidential.
    - onenite 9y ago
      Code doesn’t necessarily have to be confidential. “Secret recipe” algorithms, maybe. It’s about trade-offs. If you must have “trade secrets” amongst your code, perhaps you can keep that code available only to whom you trust will follow your wishes with it, and have separate repos to share wherein you do not care as much about collaborators “stealing” the code. As soon as you let someone into your codebase, almost anything can happen, right? There are cases where it would make sense to sacrifice risks related to code-copying in order to have faster/better development. Also, what’s stopping anyone working at ANY company from taking the company code and doing whatever they want? Code is seldom everything.
- deleted 9y ago
  [deleted]
- abiox 9y ago
  as far as i can tell, they didn't speak to "revoking knowledge", and did speak to "future access"... so your comment reads strangely to me.

jrochkind1 9y ago

Heck, nothing is stopping them from cloning and pushing to _github_ as an independent repo. Except if that were as easy and obvious as forking, the OP wouldn't be complaining about it, heh.

abiox 9y ago

> But nothing is stopping them from cloning and pushing up to BitBucket or a private git hosting service. ...which is not a github fork, and not what they're talking about.

InclinedPlane 9y ago

"Nothing"? Obviously that's untrue. There are many things stopping them. Professionalism, for example. There's "nothing" stopping someone at a job from printing every single one of their corporate emails and putting them into a binder to save forever, even after they've left the position. Nothing except professionalism, a sense of business ethics, the law, and the fact that it's a huge hassle. This seems like a problem that's not a problem. If you are working in a private repo then there should be some formalized arrangement on who owns the code and who doesn't, and that would be the originator of the private repo. If, for some reason, that relationship is less clear, then as you say other contributors can just create their own clones of the repo elsewhere. If the obvious relationship is one of collaborative ownership, then a public repo is the obvious choice.