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.

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.

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.

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.

@reegnz Looks like release binaries are already signed here:

@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?

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.

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.

@samcoe any updates?

@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.

I've updated patch for the latest trunk. Still using it for myself, appears to be working just fine :)

@samcoe or @williammartin Any chance you could approve workflows on this PR so that I can see if any tests are broken on all the systems?

@samcoe Almost a year passed since last message, I keep bumping this patch. Any idea if I could get a review any time soon?

Hey @YorikSar 👋

Apologies for the delay on this one - we've been very busy with other competing priorities the last few months. I bumped this with the team - @williammartin opened 99designs/keyring#138 to investigate our concerns about the maintenance status of that module. We have some other questions about this PR, but it seems like we wanted to investigate this maintenance status first.

Note that @samcoe has left GitHub, so we don't receive notifications when they are @ mentioned.

👋 Hey @YorikSar. I discussed this with the team, and we are going to close this PR for now because of the maintenance concern that we brought up in 99designs/keyring#138 😞 ; we have not heard back from the maintainers on that package.

I'll invite more discussion and suggestions from anyone interested in #7123 🙏