-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Port GCM Core to Linux #135
Comments
A few of these questions have answers, but I've lacked time for far to get around to doing it.
|
libsecret (or formally, the Freedesktop Secret Service API) is probably the best choice, especially since KeepassXC started supporting it as a credential provider in 2.5.0: https://keepassxc.org/blog/2019-10-26-2.5.0-released/ However, there is still a lack of support in KDE, as KWallet has zero compatibility with libsecret, and the newer KSecretService still seems to be incomplete. Other desktop environment likely have similar problems. Pure CLI should work, gnome-keyring and secret-tool don't depend on a graphical desktop environment. |
A partner team at Microsoft also attempted to integrate secret storage via libsecret, but hit issues (at least on Ubuntu Server) with how DBus was configured - it would throw all sorts of errors when trying to call libsecret APIs without X11 configured and running. Storage mechanisms for other popular distros should also be on the backlog. |
As for point no. 3: Microsoft is maintaining their own Linux package repositories, why not put it there? It would also be great if you could work with distributions to get GCM into official package repositories. At least Debian and Fedora should cover a large number of derived distributions. |
|
As a (fairly experienced) Ubuntu user, from the standpoint of installation and updates I would be happy with a Snap rather than |
I'm not a fan of alternative package managers such as Snap or Flatpack, so my view is a bit biased here. I do acknowledge that they are useful in cases where large applications with lots of internal dependencies are packaged, but in this case, I see very little benefit. All dependencies have to be resolved in some way, and by choosing a particular library version, you're risking incompatibilities with the rest of each system. By linking against an OS package instead, you're making sure you're using a version that is supported by the OS distributor. This is particularly true for anything that has strong ties to the system, and GCM Core is a prime example of that: git, ssh-agent, secret-agent are all OS-provided frameworks, so by packaging a different client library than the OS, you're risking breakage on a wide range of systems. |
I also am not a fan of snap and neither is my preferred linux flavor: https://www.zdnet.com/article/linux-mint-dumps-ubuntu-snap/ (Thank you Tucker for pointing that out). |
Update!We have a pre-release of a GCM Core that supports Linux! 🥳 https://github.com/microsoft/Git-Credential-Manager-Core/releases/tag/v2.0.246-beta At the moment we provide a Debian package, and a tarball of the If you wish to build from source you can clone and run After installing the package, or building from source, you’ll want to link the binary to somewhere on your [credential]
helper = <path to git-credential-manager-core>
[credential "https://dev.azure.com"] #required only for Azure DevOps users
useHttpPath = true Again, we plan to add these steps to a post install action in the .deb package. Due to the nature of Linux distributions' open and varied nature, we've had to offer a collection of credential storage options, each with different limitations, advantages, and setup. We've outlined the different options here: https://aka.ms/gcmcore-linuxcredstores. We hope to improve on this in the future, especially where it comes to helping users select and configure an option. Please let us know what you think, and raise an issue for any bugs you encounter. |
How are you building the Debian package? |
I'm still pretty new to building packages on/for Debian systems. Is the goal of an ITP to make known that we are building a particular package and that's it. Or is the goal to go further and say, we intend to submit this package to be a part of the Debian packages? |
@derrickstolee Thanks. I guess this means that the resulting package includes the .NET Core runtime and all dependencies? @kyle-rader An ITP (=Intent To Package) is basically saying that the person submitting the ITP will prepare all the necessary work for the project to be included with the Debian project as a supported software package. There are a lot of hurdles to go through, and the tooling is not all that easy to use. But if the upstream project provides a straight-forward way to build a project, then it's often much less work. Note that I'm not neither affiliated with Microsoft, nor am I a Debian developer. But I've maintained a few Debian packages and know my way around a bit. |
My only concern is that we have a lot of non-trivial and only internally runnable steps to go through to produce what will be the final product as a signed |
@onitake re: .NET Core Runtime - yes. If you take a look at the build.sh you'll see we publish this as a single executable but it does contain the whole runtime. The size of that executable IIRC is around 80-100 MB. We might change this to deploy all the Dlls into usr/lib/ and create a symlink in /usr/bin. We also have the option of publishing with trimming to strip out Dlls never used which can help reduce the payload size quite a lot. (I've seen other tools go from 80MB to 18MB) |
I don't think that we intend to incorporate this into Debian by default, but do intend for it to be easy to install using |
That's what my first thought was. If a package is required to be built and included by a Debian maintainer, then it simply won't be possible for them to include a signed version of GCM (unless they just pull the one we ship). |
I don't think we want GCM Core to be bundled with Debian, at least not right now. Having it on the https://packages.microsoft.com feed requires it be signed by a Microsoft key, so we won't be able to do that except inside of a MS build process.
If we're not trimming, we probably should. I don't think we make (much) use of reflection, so it should be safe. |
Can you clarify what you mean with "signing"? |
By signing we mean the .deb package, yes. On Mac and Windows we sign both the binaries and installer/packages with Apple's signing service (with the MS team account) and the Microsoft Authenticode certificate, respectively, in our release pipelines. On macOS, binaries must be signed to enable Keychain functionality without constant confirmation prompts. From a policy level, all 'production' released Microsoft software or packages must be signed as both internal and external customers often take Microsoft software to be trustworthy in their own build systems etc, and must verify the bits are what they expect them to be on disk. Since GCM Core on Linux is still in the very early stages of release, and we will be making frequent iterations, I don't think it would be appropriate yet to have it bundled with distros or hosted by external projects. Also I think ITP requires the package be stable:
Once the project is more stable, especially on Linux (a new platform for us here 😁 ) this is probably something we can look at. |
Technically, GCM Core should be stable - it's at at version 2.0.x after all. 😉 I did a quick skim of what's needed - and I think the bigger problem is something else: There is currently no .NET Core in Debian. We have Mono and a lot of .NET libraries, but I'm not even sure if building .NET Core projects with Mono is even possible at the moment. |
And then there will be .NET 5 soon - so let's leave this discussion open for now. I think putting signed |
Thanks for adding to Microsoft Ubuntu repo https://packages.microsoft.com/ubuntu/21.04/prod repo (https://github.com/microsoft/Git-Credential-Manager-Core/blob/main/README.md#ubuntu-2104-hirsute) Any chance of inclusion in the Microsoft Debian repo https://packages.microsoft.com/debian/10/prod ? https://docs.microsoft.com/en-us/dotnet/core/install/linux-debian#debian-10- |
I'd like to point out that Git has very basic credential manager that internally uses libsecret. You can find the source here. On Ubuntu/Debian it is not installed by default, it needs to be compiled with make before it is used. It works as advertised, noting fancy, for GitHub I need to enter personal access token as password. Would it be possible to make this credential manager compatible with that one, i.e. credential already stored by the old one should be readable by this new one (and maybe the other way around)? |
If you are using GitHub, I think you are better off with https://cli.github.com/manual/gh_auth_login which sets up [credential "https://github.com"]
helper =
helper = !/usr/bin/gh auth git-credential That currently stores a plaintext OAuth token in |
Closing this issue as GCM Core can now run on Linux distributions. For further issues/bugs, or support for more distributions please open new issues. Thanks! 🎉 |
Opened #447 "Publish packages to packages.microsoft.com/debian" |
We hope to make a Linux version of GCM Core. Since the tool is built on .NET Core, most of our logic will carry over automatically. There are a few platform-specific bits to handle, though:
.deb
package so users can install viaapt-get
the same way macOS users can install viabrew
.These are all important, technically challenging items.
Update!
We have a pre-release of a GCM Core that supports Linux! 🥳 See this comment below for more information.
The text was updated successfully, but these errors were encountered: