SDKConfig doesn't work past gcloud v179.0.0

[daenney]

In newer versions of gcloud SDK the credentials are no longer stored in a flat file, but in a sqlite database. However, (New)SDKConfig is completely unaware of this change and breaks on newer versions of the gcloud SDK even though you've managed to correctly gcloud auth login and the account is properly shown as active.

The current approach appears to be to downgrade to 179.0.0, execute gcloud config set auth/use_sqlite_store false and then do a gcloud auth login again. Now upgrading past that version appears to work and maintain the setting.

Though this makes it work currently this is not a viable long-term solution and not something I can implement as part of a CLI tool (or continuously direct people to do). SDKConfig should be able to handle the new sqlite based storage format that gcloud SDK has started to use.

[ojarjur]

Looking at the current interface for the gcloud tool, it looks like the code should be changed to invoke gcloud config config-helper --format json to get the credentials.

That only gives the access token and expiry, so it seems like the SDKConfig should be changed to implement a custom token source that invokes that gcloud command to get the access token/expiry, and then pass that token source in when constructing the transport for the HTTP client.

The Scopes method would probably have to go away, since gcloud does not seem to expose any information about what scopes are included in the token.

This would follow a similar pattern used for getting tokens from a metadata server, so I think there is a reasonable precedent for it.

[daenney]

That seems possible, shouldn't be too hard to implement either. I'm a bit reluctant though given this:

$ gcloud config config-helper --help

NAME
    gcloud config config-helper - a helper for providing auth and config data
        to external tools
DESCRIPTION
    A helper for providing auth and config data to external tools.

    Tools can call out to this command to get gcloud's current auth and
    configuration context when needed. This is appropriate when external tools
    want to operate within the context of the user's current gcloud session.
[..]
NOTES
    This command is an internal implementation detail and may change or
    disappear without notice.

At least according to the help of this command, we can't actually trust its output won't change or for it to stick around, even though the description seems to suggest otherwise.

Given that apparently anything can change/disappear and without notice, should SDKConfig even be supported if gcloud won't to provide a stable interface for accessing it?

[ojarjur]

@daenney I think whether or not this support should be included at all is a valid question.

Until that is decided, however, I think changing to use gcloud config config-helper is a clear improvement over the current state.

[rohansingh]

Agree with @ojarjur here that #301 is a clear improvement over the current state, where SDKConfig is pretty much just broken.

I'd argue for either fixing it, or dropping the functionality altogether. The current state is subpar— I just spent time implementing functionality around SDKConfig only to find that it has been broken for a while.

@daenney Were you ever able to find a long-term fix?

[daenney]

I'm afraid not. I got away from the problem in that I never ended up completing the tool I was working on. I got stuck on this and then other priorities took over.

Not having a stable interface to the credentials is really annoying though from a developer point of view. I either have to implement a full oauth2 flow in my CLI app and put the users through it, or use SDKConfig and hope the teams at Google won't change it up again anytime soon.

I'm kinda torn here, I prefer not having to do the work of implementing the oauth2 flow, and I like the idea of having an updated SDKConfig, but I dread the day a team at Google decides to change this again b/c then we're right back where we started. It feels better to just drop SDKConfig in my opinion instead of having it be this moving target, and especially one that's not getting the maintenance it needs.

Looking at #301 and it's associated https://go-review.googlesource.com/c/oauth2/+/121939#message-a9faec17665d2fab7e31a69d24a5295c05f1dc0e it seems nobody from the Go team ended up reviewing this either, so it's still stuck in limbo.

[rohansingh]

Yeah, the status quo is a bit of a bummer. I'm working an internal CLI, and it would be nice to not force a user to login again if they've already run gcloud auth login.

That said, I just found this project and perhaps it's an option:
https://github.com/google/oauth2l

Apparently it implements the oauth2 flow.

[daenney]

Nice find! That seems like a better way to go about it indeed. I suppose once that stabilizes it might make sense to have SDKConfig leverage that instead.

[seankhliao]

https://pkg.go.dev/cloud.google.com/go/auth@v0.16.0

[ojarjur]

@seankhliao can you please explain what you meant by the link to https://pkg.go.dev/cloud.google.com/go/auth@v0.16.0 ?

I can't tell how that's relevant to this bug.

I also don't understand how the not planned tag applies to this.

This issue isn't a feature request, it's reporting an existing part of the library is broken.

Removing that broken piece would be a valid fix for this issue, but simply leaving the broken code in there as-is does not seem like a good resolution. At the very least, I would want to keep the issue open so that everyone who hits the bug at least sees that it's a known issue.