Slashdot Mirror


Ask Slashdot: Self-Hosting Git Repositories?

mpol writes "We're all aware of PRISM and the NSA deals with software houses. Just today it was in the news that even Microsoft gives zero-day exploits to the NSA, who use them to prepare themselves, but also use the exploits to break into other systems. At my company we use Git with some private repositories. It's easy to draw the conclusion that git-hosting in the cloud, like Github or Bitbucket, will lead to sharing the sourcecode with the NSA. Self-hosting our Git repositories seems like a good and safe idea then. The question then becomes which software to use. It should be Open Source and under a Free License, that's for sure. Software like GitLab and GNU Savane seem good candidates. What other options are there, and how do they stack up against each other? What experience do people have with them?"

23 of 165 comments (clear)

  1. Github by curunir · · Score: 2

    You know it, you love it. Just continue using Github (just on your own servers)

    --
    "Don't blame me, I voted for Kodos!"
  2. GitBlt by stanlyb · · Score: 3, Insightful

    Pretty good web interface. But in general, you dont need any special repository server, as GIT itself is the server, and client, etc. The only difference between dedicated server and a simple shared folder is the authentication, and the questionable convenience of having a web interface.

  3. Re:If you don't want people to see the source... by Anonymous Coward · · Score: 5, Informative

    1. To moderators: this is not a Troll. A misunderstanding, yes. A Troll, no. This leads us to...

    2. To commentors: You don't need to insult somebody to correct them. Here's how:

    Git repositories aren't necessarily OSS/FS. You can host proprietary software if you pay them.

  4. You really need to clarify this. by Nutria · · Score: 2, Insightful

    It's easy to draw the conclusion that git-hosting in the cloud, like Github or Bitbucket, will lead to sharing the sourcecode

    Your "family jewels" live on someone else's machine, which is purposefully designed to let anyone on the Internet get access to it. So of course some Others* are going to get access to it even though you've password protected it.

    * And it doesn't even have to be PRISM, Echelon or the DOJ. Your competition, plain old script kiddies, Russian cyber-criminals, Chinese hackers and a host of others might break in.

    --
    "I don't know, therefore Aliens" Wafflebox1
    1. Re:You really need to clarify this. by gl4ss · · Score: 2

      insightful!? ... ever heard about private github repositories?!

      I thought he was referring to them, but poorly worded. you see, github is meant for to be accessible from anywhere.. private repos are supposed to be limited to people you authorize of course. but still if you want to keep it private storing it on any cloud server or even net accessible private server is no good.

      --
      world was created 5 seconds before this post as it is.
  5. How does this protect you? by Tr3vin · · Score: 4, Informative

    I get why everybody is stocking up on tinfoil right now but based on what the NSA can supposedly do, hosting stuff internally isn't going to keep it away from them. After all, Microsoft is handing over all of the zero-day exploits and they are free to peruse the source to the Linux and BSD kernels.

  6. Fossil by Anonymous Coward · · Score: 2, Informative

    http://www.fossil-scm.org/

    The self-contained, stand-alone binary supports distributed version control, wiki, and bug reports. (The entire Fossil website linked above is simply a running copy of Fossil. When you clone a Fossil repository, you don't get just the source code, you get the whole website.) The same self-contained, stand-alone binary acts as the client, or as a standalone web server, or as a CGI program, or as a server run from inetd/xinetd.

  7. Re:If you don't want people to see the source... by stewsters · · Score: 2

    You can host your own git repository and access it over ssh. Make a new account on a server, generate keys on your clients and add it to that authorized_keys file. Make sure it can access the .git directory. This seems to be what github does, but in a more automated way. You wont get the cool webpages to browse source, but honestly it is a security hole.

  8. Don't need to leave the cloud by willy_me · · Score: 4, Informative

    Just host the GIT repository on a VM in the cloud. Look at TurnkeyLinux or Bitnami. Configure the VM to only accept encrypted connections and use an excrypted file system. One could still break into your VM if they wanted to - but it would be a lot of work and no government agency would bother investing the time and money to do so. If the NSA wants your source code you can bet they will get it - even if it's hosted locally.

    But the reality is you are being paranoid. The government does not care about your source code. They want to know who your friends are and when you communicate with them. If a rotten egg is found they want to be able to check for rot in neighboring eggs - because rotten eggs are generally connected.

    1. Re:Don't need to leave the cloud by MtHuurne · · Score: 2

      If an encrypted file system is mounted, the key is somewhere in memory. If it's mounted in a VM and you have access to the host machine, you can easily create a snapshot of the VM's memory. I don't think it would be all that much work for a person familiar with the internals of the OS kernel in question to figure out where the key is stored in memory. Another thing they could do with a VM snapshot is patch the authentication functions, so any login is accepted. There are countless ways of gaining entry into a system if you can freely examine and change its memory.

      You assume this would be too much work, but while the research to find a successful attack is non-trivial, repeating that attack is not that difficult and could be fully automated for popular OSes.

      Handing over the key to the attacker and hoping it's well hidden enough that it won't be extracted is pretty much what DRM does. And this is not even as obfuscated as the average DRM, since most operating systems are either open source or at least offer their source code for inspection.

  9. What features do you need? by Burning1 · · Score: 2

    If all you need is a place to dump your code, GIT is a perfectly functional GIT server. If you want full features, and damn the cost, you could consider GitHub enterprise.

  10. Re:White Hats & Ethical Hacking by stewsters · · Score: 2, Interesting

    I agree. Might as well sell the vulnerabilities, thats what m$ does.

  11. Try Gitolite by davesque · · Score: 2

    At my company, we use Gitolite and I've only had good experiences with it.

    https://github.com/sitaramc/gitolite/wiki

  12. Re:If you don't want people to see the source... by wolrahnaes · · Score: 3, Insightful

    No, you still misunderstood. OP was asking for an open + free solution for self hosting, not saying that all their code they wanted to host is open + free.

    This was the important part:

    At my company we use Git with some private repositories.

    The private repositories are key. Those are not open. They may contain code which will eventually be released under an open and/or free license, but they are not currently. OP wants to take those out of "the cloud", using open/free solutions.

    --
    I used to get high on life, but I developed a tolerance. Now I need something stronger.
  13. Re:If you don't want people to see the source... by CrudPuppy · · Score: 2

    Yeah, no sure what's so hard about this. We recently moved from SVN to Git (all private) and I grabbed a copy of Git and set it up within about 20 minutes using the docs having never used or setup Git before. I needed help from my developers to port all their code form SVN to Git, but that's not rocket science either.

    There's little point in not going private if you don't plan to share your code with the world (we sure as hell won't be sharing our closed-source, for-profit software anytime soon).

    --
    A year spent in artificial intelligence is enough to make one believe in God.
  14. Other Alternatives by paskie · · Score: 5, Informative

    You should clarify what are you after. Do you just need a place where to push + pull, or are you looking at something akin to the GitHub experience?

    Aside of GitLab, also consider Gitorious. I'm not sure about how easy it would be to get GNU Savannah up and running, and Git is only a small part of what it does.

    You can also find GitHub Enterprise interesting if you are ready to pay; I assume(!) it will call home to verify the licence though so making sure no stuff is sent to NSA may be tricky. ;-) Upside is minimal setup hassles for you.

    You may also find the Girocco platform interesting (CGIs for project index + project management web interface, and gitweb; much smaller than the above-mentioned ones so you have a good chance to actually review all the code for yourself, but it's also more raw experience; disclaimer: I'm the main author of Girocco).

    If you are fine with a simpler experience, you can simply use git-daemon (or purely SSH and git installed on the server), possibly gitolite to easily manage user access and gitweb/cgit for a web interface - there's no special magic, the Git repositories are just directories on the server.

    --
    It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
  15. Re:Do you understand what Open Source means? by Anonymous Coward · · Score: 2, Interesting

    It's open to everyone. Not just the people you like.

    Arguing "the NSA having access to GitHub is a threat to Open Source" is arguing opening the source is a threat to Open Source.

    Come back when your paranoid fantasies at least resemble the reality I live in.

    Who are you even talking to? The article doesn't say anything about any threat to open source at all. He's talking about closed source code, stored on a third party repository, and has wisely decided that he'd rather just host it all himself. In order to do so, he'd like to use a management product which is open source.

    Reading comprehension- get some.

  16. Re:BS fatalism by Giant+Electronic+Bra · · Score: 4, Insightful

    LOL, I'm not saying anyone HAS done anything. The point is, once you assume a certain level of paranoia the number of things to be paranoid about, and the number of them which are utterly beyond your ability to control grows almost without bound. Limit your objectives to those which make sense, and don't worry about the things that are beyond your control.

    You'd think that backdoors and such inserted by compilers etc would be found, but actually Ken Thompson successfully injected a backdoor into Unix early on via the PCC (Portable C Compiler) which allowed him access to ANY Unix system for a number of years. It spread to pretty much every system in existence and was never detected before he finally revealed its existence in order to demonstrate exactly my point. This was accomplished via a 'double code injection'. When PCC compiled itself it added a chunk of code that injected a backdoor during the compilation of the login program. Once the first generation of this back door existed the source was removed from PCC, but of course since PCC was self-hosting the ONLY way to compile it was with itself, and since the copy that was used for that HAD logically to be descended from the original binary the injection and the back door were virtually undetectable.

    Obviously not every such scheme would work and remain hidden for years, but it is demonstrably possible. Its certainly not too much to think that there are systems that DO contain back doors of some high degree of subtlety. For instance it would be MUCH easier for Windows to contain some for instance, and the NSA etc have almost certainly operatives who work for MS.

    Frankly, don't loose sleep over it. Software at some level simply cannot be truly secure.

    --
    "Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
  17. Re:This is all futile anyway by MtHuurne · · Score: 3, Insightful

    Obviously you need to be pretty paranoid to believe that the NSA has corrupted the GNU toolchain in such a way that it inserts back doors in every OS kernel it compiles, that the debugger has code inserted in it to not display said OS code, etc, but it is technically possible.

    If there was only one program that could display object files, it could be done. But any number of programs can display object files, including plain hex editors. If every single hex editor would have been compromised, we would have noticed by now. And a compiler that can detect "oh, this code is a hex editor, I'd better patch it to make it hide the nasty stuff when it's run" is way beyond what can currently be created, certainly not running fast enough on an ordinary PC to avoid detection.

    Besides, it's not the question of whether the NSA can access your files if they consider it their highest priority. The problem is that if there is an easy, low-cost way to access your files, an individual rogue agent might do it and hand your files to your competitor (a favor for a friend or for a little extra cash) without the rest of the NSA even knowing about it, or finding out only after the fact.

  18. Re:If you don't want people to see the source... by Eskarel · · Score: 3, Insightful

    No, the OP is just a paranoid douche bag. He thinks the NSA is out to get him (which they very well could be), but then wants someone to give him an off the shelf product to magically make his source NSA safe. He complains about Microsoft sharing zero days with the NSA and then wants an open source solution which by design will share zero days with everyone, including the NSA.

    In essence the only way to actually make this work if you really really really want to be NSA proof and still have your system externally accessible is as follows.

    1. Create a local unhosted Git Repository
    2. Put your source in said git repository.
    3. Encrypt the git repository using a decent private key and not some bullshit from verisign which was useless before everyone knew the NSA was spying on them.
    4. Host the repository wherever the fuck you like, you can stick it on a public web page title "NSA Come Get My Source Code" with no password if you want.to as there's no evidence that the NSA can actually break strong encryption.

    5. Download the Encrypted Repository, Decrypt it and do your merges and whatnot. For bonus points air gap the system you download the repository on and the system which holds your decrypted source.

    This will of course be a gigantic pain in the ass and remove nearly all the benefits of having a hosted solution in the first place, but what it will actually do, unlike any other option is actually work. You will have a "hosted" Git Repository which can be accessed by people who have the keys and no one else, at least until the bad guys get your keys.

    Of course all of this is completely unnecessary and misses the entire point of the Prism exercise, but that's really beside the point.

  19. Re:BS fatalism by Anonymous Coward · · Score: 2, Interesting

    You'd think that backdoors and such inserted by compilers etc would be found, but actually Ken Thompson successfully injected a backdoor into Unix early on via the PCC (Portable C Compiler) which allowed him access to ANY Unix system for a number of years. It spread to pretty much every system in existence and was never detected before he finally revealed its existence in order to demonstrate exactly my point.

    According to Ken Thompson it was built but never distributed. http://skeptics.stackexchange.com/questions/6386/was-the-c-compiler-trojan-horse-written-by-ken-thompson-ever-distributed

  20. Re:BS fatalism by Anonymous Coward · · Score: 2, Informative

    I don't think Ken Thompson actually stuck a backdoor into Unix that propagated to other systems, but he described in a classic paper one way how it could be done using a compiler.

    Not to add to the paranoia (if they were *that* interested they'd just break into your house, image your drives, and put everything back together again), some kind of backdoor almost got added to the 2.6 Linux kernel. The beauty of it was the appearance it was a simple coding error (assignment instead of comparison).