Default keyring not working on Windows
msberends opened this issue · 3 comments
Many thanks for this package!
On Windows, I can't seem to retrieve existing keys, although the keyring
package does seem to find the Windows Credential Manager. The default keyring is not set and the only keyring available has no name:
library(keyring)
default_backend()$keyring_list()
#> keyring num_secrets locked
#> 1 14 FALSE
default_backend()$keyring_default()
#> NULL
The number of 14 is indeed the number of secrets I have under Generic Credentials in the Windows Credential Manager. But list()
cannot find any keys:
default_backend()$list()
#> [1] service username
#> <0 rows> (or 0-length row.names)
Setting keys via the package does work, and then these are also the only elements found with list()
:
default_backend()$set_with_value("testservice", "user123", "pw123")
default_backend()$list()
#> service username
#> 1 testservice user123
default_backend()$keyring_list()
#> keyring num_secrets locked
#> 1 15 FALSE
The number of secrets went from 14 to 15. In other words, my existing secrets are not retrievable.
On StackOverflow, somebody had the exact same problem: https://stackoverflow.com/questions/66959772/r-keyring-package-my-keyring-has-disappeared-maybe-what-happened-to-it-and
I'm on keyring
1.3.0 (no code changes have been made since 1.3.0 aside from the pkgdown website) and Windows 10 behind a corporate proxy.
Windows does not support multiple keyrings, and the keyring package emulates them by using a special key format. If you want to access keys that are set by other software I suggest you use the oskeyring package.
That does not give you a cross platform API, but it lets you access the OS specific raw features.
Ah, I see. Thank you for the quick response. I didn’t know the oskeyring
package and found the keyring
package through Googling.
I noticed that you’re also the developer of the oskeyring
package and that that one is also part of r-lib. From a user’s perspective, I would suggest to combine the two packages, as this makes it all very unclear to end users. If being cross-platform is a big thing and the major difference between the packages, then that could perhaps be an argument in the set()
and get()
methods? Probably configurable with an R option like keyring.crossplatform
or so?
We will not combine the two packages because we want to keep oskeyring dependency-free. Eventually keyring will depend on oskeyring.