Re: [git-users] Can Git do all of this?
Thank you again Konstantin for the detailed clarifications! We will carefully consider how secure our code needs to be and then review your recommendations. Greg On Wednesday, January 9, 2013 3:45:59 PM UTC-8, Konstantin Khomoutov wrote: > On Wed, Jan 09, 2013 at 10:00:07AM -0800, Greg wrote: > > [...] > > WRT 1.b: I am surprised by your comment that private Git repos > purchased > > from Github are not secure... they purport to be authenticated and use > SSL > > connections. Other than the employees at Github, who's prying eyes > would > > be able to peruse the code? > > I did not say they are not secure, I told about different levels of > security of various methods to keep your data offsite. > > I stated that the security of a private repository hosted by a > third-party is questionable. This is because being private only keeps > your repository from being freely accessed by casual public. But that's > all what it means. The repository is physically maintained by that third > party (your hosting provider) whose staff has full access to it. > It's the same situation as with your webmail account: it's not only you > who has access to it but also the organisation who hosts its data. > > So of course there's the question of which level of security you need. > It might be that the level of security just discussed is perfectly > acceptable for your needs. But it might be not. As you asked a rather > comprehensive question I decided to try to show the full picture so you > could make an educated decision. > > As to the level of security for accessing your github private repos from > the outside, it's only as strong as your account's password -- this has > to be understood very well. Even if you do use SSH auth which requires > using public keys (it's beleived to be quite a strong authentication), > to upload these keys on the server, you use regular login to the github > web interface, hence whoever succeeded at guessing your password (or > happened to just obtain it [1]) could upload their own key. Well, and > since github also provides HTTPS transport they wouldn't even need to do > that as they could use your password right away to clone your repo. > > > WRT 3.c: By "secure" I meant a user/password protected, SSL connection > to > > a web-based UI over a private and (hopefully :-) secure Git repo hosted > by > > a Git hosting provider. > > Ah, that's doable of course: any Git hosting provider offering private > repos does provide password-protected and SSL-encrypted access to the > web interface, and in the case of deploying your own hosting (say, on a > rented server or a VPS) you usually put gitweb behind a web server which > is set up to perform whichever sort of authentification/encryption is > desired. > > > So, based upon your thorough reply, it appears that Git will do > everything > > we need it to do (and more). And we will review the options for > off-site > > "secure" repository backup to determine where the best cost/benefit will > be > > for our organization. > > Well, Subversion would also fulfill all your requirements. > It's just... uh... well, okay ;-) > > 1. https://lwn.net/Articles/531726/ > > --
Re: [git-users] Can Git do all of this?
On Wed, Jan 09, 2013 at 10:00:07AM -0800, Greg wrote: [...] > WRT 1.b: I am surprised by your comment that private Git repos purchased > from Github are not secure... they purport to be authenticated and use SSL > connections. Other than the employees at Github, who's prying eyes would > be able to peruse the code? I did not say they are not secure, I told about different levels of security of various methods to keep your data offsite. I stated that the security of a private repository hosted by a third-party is questionable. This is because being private only keeps your repository from being freely accessed by casual public. But that's all what it means. The repository is physically maintained by that third party (your hosting provider) whose staff has full access to it. It's the same situation as with your webmail account: it's not only you who has access to it but also the organisation who hosts its data. So of course there's the question of which level of security you need. It might be that the level of security just discussed is perfectly acceptable for your needs. But it might be not. As you asked a rather comprehensive question I decided to try to show the full picture so you could make an educated decision. As to the level of security for accessing your github private repos from the outside, it's only as strong as your account's password -- this has to be understood very well. Even if you do use SSH auth which requires using public keys (it's beleived to be quite a strong authentication), to upload these keys on the server, you use regular login to the github web interface, hence whoever succeeded at guessing your password (or happened to just obtain it [1]) could upload their own key. Well, and since github also provides HTTPS transport they wouldn't even need to do that as they could use your password right away to clone your repo. > WRT 3.c: By "secure" I meant a user/password protected, SSL connection to > a web-based UI over a private and (hopefully :-) secure Git repo hosted by > a Git hosting provider. Ah, that's doable of course: any Git hosting provider offering private repos does provide password-protected and SSL-encrypted access to the web interface, and in the case of deploying your own hosting (say, on a rented server or a VPS) you usually put gitweb behind a web server which is set up to perform whichever sort of authentification/encryption is desired. > So, based upon your thorough reply, it appears that Git will do everything > we need it to do (and more). And we will review the options for off-site > "secure" repository backup to determine where the best cost/benefit will be > for our organization. Well, Subversion would also fulfill all your requirements. It's just... uh... well, okay ;-) 1. https://lwn.net/Articles/531726/ --
Re: [git-users] Can Git do all of this?
Thank you very, very much Konstantin for the detailed reply... you answered
all of my questions and also included lots of great supplemental
information.
I concur with your comments about the "marketing speak" and the "cloud,"
and I apologize for not phrasing my questions in a more clear and concise
way.
WRT 1.a: Voluntary pushes by devs to synchronize repos based upon agreed
policy is the model I was attempting to describe (obviously poorly, sorry).
WRT 1.b: I am surprised by your comment that private Git repos purchased
from Github are not secure... they purport to be authenticated and use SSL
connections. Other than the employees at Github, who's prying eyes would
be able to peruse the code?
WRT 3.c: By "secure" I meant a user/password protected, SSL connection to
a web-based UI over a private and (hopefully :-) secure Git repo hosted by
a Git hosting provider.
So, based upon your thorough reply, it appears that Git will do everything
we need it to do (and more). And we will review the options for off-site
"secure" repository backup to determine where the best cost/benefit will be
for our organization.
Thank you again for your counsel,
Greg
On Wednesday, January 9, 2013 9:09:28 AM UTC-8, Konstantin Khomoutov wrote:
> On Tue, 8 Jan 2013 15:51:18 -0800 (PST)
> Greg > wrote:
>
> [...]
> > 1. A general architecture as follows:
> > a. Distributed repository model where local "branches" are
> > permitted and all repositories are kept in sync with "reasonable"
> > latency (I believe Git does this; please correct me if I'm wrong)
>
> This sounds like some kind of marketing speak so it's not quite clear
> what's being asked here. If you ask about some sort of *automated*
> synchronizing of developers' repos to a central ("master", "blessed",
> "reference" or whatever else you'd like to call it) repo then no, Git
> can't do it by itself. If what's hidden behind this phrase is whether
> developers are able to periodically push their work somewhere then
> the answer is yes (obviously). But such pushes are only done
> voluntarily unless you deploy some sort of crazy scheme which would use
> a scheduler and some custom code to automate such a task. In general,
> when working with Git, a policy regarding code organisation and
> workflow is developed and agreed upon, then everyone follows it.
>
> > b. Capable of synchronization with a secure repository in the
> > cloud as redundant off-site storage (either free or subscription)
>
> Another case of marketing speak: the word "cloud" is so tired everyone
> has its own set of meanings for it. To provide an off-site emergency
> storage for your Git repo(s), you have several possibilities:
> * Buy private hosting from a Git hosting provider (such as bitbucket,
> github etc) -- this is really a no-brainer setup.
> * Buy a VPS or a dedicated server (running a Linux-based OS) and host
> your backup repos on it -- this is slighty harder to set up, but
> only slightly.
> These two possibilities suffer from the same syndrome: they won't
> protect your code from a prying eye and are unable to keep your trade
> secret, if any, so there's another one:
> * Buy/rent some storage (be it a server or a dropbox-like service)
> and periodically upload there encrypted backups of your repos
> made by the `git bundle` tool (which is an integral part of Git).
> This is not bandwidth-effective but should in exchange be reasonably
> safe security-wise.
>
> > 2. Provide a seamless developer SCM experience from within the
> > following development environments:
> > a. Microsoft Visual Studio (HTML/JavaScript/C# development for
> > PC/Windows and Windows Phone)
>
> No native (i.e. "made by Microsoft") tool, but Git Extensions [1] claims
> to have support for the whole range of contemporary MS IDEs.
> I have only used Git Extensions in the standalone mode, and it rocks.
>
> > b. Eclipse (HTML/JavaScript/Java development for Android devices)
>
> Yes, via its EGIT plugin [2]. I, again, have no personal experience
> with it, but it's reported to work OK.
>
> > c. Apple Xcode (HTML/JavaScript/Objective-C development for
> > Mac/OS X, iPad, iPod, and iPhone)
>
> XCode has built-in support for Git -- at least version 4.2 running on
> Mac OS X 10.6.8 (I've had a chance to tinker with it just today).
>
> > 3. Provide full-featured user interfaces for the following
> > platforms (particularly where IDE integration in #2 above is not
> > available):
>
> Not sure what does "full-featured" really means here.
>
> On all platforms Git is ported to (namely, everything POSIX, including
> Mac OS X, and Windows), it comes with its full set of command-line
> utilities and its two standard GUI tools (`git gui` for arranging
> commits and working with remote repos and `gitk` which is a graphical
> history browser). Git's command line tools are able to work with a
> wide set of diffing G
Re: [git-users] Can Git do all of this?
On Tue, 8 Jan 2013 15:51:18 -0800 (PST)
Greg wrote:
[...]
> 1. A general architecture as follows:
> a. Distributed repository model where local "branches" are
> pemitted and all repositories are kept in sync with "reasonable"
> latency (I believe Git does this; please correct me if I'm wrong)
This sounds like some kind of marketing speak so it's not quite clear
what's being asked here. If you ask about some sort of *automated*
synchronizing of developers' repos to a central ("master", "blessed",
"reference" or whatever else you'd like to call it) repo then no, Git
can't do it by itself. If what's hidden behind this phrase is whether
developers are able to periodically push their work somewhere then
the answer is yes (obviously). But such pushes are only done
voluntarily unless you deploy some sort of crazy scheme which would use
a scheduler and some custom code to automate such a task. In general,
when working with Git, a policy regarding code organisation and
workflow is developed and agreed upon, then everyone follows it.
> b. Capable of synchronization with a secure repository in the
> cloud as redundant off-site storage (either free or subscription)
Another case of marketing speak: the word "cloud" is so tired everyone
has its own set of meanings for it. To provide an off-site emergency
storage for your Git repo(s), you have several possibilities:
* Buy private hosting from a Git hosting provider (such as bitbucket,
github etc) -- this is really a no-brainer setup.
* Buy a VPS or a dedicated server (running a Linux-based OS) and host
your backup repos on it -- this is slighty harder to set up, but
only slightly.
These two possibilities suffer from the same syndrome: they won't
protect your code from a prying eye and are unable to keep your trade
secret, if any, so there's another one:
* Buy/rent some storage (be it a server or a dropbox-like service)
and periodically upload there encrypted backups of your repos
made by the `git bundle` tool (which is an integral part of Git).
This is not bandwidth-effective but should in exchange be reasonably
safe security-wise.
> 2. Provide a seamless developer SCM experience from within the
> following development environments:
> a. Microsoft Visual Studio (HTML/JavaScript/C# development for
> PC/Windows and Windows Phone)
No native (i.e. "made by Microsoft") tool, but Git Extensions [1] claims
to have support for the whole range of contemporary MS IDEs.
I have only used Git Extensions in the standalone mode, and it rocks.
> b. Eclipse (HTML/JavaScript/Java development for Android devices)
Yes, via its EGIT plugin [2]. I, again, have no personal experience
with it, but it's reported to work OK.
> c. Apple Xcode (HTML/JavaScript/Objective-C development for
> Mac/OS X, iPad, iPod, and iPhone)
XCode has built-in support for Git -- at least version 4.2 running on
Mac OS X 10.6.8 (I've had a chance to tinker with it just today).
> 3. Provide full-featured user interfaces for the following
> platforms (particularly where IDE integration in #1 above is not
> available):
Not sure what does "full-featured" really means here.
On all platforms Git is ported to (namely, everything POSIX, including
Mac OS X, and Windows), it comes with its full set of command-line
utilities and its two standard GUI tools (`git gui` for arranging
commits and working with remote repos and `gitk` which is a graphical
history browser). Git's command line tools are able to work with a
wide set of diffing GUI software (such as vimdiff, meld, KDiff etc) and
could be set up for custom front-ends as well.
> a. PC with Microsoft Windows 7 (GUI and command shell,
> preferrably PowerShell)
Works OK in cmd.exe. Works almost OK in the port of the GNU bash shell
(which is packaged with Git for Windows) -- no support for non-ASCII
characters. Don't know for PowerShell but heard it works there OK as
well.
Several technical issues exist:
* There's no 64-bit binaries of Git for Windows so you won't be able
to handle files larger than some 2GiB.
* Pathnames longer than 260 or so characters are not supported
(i.e. Git does not internally uses those hacks with "\\.\" pathname
prefixes and relies on "more standard" APIs).
* Certain obscure bugs persist (though you're unlikely to encounter
them).
> b. Mac with OS X
It's just a POSIX system, so nothing special about it.
There were certain issues with funky approach to handling Unicode in
HFS but they've been fixed in 1.8 or even earlier.
> c. Browser-based web interface for the secure repository in the
> cloud (for use on machines/devices where Git is not installed)
I hear this stupid word again...
There are three sorts of web front-ends to browse Git's history:
* Proprietary web front-ends provided by the Git hosting providers.
* A de-facto standard free tool called gitweb -- it usually comes
packaged with any sensible OS which has Git packaged, so if you're
about to depl
