Keyring fails with env backend.

[eliocamp]

I'm trying to download from the CDS service from a server which doesn't have proper keyring support, so it uses environmental variables for storing keys. So far so good- However, it seems that there are subtle differences with the env backend such that some part of the code fails with this error:

#> Error in b_env_list(self, private, service, keyring) : 
  'service' is required for 'env' backend.

I'm posting this basically to remind myself of figuring the error out.

[khufkens]

Hi Elio, Thanks for the follow up. Sorry for the late reply. I'm currently away from my desk so I'll review changes in a week. K

…

On Mon, 9 Dec 2019, 02:05 Elio Campitelli, ***@***.***> wrote: I'm trying to download from the CDS service from a server which doesn't have proper keyring support, so it uses environmental variables for storing keys. So far so good- However, it seems that there are subtle differences with the env backend such that some part of the code fails with this error: #> Error in b_env_list(self, private, service, keyring) : 'service' is required for 'env' backend. I'm posting this basically to remind myself of figuring the error out. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#46>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKKUER5UNVVBT4JMPOWO6TQXWRWRANCNFSM4JYCBISQ> .

[eliocamp]

I'm trying to fix it, but this reminded me that keyring is a bit a complicated dependency because on unix it requires a system dependency (libsodium). This makes ecmwfr installation fail with relatively obtuse errors which some users might not know how to fix but, more importantly, it's a pain in the ass when installing it on a server or any computer for which you don't have root access. Would you be open to setting keyring as a suggested dependency and allowing some admittedly more insecure method of authenticating? The documentation could make it extremely clear that it's not the ideal method, of course.

[khufkens]

Thanks for including explicit environment names into the authentication routines. This should indeed resolve naming issues.

However, I'm reluctant to back track on the keyring requirement. As this makes the "insecure" way the implicit default (because of dependency issues). My experience with clusters or HPC admins is generally that they will implement these kinds of libraries rather quickly (it's their business to support the users). The only issue I see is where computers are administered by departmental IT.

The latter (which should be avoided at all cost) often don't care about their users and just implement "policy". However, very few will even bother to support Linux, and therefore such users would have root access. If you have physical access to a Linux workstation (which isn't encrypted) you can just boot using linux single mode and change the root password anyway.

[khufkens]

Seems like the pull request has thrown a NOTE on the use of :::, unit test also seem to fail. Could you verify what is up with that?

* checking dependencies in R code ... NOTE
There are ::: calls to the package's namespace in its code. A package
  almost never needs to use ::: for its own objects:
  ‘make_key_service’

[eliocamp]

Ups. I see what I did wrong. I'm sending a PR to correct it.