search

gravitational / teleport

The easiest, and most secure way to access and protect all of your infrastructure.
https://goteleport.com
GNU Affero General Public License v3.0
16.95k stars 1.7k forks source link

Unify macOS downloads/installers #14006

Open codingllama opened 2 years ago

codingllama commented 2 years ago

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:

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):

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 commented 2 years ago

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 commented 2 years ago

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

codingllama commented 2 years ago

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

xinding33 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 2 months ago

image