Add support for reading pwd from Windows and Linux/GNOME keyrings

[giulianopz]

Use zalando/go-keyring to support targets different from macOS.

Please, note that the PR introduces new flags to properly tell apart the different credentials sources (or no credentials at all).

This should improve user experience IMHO: before passing the domain flag implicitly meant "prompt me for a password" and a failure when retrieving the credentials from a source was handled by just disabling proxy auth.

The README was updated accordingly.

[samuong]

Hi @giulianopz, thanks for sending this! It would be great to be able to support Linux and Windows.

I'm travelling at the moment, so apologies in advance, I might not be able to get back to you very quickly.

Please, note that the PR introduces new flags to properly tell apart the different credentials sources (or no credentials at all).

This should improve user experience IMHO: before passing the domain flag implicitly meant "prompt me for a password" and a failure when retrieving the credentials from a source was handled by just disabling proxy auth.

I see what you mean, it makes sense to have explicit flags for each source of credentials. The way it currently works is the result of evolution, with various credential sources being added over time.

That said, I'm reluctant to change this as the existing behaviour has been documented (e.g. internal confluence pages) and scripted (e.g. in shell scripts and launchd agents). I'm not sure exactly how much would break if we change the command-line flags now, but I know of at least a few examples. Are you ok to leave the changes to the flags out of this PR?

[samuong]

Did you mean to add 2019 and 2020 to this, or did you mean to add 2024 instead?

Also, are you ok to add your name to the AUTHORS file, and are you ok with the Apache 2.0 license?

[giulianopz]

Ok for both things.

With regard to the years , I've just copy-pasted the from keyring_darwin.go. I'm not a license expert but I remember this blog post from Daniel Stenberg who says that you don't really need to mention the year in copyright statements.

But I will update it to 2024, if you want so.

[samuong]

I think will restrict this file to only build on Linux (and keyring_darwin.go will be used on Mac). Will this break on Windows and other OSes? Should we leave it as !darwin?

[giulianopz]

My fault sorry, I've just restricted keyring.go to Windows and Linux, adding an empty keyring interface for other platforms.

[samuong]

I'm not sure this is needed - the filename already ends in _darwin.go, which should restrict the file to darwin builds?

[giulianopz]

You are right: the build constraint in the filename is just enough.

[giulianopz]

Hi @samuong,

I removed the -k flag, but I cannot remove the -i flag since I need the domain (and the username) to be passed also in the case of the keyring used as the credentials source. In fact, I was forced to move both variables to a global scope to be accessed in keyring.go. This is not needed on macOS because you resort to NoMAD to retrieve them.

To remove the -i flag, the code should be refactored a little bit to silently try fetching the password from shell env or keyring, using the shell prompt just as a fallback if the two previous options are not available.

What do you think?