-
Notifications
You must be signed in to change notification settings - Fork 101
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
Keychain backend not working on darwin/arm64 (aka M1) Macs #139
Comments
After doing some digging it appears other tools that use the keyring library are experiencing similar issues. The fix appears to be cross-compiling darwin/arm64 on darwin/amd64: |
Hi @schisamo thanks for checking out Granted and reporting this issue. I appreciate the research and links you've shared. I've just tested this locally on an M1 Macbook Air, running 12.3.1 Monterey.
It seems like I'm unable to reproduce the error? I'll do some more digging and get back to you as soon as possible. Cheers |
I'm having the same issue. I received the same error as @schisamo when running as usual and when specifying the
This is on a 14" MBP with M1 Pro running macOS Monterey 12.3.1, with granted installed through homebrew. |
@jordiup I think the issue is in the Makefile here: |
I am also getting the same issue as @schisamo. The default install via homebrew went to a cred file. |
I've cloned the repo and compiled with MacBook Pro (13-inch, M1, 2020) running macOS 12.4 |
The above is correct, clone the repository and go through the Makefile. Build the binaries locally and make them available in your system path, works perfect! Thank You. |
Same issue on MacBook Pro (16-inch, M1, 2021) running macOS 12.4. My steps to compile:
Also |
Thankyou @holly-evans @rK-delphix @dserodio @antonosmond for your help on this! I’ll update our documentation with this issue and workaround and also take a look at our build pipelines which create the MacOS binary. My current suspicion is that this may be due to how we are notarizing the binary, as building a binary locally doesn’t require notarization. |
@holly-evans @rK-delphix @dserodio @antonosmond I've included our release pipelines for Granted v0.2.0 with the following environment variables based on 99designs/aws-vault#760
If you could try running |
It's working for me on an M1
|
Reinstalled via Homebrew and it's working as expected, thanks! Note: I found a bit strange that the Keychain prompt asks "[…] to use your confidential information stored in "" in your keychain", since the Keychain entry is called |
Closing this as it looks like it has been resolved, thanks everyone |
Sorry to revive this @JoshuaWilkes , but... could it be there is a regression?
|
@citosid, same issue. After upgrading to v0.24.0, assume fails with:
I'm not on M1, though. Just an old Intel MacBook Pro. — Might be worth opening a new issue 🤔 UPDATE:
|
@uvw, I have an intel mac, so is the same as you. But since I was not sure it was a regression of some kind I didn't want to write a new issue. But thank you for doing it! Now we just have to wait... |
Describe the bug
Even though I am using macOS, I noticed
assume
would not save SSO tokens intokeychain
which from the documentation appeared to be the default.To Reproduce
I forced
assume
to use thekeychain
keyring backend via config:Next I ran an
assume
with the--verbose
flag and observed thekeychain
was not available as a backend:Expected behavior
As I am on macOS, I expect
assume
to save the SSO token in thekeychain
keyring backend by default.Actual behavior
assume
falls back to thefile
keyring backend which works BUT forces me to enter a passphrase each time:Version Info
The text was updated successfully, but these errors were encountered: