Change link for MacOS Binary Installer to support Apple Silicon

[tongfa]

Which download is failing?

The MacOS Binary Installer

Problem

The MacOS Binary Installer is out of date, for example it does not support Apple Silicon which has been available since November 2020.

Operating system and browser

MacOS

Steps to reproduce

0. On an Apple Silicon machine without Rosetta2 installed.
1. install Tim Harper's MacOS binary installer.
2. After installation, running /usr/local/bin/git produces an error message saying the CPU architecture is not supported.

Other details

After going through this, I started researching what it would take to build the git installer myself for Apple Silicon. In that process, I discovered that @coderforlife has built an installer that supports Apple Silicon, and he has released it through Moravian University's github organization at:
https://github.com/MoravianUniversity/git_osx_installer

I have installed the installer on a Macbook Air that does not have Rosetta2 installed and I was able to clone a repo, use git config ... and push some commits back to github. It passed my smoke test.

My suggestion is to change the link on the downloads page to point to the above repo instead of Tim Harper's.

I'm willing to PR this if there is consensus.

[pedrorijo91]

thanks for reporting the issue @tongfa

indeed, the original repo seems a bit abandoned ATM (PRs without any feedback for 7 months timcharper/git_osx_installer#190)

but the project you mentioned does not seem to be releasing all versions frequently (only 2 releases under https://github.com/MoravianUniversity/git_osx_installer/releases), so I'm not totally comfortable referencing that project yet...

[coderforlife]

I am running that other repo and only recently started. My plan has been to have 2 releases a year: one in August and one in January. This lines up with an update just before each semester of school when we release new setups for our introductory course. This seems like it will be just behind by a few minor versions at each release. I can also release on-demand as it only takes a few minutes (I just posed 2.40). Is there a way I can "watch" for new releases? git doesn't make official releases through GitHub so I can't subscribe there.

[coderforlife]

Note: I (and many at the school) have been using this version on Apple Silicon and Apple Intel and the only known issues are with the GUI due to Tk library issues.

Currently, the installer is unsigned, but over the summer I plan on setting up signing so they can be installed with even fewer issues.

[pedrorijo91]

thanks for jumping in @coderforlife !

on our side we have a scheduled job to check for new releases. see https://github.com/git/git-scm.com/blob/main/lib/tasks/downloads.rake

we also have a scheduled job to check new git versions and import man pages at https://github.com/git/git-scm.com/blob/main/lib/tasks/index.rake

does this help?

@peff / @jnavila any thoughts against using this new project as source for mac versions given this info?

[coderforlife]

I took a cheap way out and used visualping.io on git-scm.com/download to tell me when there is a change in the version number. I don't plan on updating extremely rapidly, but I do guarantee at least twice a year (January and August) with some other random ones in between.

…

On Wed, Mar 29, 2023 at 5:49 AM Pedro Rijo ***@***.***> wrote: thanks for jumping in @coderforlife <https://github.com/coderforlife> ! on our side we have a scheduled job to check for new releases. see https://github.com/git/git-scm.com/blob/main/lib/tasks/downloads.rake we also have a scheduled job to check new git versions and import man pages at https://github.com/git/git-scm.com/blob/main/lib/tasks/index.rake does this help? @peff <https://github.com/peff> / @jnavila <https://github.com/jnavila> any thoughts against using this new project as source for mac versions given this info? — Reply to this email directly, view it on GitHub <#1774 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALXNGD7GGXTNWQGFCPPIADW6QAQ7ANCNFSM6AAAAAAV2TLKDI> . You are receiving this because you were mentioned.Message ID: <git/git-scm .***@***.***>

[peff]

I don't have a strong opinion on this new project source. In a sense, pointing to work that exists is mostly better than not, because people can choose to use it or not.

But I do think we don't have a very coherent view on software supply chain security. Linking from the site indicates at least some endorsement. Not that I think @coderforlife is trying to upload malicious packages or anything, but we could end up in a situation where, say, his laptop gets owned, a trojan version is uploaded to his GitHub repo, and then our link causes it to get distributed widely.

I'm not sure what linking from our site implies to people about the security practices of those binaries. But it feels like we're being put on the hook for those practices. And again, I'm not questioning @coderforlife's practices in particular; this is something the community probably should have figured out long ago and didn't (including for things like the existing links to @timcharper's binaries).

So I dunno. It seems like maybe something that should get input from the broader community on the mailing list. I'll send a note there.

[tongfa]

Could GitHub actions with MacOS runners be used to build in a public manner that gives us more comfort?

I think the MacOS runners are free for public repos, but I'm not 100% sure on that.

[rimrul]

I think the MacOS runners are free for public repos, but I'm not 100% sure on that.

They aren't. But there is a monthly time budget of 2 000 minutes (which would be 200 macOS minutes) included with free accounts and organizations.

[coderforlife]

The package only takes <5 minutes to build, but it sounds like that is 50 out of the 2000 minutes, which may be manageable.

[dscho]

So I dunno. It seems like maybe something that should get input from the broader community on the mailing list. I'll send a note there.

@peff did you ever get around to do that?

Given that most macOS users apparently seem to use the Homebrew variant of Git, it might be a good idea to change the download page on this here site accordingly and stop advertising outdated macOS binaries with known vulnerabilities.

[rimrul]

did you ever get around to do that?

https://lore.kernel.org/git/20230412080019.GA2172825@coredump.intra.peff.net/

[peff]

I have no problem with dropping the existing (outdated) binaries and just pointing people to Homebrew (or the Apple releases). Most of what is on the site is there from inertia. I am not a mac user myself, so I don't have a good sense of what most people would do or want.

[timcharper]

Yeah, git packaging is solved by Apple at this point. Best to use their packaging.

I'm really sorry, I should have been more noisy about my lack of support for the Git OS X installer 🙈. Dropped the ball there. I suck.

I'm using Linux full time for development, and have for several years.

[peff]

@timcharper No problem, and thank you for all the work you put in over the years!

[coderforlife]

I have been releasing a successor to Tim Harper and added support for the M series chippers to the installer. I mostly wanted to add my two cents on why I will keep this installer for my own purposes: - macOS does have a git but you have to install the Xcode command line tools to get it and those are around a 1GB download and almost every time the OS is updated (including minor) they usually need to be reinstalled. - the alternative is brew, but brew requires the Xcode command line tools as well. This seems like major overhead if all you need is git. In many cases it is totally reasonable, but there are situations (like testing something in a VM) where you just need a quick git install.

…

On Tue, Nov 19, 2024 at 7:32 AM Jeff King ***@***.***> wrote: @timcharper <https://github.com/timcharper> No problem, and thank you for all the work you put in over the years! — Reply to this email directly, view it on GitHub <#1774 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALXNGCIAJXCXMJELVS2EOD2BMVTXAVCNFSM6AAAAABSALPH2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBVGU4DIOJSHE> . You are receiving this because you were mentioned.Message ID: <git/git-scm .***@***.***>

[dscho]

I do think we don't have a very coherent view on software supply chain security.

@coderforlife this is still very much an issue. From looking at https://github.com/MoravianUniversity/git_osx_installer/actions, it would appear that none of the releases are built by GitHub workflows (which would be somewhat transparent), but instead they are built behind closed doors.

I want to trust people, but we live in times where Solarigate and the xz backdoor are realities, and therefore we must exact much more diligence than we did in the past.

One option would be to move https://github.com/MoravianUniversity/git_osx_installer to the git org and then resurrect my PR to add automated builds. This would likely need a ton more work now that notarization is essentially required.

Another option would be to lift the work we have done in microsoft/git (which was based on git_osx_installer but basically dropped a ton of no-longer-needed cruft, then added notarization) and put it into a separate repository inside the git org.

With notarization, it is a bit unclear to me what is the proper course of action, IIUC Apple's hands need to be crossed with silver to make that happen.

If the Git project would use project management techniques like a roadmap and milestones, then an effort like this could be put there, but unfortunately, the Git project does not employ those, it's way more fuzzy than that. Based on the reflexive "I don't do Windows" reactions I usually get on the Git mailing list when bringing up Windows-specific issues, I could imagine that any initiative to get any kind of public commitment to provide macOS builds would be likely doomed.

Hmm. I do not want to leave this reply on a downcast note, so here is yet another, crazy option: We could instead advertise the microsoft/git macOS releases. But then, that's not vanilla Git, that fork has quite a few features on top of git/git, which may confuse users. On the other hand it is based on git-for-windows/git which also has a ton of features on top of git/git yet is advertised as the best option for Windows users. So I dunno.

[coderforlife]

I don't think my package should be the official one, in fact, I would love it if it just happened elsewhere.

I had no idea microsoft/git for macOS was a thing! If I had known that, I would have never done my packaging. So maybe just advertising that one is the solution. At least it is consistent with Windows. The website should maintain the other ways to get git that it currently does and in roughly the same order, but sometimes all you want/need is a quick installer with no other massive baggage, so it would be great to have that as an option.

My recommended solutions would be as follows:

• Link to the microsoft/git release for macOS
• Migrate packaging into some automatic action/workflow
• Link to mine (this is starting to get way down there in preference though, especially now that I know about the MS one I may archive my repo)
• Have no link
• Keep the current link to the very outdated one