{"thread":{"id":"12665","subject":"[Q] Encrypted GIT?","startedAt":"2008-03-13T08:48:53Z","lastAt":"2008-03-13T20:06:13Z","messageCount":17,"participants":["Alexander Gladysh","Miklos Vajna","Johannes Schindelin","Theodore Tso","Jeff King","Thomas Harning","David Brown","Luke Lu"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"71910","messageId":"c6c947f60803130148w7981a3f0r718c0801343c7b78@mail.gmail.com","threadId":"12665","inReplyTo":null,"subject":"[Q] Encrypted GIT?","fromName":"Alexander Gladysh","fromEmail":"agladysh@gmail.com","sentAt":"2008-03-13T08:48:53Z","receivedAt":"2008-03-13T08:48:53Z","isPatch":false,"sender":{"key":"agladysh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38239?v=4"},"body":"Hi, list!\n\nI want to create a private GIT repo (without working copy) on a\nmachine in external data-center. While I do not actually believe that\nit is possible that someone who has physical access to a machine would\nbe interested in peeking into my repo, I'd like to play safe and to\nhave this issue covered.\n\nPlease advise what is the best way to do it. Are there any existing solutions?\n\nThanks,\nAlexander.\n"},{"id":"71919","messageId":"20080313114738.GC2414@genesis.frugalware.org","threadId":"12665","inReplyTo":"c6c947f60803130148w7981a3f0r718c0801343c7b78@mail.gmail.com","subject":"Re: [Q] Encrypted GIT?","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-03-13T11:47:38Z","receivedAt":"2008-03-13T11:47:38Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Thu, Mar 13, 2008 at 11:48:53AM +0300, Alexander Gladysh wrote:\n> I want to create a private GIT repo (without working copy) on a\n> machine in external data-center. While I do not actually believe that\n> it is possible that someone who has physical access to a machine would\n> be interested in peeking into my repo, I'd like to play safe and to\n> have this issue covered.\n> \n> Please advise what is the best way to do it. Are there any existing solutions?\n\ni don't think but you can write a wrapper around git receive/upload-pack\nand use (for example) tar+gpg to keep your repo encrypted on the disc.\n"},{"id":"71920","messageId":"alpine.LSU.1.00.0803131254580.1656@racer.site","threadId":"12665","inReplyTo":"20080313114738.GC2414@genesis.frugalware.org","subject":"Re: [Q] Encrypted GIT?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-13T11:55:11Z","receivedAt":"2008-03-13T11:55:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 13 Mar 2008, Miklos Vajna wrote:\n\n> On Thu, Mar 13, 2008 at 11:48:53AM +0300, Alexander Gladysh wrote:\n> > I want to create a private GIT repo (without working copy) on a \n> > machine in external data-center. While I do not actually believe that \n> > it is possible that someone who has physical access to a machine would \n> > be interested in peeking into my repo, I'd like to play safe and to \n> > have this issue covered.\n> > \n> > Please advise what is the best way to do it. Are there any existing \n> > solutions?\n> \n> i don't think but you can write a wrapper around git receive/upload-pack \n> and use (for example) tar+gpg to keep your repo encrypted on the disc.\n\nThe problem is: you cannot decrypt on the remote side, otherwise you will \nlose all the security.\n\nBut if you do not decrypt on the remote side, you cannot store deltified \nobjects (you lose all the benefits of Git's efficient storage), neither \ncan you update incrementally (you lose all the benefits of Git's efficient \ntransport).\n\nThe latter can be remedied (somewhat) by encrypting each object \nindividually. In that case, .gitattributes can help (you should be able \nto find a mail to that extent, which I sent no more than 2 weeks ago). \nHowever, you must make sure that the encryption is repeatable, i.e. two \ndifferent encryption runs _must_ result in _identical_ output.\n\nIf it is only a single file containing all your secrets, it can also make \nsense to just encrypt it, and track the _encrypted_ file directly \n(without clean/smudge filters).\n\nHth,\nDscho\n"},{"id":"71923","messageId":"20080313121644.GD2414@genesis.frugalware.org","threadId":"12665","inReplyTo":"alpine.LSU.1.00.0803131254580.1656@racer.site","subject":"Re: [Q] Encrypted GIT?","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-03-13T12:16:44Z","receivedAt":"2008-03-13T12:16:44Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Thu, Mar 13, 2008 at 12:55:11PM +0100, Johannes Schindelin wrote:\n> The latter can be remedied (somewhat) by encrypting each object \n> individually. In that case, .gitattributes can help (you should be able \n> to find a mail to that extent, which I sent no more than 2 weeks ago). \n> However, you must make sure that the encryption is repeatable, i.e. two \n> different encryption runs _must_ result in _identical_ output.\n\nafaik, this is not the case for gpg.\n"},{"id":"71929","messageId":"20080313125853.GA12927@mit.edu","threadId":"12665","inReplyTo":"20080313121644.GD2414@genesis.frugalware.org","subject":"Re: [Q] Encrypted GIT?","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-03-13T12:58:54Z","receivedAt":"2008-03-13T12:58:54Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Mar 13, 2008 at 01:16:44PM +0100, Miklos Vajna wrote:\n> On Thu, Mar 13, 2008 at 12:55:11PM +0100, Johannes Schindelin wrote:\n> > The latter can be remedied (somewhat) by encrypting each object \n> > individually. In that case, .gitattributes can help (you should be able \n> > to find a mail to that extent, which I sent no more than 2 weeks ago). \n> > However, you must make sure that the encryption is repeatable, i.e. two \n> > different encryption runs _must_ result in _identical_ output.\n> \n> afaik, this is not the case for gpg.\n\nNo, and you wouldn't want to use gpg because of the overhead it adds\naround an encrypted message. You would need to use a raw encryption\nalgorithm, or one with very minimal wrapping. It's normally at this\npoint that that you'd need to bring in a security expert to ask a\nwhole lot of questions about your exact use scenario, do a formal\nthreat analysis, since there are all sorts of unanswered questions\nabout what kind of key management solution you really need for your\nsituation.\n\nIt's usually not as simple as \"just encrypt it\". How many people need\nto have access to the to the repository? Do you need to revoke access\nto the repository later? Who is allowed to give a new person access\nto the repository? etc., etc., etc.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"71937","messageId":"c6c947f60803130627r45629099g33a0741f319dc99c@mail.gmail.com","threadId":"12665","inReplyTo":"20080313125853.GA12927@mit.edu","subject":"Re: [Q] Encrypted GIT?","fromName":"Alexander Gladysh","fromEmail":"agladysh@gmail.com","sentAt":"2008-03-13T13:27:41Z","receivedAt":"2008-03-13T13:27:41Z","isPatch":false,"sender":{"key":"agladysh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38239?v=4"},"body":"> It's normally at this point that that you'd need to bring in a security expert to ask a\n> whole lot of questions about your exact use scenario, do a formal\n> threat analysis, since there are all sorts of unanswered questions\n> about what kind of key management solution you really need for your\n> situation.\n\nUh. This is for kind of hobbyist noncommercial usage, so there are not\nthat much resources for bringing in security experts. :-)\n\nAlso I do not expect this data to be protected from determined (payed)\nprofessional attack -- a determined professional would probably be\nable to find some weaker spot elsewhere. However I do want such attack\nto cost enough to ward off idle amateurs and bored professionals. :-)\n\n> It's usually not as simple as \"just encrypt it\".\n\n> How many people need to have access to the to the repository?\n\nWell, 2-5, up to ten, I guess. In immediate future -- two persons only. :-)\n\n> Do you need to revoke access to the repository later?\n\nProbably. But restricting remote access should be enough.\n\n> Who is allowed to give a new person access to the repository?\n\nTo keep things simple, me myself only.\n\n> etc., etc., etc.\n\nThank you,\nAlexander.\n"},{"id":"71952","messageId":"alpine.LSU.1.00.0803131620270.1656@racer.site","threadId":"12665","inReplyTo":"20080313125853.GA12927@mit.edu","subject":"Re: [Q] Encrypted GIT?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-13T15:21:44Z","receivedAt":"2008-03-13T15:21:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 13 Mar 2008, Theodore Tso wrote:\n\n> On Thu, Mar 13, 2008 at 01:16:44PM +0100, Miklos Vajna wrote:\n> > On Thu, Mar 13, 2008 at 12:55:11PM +0100, Johannes Schindelin wrote:\n> > > The latter can be remedied (somewhat) by encrypting each object \n> > > individually. In that case, .gitattributes can help (you should be \n> > > able to find a mail to that extent, which I sent no more than 2 \n> > > weeks ago). However, you must make sure that the encryption is \n> > > repeatable, i.e. two different encryption runs _must_ result in \n> > > _identical_ output.\n> > \n> > afaik, this is not the case for gpg.\n> \n> No, and you wouldn't want to use gpg because of the overhead it adds\n> around an encrypted message.\n\nTo the contrary: if your files are small (which they are most likely), you \n_want_ the overhead, in order to make the encryption harder to crack.\n\nAFAICT gpg is a good all-round encryption tool, and reinventing the wheel \njust for encrypting things in a git repository just does not cut it.\n\nCiao,\nDscho\n"},{"id":"71953","messageId":"20080313155322.GA30847@coredump.intra.peff.net","threadId":"12665","inReplyTo":"20080313125853.GA12927@mit.edu","subject":"Re: [Q] Encrypted GIT?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-13T15:53:22Z","receivedAt":"2008-03-13T15:53:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 13, 2008 at 08:58:54AM -0400, Theodore Tso wrote:\n\n> No, and you wouldn't want to use gpg because of the overhead it adds\n> around an encrypted message. You would need to use a raw encryption\n> algorithm, or one with very minimal wrapping. It's normally at this\n\nWell, \"raw encryption algorithm\" is a bit vague here. :)\n\nI thought about this a while ago and come to a few conclusions:\n\n - encrypting before git sees content sucks, because you are either\n sacrificing security (content X always encrypts to Y) or system\n stability (git doesn't know that Y and Y' are really the same thing)\n\n - encrypting at the object level (when we do zlib) sucks, because we\n still want to name contents by their hash, which means the object\n database index contains information about what's in your content.\n There's also some per-object overhead. Plus any system without the\n key can't do deltas.\n\n - encrypting whole packfiles sucks for local storage, since you lose\n the random access property (unless you go with something static like\n an ECB mode, but then you are sacrificing security).\n\n - encrypting whole packfiles is a bit better for transport. The\n key-holding repo does the deltas and just treats the remote repo as\n dumb storage (it can't be smart, since that would involve looking at\n the data). Storage overhead is minimal if packfiles are a reasonable\n size.\n\nSo I think the last makes the most sense, where your local repo is\ntotally unprotected, but you efficiently push git objects to a remote\nuntrusted repo.\n\nYou could probably do something totally external to git using bundles as\nthe primitive. Store an encrypted index on the remote that says \"here\nare the packs I have, and the objects they contain.\" Whenever you push,\npull the index (which is of course more network-intensive than regular\ngit protocol, but not as bad as pulling all the data) and calculate a\nthin-pack bundle yourself. Encrypt the bundle and store remotely.\n\n> point that that you'd need to bring in a security expert to ask a\n> whole lot of questions about your exact use scenario, do a formal\n> threat analysis, since there are all sorts of unanswered questions\n> about what kind of key management solution you really need for your\n> situation.\n\nI don't know if a formal thread analysis is necessary. I think most\npeople are interested in \"if the contents of remote storage X are\nknown, how much do people know about the _contents_ of my repo stored on\nX?\" and they don't care about masking the size, time of updates, etc.\n\nThat's a fairly straightforward application of cryptography. The tricky\npart is doing it in a way that can still leverage some of git's\nefficiencies.\n\n> It's usually not as simple as \"just encrypt it\". How many people need\n> to have access to the to the repository? Do you need to revoke access\n> to the repository later? Who is allowed to give a new person access\n> to the repository? etc., etc., etc.\n\nSure, those are all interesting questions for a complete system. But I\nthink it makes sense to incrementally try the basics first.\n\n-Peff\n"},{"id":"71954","messageId":"20080313160016.GB30847@coredump.intra.peff.net","threadId":"12665","inReplyTo":"alpine.LSU.1.00.0803131620270.1656@racer.site","subject":"Re: [Q] Encrypted GIT?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-13T16:00:16Z","receivedAt":"2008-03-13T16:00:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 13, 2008 at 04:21:44PM +0100, Johannes Schindelin wrote:\n\n> > No, and you wouldn't want to use gpg because of the overhead it adds\n> > around an encrypted message.\n> \n> To the contrary: if your files are small (which they are most likely), you \n> _want_ the overhead, in order to make the encryption harder to crack.\n\nNot necessarily. Using random IVs, random salts, and random padding does\nincrease security. Adding headers to every object that tell which\nalgorithm and parameters were used are nice for interoperability, but\ndon't help with security. Doing per-object asymmetric encryptions (gpg\n--encrypt without --symmetric) is performance insanity.\n\n> AFAICT gpg is a good all-round encryption tool, and reinventing the wheel \n> just for encrypting things in a git repository just does not cut it.\n\nKeep in mind that in the example you posted before, you were not using\n99% of gpg. You were just asking it to do a symmetric CBC cipher using a\npassphrase. So it is overkill for that, but at the same time not\nactually very flexible for doing those sorts of low-level things.\nOpenSSL provides a much better toolkit for that.\n\n-Peff\n"},{"id":"71955","messageId":"20080313160154.GC30847@coredump.intra.peff.net","threadId":"12665","inReplyTo":"20080313155322.GA30847@coredump.intra.peff.net","subject":"Re: [Q] Encrypted GIT?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-13T16:01:54Z","receivedAt":"2008-03-13T16:01:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 13, 2008 at 11:53:22AM -0400, Jeff King wrote:\n\n> You could probably do something totally external to git using bundles as\n> the primitive. Store an encrypted index on the remote that says \"here\n> are the packs I have, and the objects they contain.\" Whenever you push,\n> pull the index (which is of course more network-intensive than regular\n> git protocol, but not as bad as pulling all the data) and calculate a\n> thin-pack bundle yourself. Encrypt the bundle and store remotely.\n\nOh, and a scheme like this generalizes well from \"there is one key\" to\n\"N asymmetric keyholders\".\n\n> I don't know if a formal thread analysis is necessary. I think most\n\nThat should of course be \"threa_t_ analysis\". I of course want to\nformally analyze this thread. ;)\n\n-Peff\n"},{"id":"71956","messageId":"20080313121027.5f51f852@gmail.com","threadId":"12665","inReplyTo":"c6c947f60803130148w7981a3f0r718c0801343c7b78@mail.gmail.com","subject":"Re: [Q] Encrypted GIT?","fromName":"Thomas Harning","fromEmail":"harningt@gmail.com","sentAt":"2008-03-13T16:10:27Z","receivedAt":"2008-03-13T16:10:27Z","isPatch":false,"sender":{"key":"harningt@gmail.com","avatar":"https://gravatar.com/avatar/a79ddd43da8c8f1f899cd75b7b95cc5f3b2ba5643400468988b1a12c86b75d08?d=mp&s=160"},"body":"On Thu, 13 Mar 2008 11:48:53 +0300\n\"Alexander Gladysh\" wrote:\n\n> Hi, list!\n> \n> I want to create a private GIT repo (without working copy) on a\n> machine in external data-center. While I do not actually believe that\n> it is possible that someone who has physical access to a machine would\n> be interested in peeking into my repo, I'd like to play safe and to\n> have this issue covered.\n> \n> Please advise what is the best way to do it. Are there any existing\n> solutions?\n> \nPotential solution to store arbitrary data in a safe manner:\n\nmkdir remote_git_raw remote_git\nsshfs : $PWD/remote_git_raw\nencfs $PWD/remote_git_raw $PWD/remote_git\n\nThis will lock your data in a remote encfs volume. (Uses FUSE)\n\nNot quite sure about the implications on performance... but this will\ncertainly keep your data safe on that remote location.\n"},{"id":"71957","messageId":"20080313161201.GA31653@mit.edu","threadId":"12665","inReplyTo":"20080313155322.GA30847@coredump.intra.peff.net","subject":"Re: [Q] Encrypted GIT?","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-03-13T16:12:01Z","receivedAt":"2008-03-13T16:12:01Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Mar 13, 2008 at 11:53:22AM -0400, Jeff King wrote:\n> - encrypting whole packfiles is a bit better for transport. The\n> key-holding repo does the deltas and just treats the remote repo as\n> dumb storage (it can't be smart, since that would involve looking at\n> the data). Storage overhead is minimal if packfiles are a reasonable\n> size.\n> \n> So I think the last makes the most sense, where your local repo is\n> totally unprotected, but you efficiently push git objects to a remote\n> untrusted repo.\n\nIf the main goal is primarily backup of your repository to an\nuntrusted remote server, yes, that makes perfect sense. \n\nIf you assume multiple trusted developers would actually be\n*operating* on an encrypted repo, the life gets much harder, as you've\npointed out.\n\n> - encrypting before git sees content sucks, because you are either\n> sacrificing security (content X always encrypts to Y) or system\n> stability (git doesn't know that Y and Y' are really the same thing)\n\nIt's not clear that \"content X always encrypts to Y\" is a fatal flaw,\nby the way. Yes, it leaks a bit of information, but in a source code\nmanagement situation, it may not matter. If you do absolutely care,\ntough, it might be that the simplest solution is to store the entire\nrepository and working tree under cryptofs. After all, what's the\npoint of encrypting the local repo if the checked-out working tree is\nunprotected for all to see? :-)\n\n\t\t\t\t\t\t- Ted\n"},{"id":"71958","messageId":"20080313161919.GA2050@coredump.intra.peff.net","threadId":"12665","inReplyTo":"20080313161201.GA31653@mit.edu","subject":"Re: [Q] Encrypted GIT?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-13T16:19:19Z","receivedAt":"2008-03-13T16:19:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 13, 2008 at 12:12:01PM -0400, Theodore Tso wrote:\n\n> If the main goal is primarily backup of your repository to an\n> untrusted remote server, yes, that makes perfect sense. \n> \n> If you assume multiple trusted developers would actually be\n> *operating* on an encrypted repo, the life gets much harder, as you've\n> pointed out.\n\nWell, it depends on the meaning of \"operate\". :) I think you could still\nuse it as a rendezvous point as you would any bare repository. Pushing\nand pulling would have a little larger network overhead, and a lot more\nCPU overhead.\n\nBut yes, that scheme is horrible for a working repo.\n\n> > - encrypting before git sees content sucks, because you are either\n> > sacrificing security (content X always encrypts to Y) or system\n> > stability (git doesn't know that Y and Y' are really the same thing)\n> \n> It's not clear that \"content X always encrypts to Y\" is a fatal flaw,\n> by the way. Yes, it leaks a bit of information, but in a source code\n\nAgreed (I actually recommended in Dscho's original thread \"you can do it\nby eliminating the salt, if you accept the consequences...\").\n\nSo after my saying \"no formal threat analysis is necessary\" you have\nclearly called me on making a bunch of usage assumptions. Oops. :)\n\n> management situation, it may not matter. If you do absolutely care,\n> tough, it might be that the simplest solution is to store the entire\n> repository and working tree under cryptofs. After all, what's the\n> point of encrypting the local repo if the checked-out working tree is\n> unprotected for all to see? :-)\n\nYes. And it doesn't involve any git-specific code at all. :)\n\n-Peff\n"},{"id":"71964","messageId":"20080313174328.GA3783@old.davidb.org","threadId":"12665","inReplyTo":"alpine.LSU.1.00.0803131254580.1656@racer.site","subject":"Re: [Q] Encrypted GIT?","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2008-03-13T17:43:28Z","receivedAt":"2008-03-13T17:43:28Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Thu, Mar 13, 2008 at 12:55:11PM +0100, Johannes Schindelin wrote:\n\n>The latter can be remedied (somewhat) by encrypting each object \n>individually. In that case, .gitattributes can help (you should be able \n>to find a mail to that extent, which I sent no more than 2 weeks ago). \n>However, you must make sure that the encryption is repeatable, i.e. two \n>different encryption runs _must_ result in _identical_ output.\n\nAny decent file encryption program will never have this characteristic.\nIt's normally a bad idea from a security perspective.\n\nDavid\n"},{"id":"71981","messageId":"51ED164C-2269-48B7-B8C9-0E819BFD63EC@vicaya.com","threadId":"12665","inReplyTo":"c6c947f60803130148w7981a3f0r718c0801343c7b78@mail.gmail.com","subject":"Re: [Q] Encrypted GIT?","fromName":"Luke Lu","fromEmail":"git@vicaya.com","sentAt":"2008-03-13T18:36:46Z","receivedAt":"2008-03-13T18:36:46Z","isPatch":false,"sender":{"key":"git@vicaya.com","avatar":null},"body":"\nOn Mar 13, 2008, at 1:48 AM, Alexander Gladysh wrote:\n> Hi, list!\n>\n> I want to create a private GIT repo (without working copy) on a\n> machine in external data-center. While I do not actually believe that\n> it is possible that someone who has physical access to a machine would\n> be interested in peeking into my repo, I'd like to play safe and to\n> have this issue covered.\n>\n> Please advise what is the best way to do it. Are there any existing \n> solutions?\n\nAn obvious and easy solution: use an encrypted partition on the \nremote server and ssh as transport. Last time I checked, git on \nencrypted volumes is plenty fast.\n\n__Luke\n"},{"id":"71987","messageId":"20080313151532.20d72b14@gmail.com","threadId":"12665","inReplyTo":"51ED164C-2269-48B7-B8C9-0E819BFD63EC@vicaya.com","subject":"Re: [Q] Encrypted GIT?","fromName":"Thomas Harning","fromEmail":"harningt@gmail.com","sentAt":"2008-03-13T19:15:32Z","receivedAt":"2008-03-13T19:15:32Z","isPatch":false,"sender":{"key":"harningt@gmail.com","avatar":"https://gravatar.com/avatar/a79ddd43da8c8f1f899cd75b7b95cc5f3b2ba5643400468988b1a12c86b75d08?d=mp&s=160"},"body":"On Thu, 13 Mar 2008 11:36:46 -0700\nLuke Lu wrote:\n\n> An obvious and easy solution: use an encrypted partition on the \n> remote server and ssh as transport. Last time I checked, git on \n> encrypted volumes is plenty fast.\n\nIf its an encrypted partition on the remote server... then its visible\n@ that server.. which I don't think is desired in the situation.\n\nAn encrypted partition is fairly useless on a remote server unless the\nremote server is expected to be physically removed/powered down...\notherwise anything can get into that data while its alive (pending\npermissions, lack-of-holes, etc..)\n\nThe encfs solution makes sure that nothing is ever revealed\nremote-side... all data is prevented from even going over ssh in its\nunencrypted form.\n"},{"id":"71989","messageId":"8F9BA906-777F-4B7D-BA19-D0848D1886B3@vicaya.com","threadId":"12665","inReplyTo":"20080313151532.20d72b14@gmail.com","subject":"Re: [Q] Encrypted GIT?","fromName":"Luke Lu","fromEmail":"git@vicaya.com","sentAt":"2008-03-13T20:06:13Z","receivedAt":"2008-03-13T20:06:13Z","isPatch":false,"sender":{"key":"git@vicaya.com","avatar":null},"body":"\nOn Mar 13, 2008, at 12:15 PM, Thomas Harning wrote:\n\n> On Thu, 13 Mar 2008 11:36:46 -0700\n> Luke Lu wrote:\n>\n>> An obvious and easy solution: use an encrypted partition on the\n>> remote server and ssh as transport. Last time I checked, git on\n>> encrypted volumes is plenty fast.\n>\n> If its an encrypted partition on the remote server... then its visible\n> @ that server.. which I don't think is desired in the situation.\n>\n> An encrypted partition is fairly useless on a remote server unless the\n> remote server is expected to be physically removed/powered down...\n> otherwise anything can get into that data while its alive (pending\n> permissions, lack-of-holes, etc..)\n>\n> The encfs solution makes sure that nothing is ever revealed\n> remote-side... all data is prevented from even going over ssh in its\n> unencrypted form.\n\nYes encfs over an sshfs is probably the safest. But it is intolerably \nslow if you need any kind of random access of data, which git does \nall the time. You can mount the encrypted partition using a key over \nssh per git push or pull to minimize exposure while get the \nperformance you want.\n\n__Luke\n"}]}