Use native keychain bindings if possible

[YorikSar]

Switch from github.com/zalando/go-keyring to github.com/99designs/keyring that uses native bindings on macOS and Windows.

Originally suggested in #7023 (comment)
Fixes #7123

cc @mislav who opened the issue and @reegnz who originally suggested this library.

[YorikSar]

To address the concern raised by @samcoe in #7123 (comment) that user would have to re-authenticate to switch to the new library, I've added the code that detects token stored by old library and uses it to fetch it properly and overwrite it with plain token with the new library. This should address issue on the macOS.
In my testing I found out that old library reads plain token just fine, so both old and new versions will work with both formats. There is no such difference in the way the token is stored on other platforms, so there should be no compatibility issues now.

[YorikSar]

Note that user will still have to authorise access to the keychain item for the new binary after switch and on each subsequent upgrade of gh, but that is an expected behaviour on macOS.

[reegnz]

AFAIK the trusting of the binary for each release only has to be done if you don't sign your binaries. If you're releasing signed binaries, it's enough to trust developer once.

[reegnz]

See docs for how aws-vault does it (they're the guys responsible for the lib you're using): https://github.com/99designs/aws-vault/blob/e22aea12b03e8ce036e9af87dda9303806fa2a9e/README.md#development

Alternatively, on ARM macs if you distribute via homebrew, kegs are automatically codesigned on installation.

[YorikSar]

@reegnz Looks like release binaries are already signed here:

cli/.github/workflows/deployment.yml

Lines 76 to 93 in e0d2fc8

	- name: Configure macOS signing
	if: inputs.environment == 'production'
	env:
	APPLE_DEVELOPER_ID: ${{ vars.APPLE_DEVELOPER_ID }}
	APPLE_APPLICATION_CERT: ${{ secrets.APPLE_APPLICATION_CERT }}
	APPLE_APPLICATION_CERT_PASSWORD: ${{ secrets.APPLE_APPLICATION_CERT_PASSWORD }}
	run: |
	keychain="$RUNNER_TEMP/buildagent.keychain"
	keychain_password="password1"
	security create-keychain -p "$keychain_password" "$keychain"
	security default-keychain -s "$keychain"
	security unlock-keychain -p "$keychain_password" "$keychain"
	base64 -D <<<"$APPLE_APPLICATION_CERT" > "$RUNNER_TEMP/cert.p12"
	security import "$RUNNER_TEMP/cert.p12" -k "$keychain" -P "$APPLE_APPLICATION_CERT_PASSWORD" -T /usr/bin/codesign
	security set-key-partition-list -S "apple-tool:,apple:,codesign:" -s -k "$keychain_password" "$keychain"
	rm "$RUNNER_TEMP/cert.p12"

I'm installing gh via Nix, so that's probably why I'm getting confirmation dialogs from Keychain on each binary update. I'm also fine with it.

[samcoe]

@YorikSar Apologies for letting this PR languish in review limbo for so long. Just wanted to give you a bit of a status update from our end. We are still interested in moving to the 99designs/keyring library, but at the moment the team is focused on bring multi-account support to gh which will cause code changes down to the keyring level. In order to reduce risk and accidentally introduce conflicting code we are going to revisit this work once multi-account work has shipped. Do you have any issue with leaving this PR open for awhile longer? Would you have interest in updating this PR to be compatible with the multi-account work once it has shipped?

[YorikSar]

I use this patch myself since I’ve published it (I’ve overridden it in my dotfiles), so there is little detriment to myself from having this PR hanging. I’m fine with rebasing it when needed since I will have to rebase it anyway when I want to update my gh, which didn’t happen so far.
I honestly don’t see much downside in switching libraries early since the change is rather compatible with both old and new ways.

[samcoe]

I honestly don’t see much downside in switching libraries early since the change is rather compatible with both old and new ways.

This is something I will bring up with the team to see how we feel about getting this in first.

[reegnz]

@samcoe any updates?

[samcoe]

@reegnz No updates on this right now. As we just shipped multi-account this is unblocked now, but with holidays coming up it is unlikely that this work gets prioritized before then.