-
Notifications
You must be signed in to change notification settings - Fork 86
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
Comparison with 99designs/keyring #64
Comments
|
At least for Linux, this is untrue, try What other problems have you experienced aside from failing to enable |
I haven't had any other problem. I use |
We switched to 99designs/keyring but now are switching back to this package |
On macOS, 99designs/keyring uses CGO (via https://github.com/99designs/go-keychain) to access the keychain while zalando/go-keyring shells out to the The disadvantage of zalando/go-keyring's approach are:
Because 99designs/keyring accesses the keychain directly through CGO instead of shelling out, an "Always Allow" grant only gives access to the specific binary using 99designs/keyring. So 99designs/keyring's approach is more secure, assuming the binary has a smaller attack surface area than |
@tekumara we agree with your summary. I think we are happy to get PRs that advance MacOS integration. As we (maintainers) are no Mac users we rely on PR authors in this case. If you can build a PR that does not change the interface and build only with CGO for MacOS, then I think there is nothing that would stop the PR from being merged. |
Hey there! It appears to me that 99designs/keyring supports more backends compared to go-keyring. Other than that, are there any differences between both of them? Looks like 99designs/keyring also supports KWallet as well custom keyring names while go-keyring has open PRs for a while now.
The text was updated successfully, but these errors were encountered: