RE: Repository Code Security (Plan Text)
Ok, thanks. I didn't realize there was a difference! I thought Git SCM ran GitHub. I haven't yet read this clear distinction. Of course I wasn't the one who chose GitHub in the first place. -Original Message- From: David Turner [mailto:dtur...@twopensource.com] Sent: Wednesday, June 24, 2015 4:00 PM To: BGaudreault Brian Cc: David Lang; Konstantin Khomoutov; git@vger.kernel.org Subject: Re: Repository Code Security (Plan Text) Git is not GitHub (any more than a cat is a cathouse). Git is a piece of software; GitHub is a hosting service for Git. Contact GitHub for GitHub support. On Wed, 2015-06-24 at 19:53 +0000, BGaudreault Brian wrote: > Hi David Lang, > > I'm sorry, but I'm confused by your first two responses. Am I not contacting > Git when I e-mail this e-mail address? You sound like you don't know exactly > how GitHub works. Should I be contacting someone else for GitHub support? > > Thanks, > Brian > > -Original Message- > From: David Lang [mailto:da...@lang.hm] > Sent: Wednesday, June 24, 2015 3:20 PM > To: BGaudreault Brian > Cc: Konstantin Khomoutov; git@vger.kernel.org > Subject: RE: Repository Code Security (Plan Text) > > On Wed, 24 Jun 2015, BGaudreault Brian wrote: > > > Thanks. Yes, I meant that "local code" is code pulled down to a person's > > PC, so we don't want them to leave the company with access to this code. > > So we can only prevent this scenario by running GitLab in our environment > > instead of running GitHub in the cloud? Would removing a GitHub account > > from the GitHub repository prevent them from accessing the code on their PC? > > > > How do you prevent private GitHub repositories from being pulled down to > > unauthorized PCs? > > policy, you say that it's against policy for someone to put company info on a > personal machine. > > You probably run your own repository that's only available within your > network (or over your VPN) rather than using a cloud service like > github (you may want to check with github to see if they can lock down > a private repo to only be accessed from specific IP addresses) > > you will also need to make sure that people don't plug personal laptops into > your corporate network, and that they don't use personal phones to access > company e-mail. > > The bottom line is that it's no different from preventing them from having > access to any other sensitive data in your company. What measures do you have > in place to keep them from taking sensitive Word Docs or spreadsheets when > they leave? do the same thing to deal with their access to code. > > David Lang > > > Thanks, > > Brian > > > > -Original Message- > > > > On Wed, 24 Jun 2015 18:18:00 + > > BGaudreault Brian wrote: > > > >> If someone downloads code to their notebook PC and leaves the > >> company, what protection do we have against them not being able to > >> access the local code copy anymore? > > > > What do you mean by "local code"? > > That one which is on the notebook? > > Then you can do literally nothing except for not allowing cloning your Git > > repositories onto random computers in the first place. > > > > If you instead mean the copy of code available in the repositories hosted > > in your enterprise then all you need to do is to somehow terminate the > > access of that employee who's left to those repositories. > > (This assumes they're accessible from the outside; if they aren't, > > the problem simply do not exist.) > > -- > > To unsubscribe from this list: send the line "unsubscribe git" in > > the body of a message to majord...@vger.kernel.org More majordomo > > info at http://vger.kernel.org/majordomo-info.html > >
RE: Repository Code Security (Plan Text)
Hi David Lang, I'm sorry, but I'm confused by your first two responses. Am I not contacting Git when I e-mail this e-mail address? You sound like you don't know exactly how GitHub works. Should I be contacting someone else for GitHub support? Thanks, Brian -Original Message- From: David Lang [mailto:da...@lang.hm] Sent: Wednesday, June 24, 2015 3:20 PM To: BGaudreault Brian Cc: Konstantin Khomoutov; git@vger.kernel.org Subject: RE: Repository Code Security (Plan Text) On Wed, 24 Jun 2015, BGaudreault Brian wrote: > Thanks. Yes, I meant that "local code" is code pulled down to a person's PC, > so we don't want them to leave the company with access to this code. So we > can only prevent this scenario by running GitLab in our environment instead > of running GitHub in the cloud? Would removing a GitHub account from the > GitHub repository prevent them from accessing the code on their PC? > > How do you prevent private GitHub repositories from being pulled down to > unauthorized PCs? policy, you say that it's against policy for someone to put company info on a personal machine. You probably run your own repository that's only available within your network (or over your VPN) rather than using a cloud service like github (you may want to check with github to see if they can lock down a private repo to only be accessed from specific IP addresses) you will also need to make sure that people don't plug personal laptops into your corporate network, and that they don't use personal phones to access company e-mail. The bottom line is that it's no different from preventing them from having access to any other sensitive data in your company. What measures do you have in place to keep them from taking sensitive Word Docs or spreadsheets when they leave? do the same thing to deal with their access to code. David Lang > Thanks, > Brian > > -Original Message- > > On Wed, 24 Jun 2015 18:18:00 + > BGaudreault Brian wrote: > >> If someone downloads code to their notebook PC and leaves the >> company, what protection do we have against them not being able to >> access the local code copy anymore? > > What do you mean by "local code"? > That one which is on the notebook? > Then you can do literally nothing except for not allowing cloning your Git > repositories onto random computers in the first place. > > If you instead mean the copy of code available in the repositories hosted in > your enterprise then all you need to do is to somehow terminate the access of > that employee who's left to those repositories. > (This assumes they're accessible from the outside; if they aren't, the > problem simply do not exist.) > -- > To unsubscribe from this list: send the line "unsubscribe git" in the > body of a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Repository Code Scope (Plan Text)
Thanks. So are you saying there are tools that will let us start a repo for a project with multiple submodules and then pull out the coding history for a specific submodule so we can create a separate repository just for that submodule? I've actually been doing a lot of research about Git for many things that Git doesn't have basic documentation for, but I wasn't sure how to search for an answer to this type of question. Plus, we're trying to adopt Git quickly, and since I'm not a developer I have a lot of research that has to be done to understand what developers understand and how we can manage GIt, which is slowing down our adoption of Git. Thanks, Brian -Original Message- From: Konstantin Khomoutov [mailto:kostix+...@007spb.ru] Sent: Wednesday, June 24, 2015 2:53 PM To: BGaudreault Brian Cc: git@vger.kernel.org Subject: Re: Repository Code Scope (Plan Text) On Wed, 24 Jun 2015 18:19:42 + BGaudreault Brian wrote: > What type of code scope should a repository contain? Can it be one > large program with many elements or should it just be part of a > program or can it be a project with multiple programs? What are the > recommendations? There are no recommendations because the structure of a repositories depends on the use case. If you're developing a library which might be used by more than a single other project, host it in a separate repository, and in the projects which use that library, refer to it using submodules. If you have a project which contains internal submodules (say, for .NET projects, it's common to have many so-called assemblies in a single project to provide modularity), there's little point in messing with separate repositories and it's simpler to keep everything in one place. Note that there are tools which allow you to split from a repository the history touching only the contents of a particular directory, and then glue such history back into some other repository. Using these are not exactly a walk in the park but at least this sort of things is doable. This means you might start with a simple solution and then shape it into a more appropriate form when you'll see the need for this. I should also warn you that your question appear to be a bit too broad which, IMO, suggests that you did not do much research on what's offerred by Git and its ecosystem, what's in a Git repo, how is it hosted, what are the best practices of managing complicated Git projects etc. And all this information is abundant in the internets... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Repository Code Security (Plan Text)
Thanks. Yes, I meant that "local code" is code pulled down to a person's PC, so we don't want them to leave the company with access to this code. So we can only prevent this scenario by running GitLab in our environment instead of running GitHub in the cloud? Would removing a GitHub account from the GitHub repository prevent them from accessing the code on their PC? How do you prevent private GitHub repositories from being pulled down to unauthorized PCs? Thanks, Brian -Original Message- From: Konstantin Khomoutov [mailto:kostix+...@007spb.ru] Sent: Wednesday, June 24, 2015 2:31 PM To: BGaudreault Brian Cc: git@vger.kernel.org Subject: Re: Repository Code Security (Plan Text) On Wed, 24 Jun 2015 18:18:00 +0000 BGaudreault Brian wrote: > If someone downloads code to their notebook PC and leaves the company, > what protection do we have against them not being able to access the > local code copy anymore? What do you mean by "local code"? That one which is on the notebook? Then you can do literally nothing except for not allowing cloning your Git repositories onto random computers in the first place. If you instead mean the copy of code available in the repositories hosted in your enterprise then all you need to do is to somehow terminate the access of that employee who's left to those repositories. (This assumes they're accessible from the outside; if they aren't, the problem simply do not exist.) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Repository Code Scope (Plan Text)
Hello, What type of code scope should a repository contain? Can it be one large program with many elements or should it just be part of a program or can it be a project with multiple programs? What are the recommendations? Thanks, Brian -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Repository Code Security (Plan Text)
Hello, If someone downloads code to their notebook PC and leaves the company, what protection do we have against them not being able to access the local code copy anymore? Thanks, Brian -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: proxy_windows_386.exe Firewall Notification
Lol, sorry. I meant to post in the Vagrant forums. Too many projects going on at the same time! -Original Message- From: Konstantin Khomoutov [mailto:kostix+...@007spb.ru] Sent: Thursday, June 11, 2015 3:43 PM To: BGaudreault Brian Cc: git@vger.kernel.org Subject: Re: proxy_windows_386.exe Firewall Notification On Thu, 11 Jun 2015 17:46:58 + BGaudreault Brian wrote: > Hello, when connecting to a Vagrant Shared VM via SSH, I'm getting a > Windows Firewall prompt about 'proxy_windows_386.exe' (in C:\Program > Files\hashicorp\vagrant\embedded\gems\gems\vagrant-share-1.1.0 > \localbin\), which looks like a malware-type name. Here's the > message: "Windows Security Alert. Windows Firewall has blocked some > features of this app. Windows Firewall has blocked some features of > proxy_windows_386.exe on all public and private networks.". > > So I did a quick search for this file name on the Internet as well as > the Git-SCM.com/community site and haven't found any clear > explinations about what this file is and if it's safe. If this is a > legitimate safe file, I think it's important that this is clearly > documented in the Git documentation. Can someone verify the details > about this file? I fail to get how did you manage to connect "proxy_windows_386.exe" with Git. Care to elaborate on this? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
proxy_windows_386.exe Firewall Notification
Hello, when connecting to a Vagrant Shared VM via SSH, I'm getting a Windows Firewall prompt about 'proxy_windows_386.exe' (in C:\Program Files\hashicorp\vagrant\embedded\gems\gems\vagrant-share-1.1.0\localbin\), which looks like a malware-type name. Here's the message: "Windows Security Alert. Windows Firewall has blocked some features of this app. Windows Firewall has blocked some features of proxy_windows_386.exe on all public and private networks.". So I did a quick search for this file name on the Internet as well as the Git-SCM.com/community site and haven't found any clear explinations about what this file is and if it's safe. If this is a legitimate safe file, I think it's important that this is clearly documented in the Git documentation. Can someone verify the details about this file? Thanks, BRIAN -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html