Unify macOS downloads/installers

[codingllama]

What would you like Teleport to do?

Unify Teleport macOS downloads/installers, so that a single installer is available, or at least all options are equivalent in functionality.

A full install of teleport on macOS should deliver:

• tbot, tctl and teleport binaries, signed and notarized
• tsh.app app bundle, signed, notarized and with support for Touch ID
• (optionally) additional support files, such as README, CHANGELOG, examples, etc.

Note the absence of the "naked" tsh binary, which is unable to provide Touch ID support.

What problem does this solve?

Currently Teleport has 3 macOS installers (using v9 as an example):

• "MacOS", aka teleport-v9.3.7-darwin-amd64-bin.tar.gz (a zip with all binaries)
• "MacOS .pkg installer (tsh client only, signed)", aka tsh-9.3.7.pkg (installer for tsh.app)
• "MacOS .pkg installer", aka teleport-9.3.7.pkg (installer for all binaries, equivalent to copying .tar.gz contents to /usr/local/bin)

Unfortunately, starting on v10, the options above have a functionality drift. That is because tsh.app is required for Touch ID support, but the app bundle is only available via the "MacOS .pkg installer (tsh client only, signed)".

If a workaround exists, please include it.

There are many valid ways to address this, so discussion is left to comments.

[codingllama]

FYI @zmb3 @xinding33

A similar issue could apply to Linux, in the sense that we could use the most compatible binary in all packages and get rid of the "regular" and "CentOS 7" packages.

[zmb3]

Yep, that's being worked on right now actually.

[codingllama]

@zmb3 you mean the Linux builds, right? macOS still needs work.

[xinding33]

A single unified macOS installer would be great but I'm not sure an "installer" is the right approach. In my network, most developers on macOS are used to Homebrew. That could be a great way to distribute all Teleport binaries.

Related ticket: https://github.com/gravitational/teleport/issues/4870

[codingllama]

I think we need some downloadable artifact, but agree that it doesn't have to be an installer. We could unify into the .tar.gz, only it would have to deliver "tsh.app" too.

Completely agree on Homebrew, although I think it should deliver the unified package contents too.

[webvictim]

@xinding33 I agree with the assessment, but we've already been down this road in the past.

The problem with Homebrew is that teleport already exists as a Homebrew formula and Homebrew's rules state that they won't replace or override a package in Homebrew-core with a third-party formula (known as a Tap). I also don't believe they'd accept a PR fundamentally changing the nature of the core package that's installed currently.

We could write our own tap, host it and then ask people to brew install gravitational/teleport/tsh or similar in our docs - but 9/10 times people will still just idly run brew search teleport without reading or trying any docs, get the core formula, install it, think everything's it's worked fine and stop looking. IMO further fragmentation would be worse than the status quo here.

As I understand it, this is why we haven't invested any effort in packaging for Homebrew in the past and have instead opted to put a big warning in the docs about using Homebrew, rather than trying to alter the behaviour.

With that said, if we do add tsh.app to the tarball, Homebrew is already packaging that so brew install teleport should start getting that onto people's machines as it does today.

[webvictim]

@codingllama The user experience is no different with tsh.app, right? You still just run tsh login --proxy=teleport.example.com at the command line and everything works exactly the same as it does today?

There are two reasons we had a separate tsh installer historically:

1. Several customers said that they didn't want their users needing to download, extract and install files from a 100MB+ tarball just to get the tsh binary on their company-issued Mac to log into a Teleport cluster
2. prior to Go supporting code embedding in 1.16, we couldn't sign or notarize the teleport binary because it had a ZIP file containing the webassets appended onto the end of it which codesign didn't like.

Even though 2) isn't an issue any more, I'd still encourage us to keep a separate tsh-only installer for people who really do just need tsh and don't want or need the additional overhead of the other binaries,

[codingllama]

@webvictim correct, the usage is the same. In case of a manual install users only have to make sure they are using the binary within "tsh.app/Contents/MacOS/tsh". No objections on my part about providing tsh.app as its own download, for example.

[webvictim]

Having to run /Applications/tsh.app/Contents/MacOS/tsh login… instead seems like a pretty big change to me. Am I getting the wrong end of the stick?

[codingllama]

The current installer links it to /usr/local/bin, so you can run tsh as usual. We need the binary to be in the app shell, though, otherwise we can't do Enclave things.

[gclawes]

With the advent of signed tsh binaries for TOUCHID mfa, It would be very nice to have a path to install these from homebrew, possibly from an officially maintained gravitational/teleport tap.

[webvictim]