Include the new Git Credential Manager

[dscho]

There is a new Git Credential Manager that supports really cool features such as 2-factor-authorization with GitHub as well as with Visual Studio Online.

The best way might be to auto-package the releases.

[dscho]

@linquize please. Use the correct forum for questions: the mailing list. Do not abuse an only remotely related ticket for your questions. Thanks.

[shiftkey]

cc @haacked

[dscho]

Please note that I had some back-channel discussions about this ticket. The preliminary outcome is:

• it probably won't work on Windows XP
• for pre-Windows 8, there is a good chance that the appropriate .NET framework needs to be installed first

Will keep y'all updated.

@shiftkey welcome back to the workforce ;-)

[neico]

Windows XP support isn't that much important as it's support by Microsoft has ended anyway (there are still stubborn people living with a possible insecure OS and those shouldn't really affect a project like this)

Installing a .NET framework is very easy, there's even a good chance that many using git (or github) already have the required package installed due to C#. Installing .NET via Inno Setup

What's more important is that it's still in pre-release state and I'd at least wait for the first public release before going deeper into that, after all this will change how passwords are stored and therefore has security considerations for end users and will most likely invalidate all existing stored passwords.

[linquize]

As of GCM v0.9-beta.2, it's behaviour is more compatible with git-credential-winstore than with git-credential-wincred.
e.g. git-credential-wincred uses git:https://username@host as target name, while GCM / git-credential-winstore use git:https://host.

[dscho]

Windows XP support isn't that much important as it's support by Microsoft has ended anyway (there are still stubborn people living with a possible insecure OS and those shouldn't really affect a project like this)

Please note that your opinion on that matter counts less than the opinion of active contributors who might be stuck with XP for the time being.

So while I appreciate your participation, I have to point out that I always value code over comments :-)

What's more important is that it's still in pre-release state and I'd at least wait for the first public release

Yes, that was the plan. However, before including the credential manager in the end user installer, we should package it as Pacman packages. And we can do that sooner rather than later.

Ther are nice examples to follow, e.g. https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-connect/PKGBUILD

@neico how about giving it a shot?

[neico]

@dscho If you're asking me to provide such a file for MINGW-packages then this is the best I can think of: http://puu.sh/kJsLH/4927ea92d6.txt

I have totally no idea what I'm doing there neither do I like environments like mingw, cygwin and whatnot, therefore my knowledge about them is very limited

[dscho]

To avoid forcing everybody to follow a link that might be broken in the future:

# Maintainer: * <*@*.*>

_realname=git-credential-manager
pkgbase=mingw-w64-${_realname}
pkgname=("${MINGW_PACKAGE_PREFIX}-${_realname}")
pkgver=0.9-beta.2
tag='v0.9-beta.2'
pkgrel=2
pkgdesc="Secure Git credential storage for Windows."
arch=('any')
license=('MIT')
url="https://github.com/Microsoft/Git-Credential-Manager-for-Windows"
source=("https://github.com/Microsoft/Git-Credential-Manager-for-Windows/releases/download/${tag}/git-credential-manager.${tag}.zip")
sha1sums=('<insert sh1sum>')

package() {
  cd "${srcdir}"

  install -d "${pkgdir}${MINGW_PREFIX}/libexec/git-core/"
  install ${_realname}.exe "${pkgdir}${MINGW_PREFIX}/libexec/git-core/"
  install *.dll "${pkgdir}${MINGW_PREFIX}/libexec/git-core/"
}

@neico I thought you might be interested enough in this issue to drive it forward.

The next step would be to install the Git for Windows SDK and then to follow the steps outlined in https://github.com/git-for-windows/git/wiki/Package-management#rebuild-packages, then verify that the package you built actually works.

[dscho]

Probably a good idea to use tasks and call a shell script using cURL to download the installer and launch it with the appropriate parameters.

[whut]

Would not this Microsoft's Git Credential Manager slow fetch/push down? If it is .NET application it will definitely start up slower than plain C. Also, is there anything missing from wincred for regular user? I mean, two-factor authentication to GitHub is nice, but is it popular?

[dscho]

@whut first of all, it will be optional (not decided yet whether it will be opt-in or opt-out).

Second: why don't you just perform some tests and report back the results as to the speed?

Lastly, you already mentioned what is missing from wincred most notably: two-factor authentication. If you do not need it, just don't use it. Due to being much more secure than one-factor authentication, it is pretty much standard, though.

[linquize]

If that PC does not have the required .NET framework version, the credential helper won't run.

[shiftkey]

If that PC does not have the required .NET framework version, the credential helper won't run.

How much this matters depends on how far back support should go:

• Windows 7 ships with .NET 3.5, which may be an issue
• Windows 8/8.1 ships with .NET 4 installed
• Windows 10 ships with .NET 4.6

cc @whoisj for any additional input

[shiftkey]

Scratch that, a fully patched Windows 7 environment should have 4.5.2:

[dscho]

@shiftkey I already discussed this with @whoisj and we have rough ideas how to detect the presence of the appropriate .NET framework. I am only undecided what to do when it was not found yet.

[shiftkey]

@dscho @whoisj 👍

[linquize]

I correct @shiftkey
Win 8 ships .net 4.5, Win 8.1 ships.net 4.5.1

[whoisj]

@linquize I am not sure we should wholly concern ourselves with what technology operating systems ship with, but what technology is readily available and can rightfully be expected to be present. Microsoft pushes updates to the .Net Framework via its Windows Update service, therefore any user who accepts patches from the OS vendor (and this should be all of them) can rightfully assume to have access to the necessary framework.

Despite not officially supporting versions of Windows older than Windows 7, Microsoft has published (and made available via Windows Update) framework version 4.5.2. This is the primary reason behind the requirement decision.

.Net Framework version use the third version numeral to indicate correctness and security patches. Then "yummy" changes included in each patch version are semantic only (language improvements, but not runtime changes). Therefore, any user who has framework 4.5.0, absolutely should have 4.5.2 instead.

As for the performance consequences of create_process on a non-NGEN assembly, I'm fairly certain they are minimal at best. What is the cost of any activity of a network? Especially when many of those calls require the Internet to be part of that network. That, and the fact that a rather largish part of Git's runtime is still authored in shell script which requires an entire ecosystem with interpreter to be invoked, makes any cost incurred by using the CLR on Windows negligible at best in my opinion.

As for "why .NET"? We choose .NET because of the need for Azure Directory Authentication Library (ADAL) support. So far, and as far as I know, the only support for client applications which includes multi-factor authentication support is with Azure's .NET client.

[rimrul]

@whoisj does the Git Credential Manager Setup check the available .NET version and download the framework installer if its requirements aren't met? This is what most Setups for .NET software do. If this is the case, do we really have to care about the .NET framework here? The performance hit should not be a concern, as long as this stays optional. The same applies to support for Windows XP.

[whoisj]

@rimrul it does check for the existence of the required version (or better) of the .NET Framework. It how ever, assumes Win7 support and not Win XP support. I'd need to update the installer to change its behavior when running on Win XP.

[rimrul]

@rimrul it does check for the existence of the required version (or better) of the .NET Framework.

So we could just do a checkbox "Install Git Credential Manager" with some info text about it being a .NET application created and maintained by Microsoft as open source and about it's purpose. This could be an opt in or opt out option (IMHO preferably opt in) that downloads and runs the official Setup for the Credential Manager. As long as it assumes Windows 7 we could just disable that option on Vista/Server 2008(R2?) and older.

[whoisj]

@rimrul sounds good to me. @dscho ?

We'd want a simple way for G4W to take up the latest known good build of the GCM as well (I assume). Shouldn't be too hard, likely submodule or pull during build & package scripts.

[dscho]

Yeah, I think we could easily show / hide the task based on the OS (and maybe a trivial registry check?). i still have to play with InnoSetup's tasks, been too busy with upstreaming patches recently.

And yeah, I'd like to stay up-to-date with the latest known good build, if we can maybe have a link somewhere on http://microsoft.github.io/Git-Credential-Manager-for-Windows/ (via the gh-pages branch) pointing to the installer that gets auto-updated with every new release, that would make it really easy on Git for Windows' side... ;-)

[dscho]

After considerable consideration, I think makes for a better user experience to bundle the Credential Manager and add an opt-out option when the .NET framework (4.5.1 or later) was detected.