-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keyring debugging and error handling, support darwin/arm64
#147
Conversation
This will log details about the available backends, the chosen backend, and other Keyring things.
Same as done in `exec.go`
Currently an error when setting the item misleadingly results in the success message. There's nothing in the Keyring docs about this (`Set` doesn't return an error), but I've found that `nil` is returned when the call is successful, and an error is returned otherwise. Unsure if this is good Golang practice or not.
@jacobbednarz when running this locally, I am currently getting the macOS Keychain backend:
I don't know why this is different from the RC binary you shipped me yesterday. Looking at Keyring docs on this, it uses an ordered list that should pick the OS-native backend first. If it doesn't, there should be a reason emitted via the debug logging added in this PR. Would you mind building a new RC and sending it across? Keen to see if it works with the macOS keychain, or if there are any useful error messages. |
thanks for this, hopefully i'll have a look later today. in the meantime, you can build the releases using i'll send one over too in case it is an amd/arm thing as well. |
Interesting! I built it on an Intel Mac and an M1 Mac, and then ran it on the M1, and the behavior is different! Built on an Intel mac:Build env:
Resulting binary:
Adding a profile:
Uses the macOS keychain, as expected 👍 Built on an M1 mac:Build env:
Resulting binary:
Adding a profile:
No macOS keychain backend available 👎 One obvious other difference is the Golang version. I updated the Intel machine to So perhaps this has to do with the architecture of the build machine? Would need to dig more into Keyring to better understand it, I guess. |
the machine i've been building on the release assets on is the same as your intel tests above.
the issue is already mentioned upstream at 99designs/keyring#126 but i suspect it is wrongly label for OS version but is more about the arch being used. |
@jacobbednarz I have narrowed this down a bit. I was experimenting with what's in
It appears that on an M1 Mac, the |
Also adds `$GOARCH` to the the build paths, since there are two darwin targets now (otherwise one would overwrite the other).
I added some debugging to Keyring's backend consideration code, and all I can get out of the
I tried using Delve to dig in and see what's up, but it doesn't work with "translated" processes (Rosetta, I'm guessing).
There appear to be other ways to debug this, but I'm far enough down the rabbit hole already. I think adding a build target of |
darwin/arm64
i'm happy with that as it would also explain why we are seeing different outcomes here (i'm plain ol' intel, no apple silicone here). |
i've cut 0.0.15 with these changes; do you want to give those a run and make sure they work for ARM after being cross compiled from an intel machine? the updates are automatically pushed into the homebrew tap if that is easier for you too. building on intel for intel use is working here. |
@jacobbednarz well I've got no idea what's going on now. This release is behaving in the opposite manner than the last one:
|
is this from the release binaries? or from source on your local machine? if it is the first, maybe it is more that intel can't cross compile the keychain properly for ARM machines? do you get the same outcome if you build them on an ARM machine for use on ARM? |
I've got no idea what's causing the different behavior here. Might be something weird on my machine, might be something else. I'm not sure if there's anything else to do here.
✅ = macOS Keychain backend works |
To help track down some of the Keyring issues we're seeing, here are a few improvements:
verbose
is enabledadd
, catch an error opening the keyring (same as inexec
)add
, sorta catch an error when creating creds (see the commit comment in 988642d)darwin/arm64
as a build target$GOARCH
to the paths in the build script (otherwise the twodarwin
builds will step on each other)