r-lib / keyring

:closed_lock_with_key: Access the system credential store from R
https://keyring.r-lib.org/
Other
196 stars 28 forks source link

Default keyring not working on Windows #121

Open msberends opened 2 years ago

msberends commented 2 years ago

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.

gaborcsardi commented 2 years ago

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.

msberends commented 2 years ago

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?

gaborcsardi commented 2 years ago

We will not combine the two packages because we want to keep oskeyring dependency-free. Eventually keyring will depend on oskeyring.