Alternative to storing Gmail credentials in cleartext?

[outoftime]

I’d love to use gmailctl at work, but I wasn’t able to get security approval because credentials are stored in cleartext on my laptop. Would it be possible to provide an alternative? Two approaches come to mind:

1. Have an option to store credentials in an encrypted secret store, maybe using something like https://github.com/99designs/keyring
2. Don’t store credentials at all; just send the user through an OAuth flow each time I want to sync (as an alternative to, not replacement for, the current workflow)

For what it’s worth, I’m currently using the workaround of generating XML files with gmailctl and importing them manually, but Gmail’s filter import has a longstanding bug where it ignores category assignments, which makes that process particularly error-prone.

Anyway, thanks for the great tool!

[mbrt]

Number 1) sounds like a nice idea!

I'm curious though. The permissions gmailctl requires are very limited (only labels and basic GMail settings, no email forwarding). There's very limited chance of screwing things up from a privacy or security perspective. Is it still a problem for your org?

I won't make promises on this, especially because this would need some refactoring. I like the idea though.

[outoftime]

@mbrt thanks for taking a look at this! I’m guessing probably any cleartext credential storage would be a deal-breaker for our security team, but in particular Gmailctl asks for the gmail.metadata scope, which is documented as:

Read resources metadata including labels, history records, and email message headers, but not the message body or attachments.

So my read on this is that if an attacker managed to get access to my laptop filesystem, the gmailctl config would give them the ability to read the subject lines of everything in my email account.

[mbrt]

Ha, you're right. I wonder if I can get rid of that scope, which doesn't seem necessary at a first glance.

In any case it seems like you won't be able to use it without option 1).

[mbrt]

The metadata scope was a leftover from the past, thanks for checking. Gmailctl is more secure as a result :)

[mbrt]

The current state is that gmailctl requires the gmail.settings.basic and gmail.labels which are quite harmless. True that there's still some risk, but whoever is keeping SSH keys locally is facing way higher risks.

I recognize however that company policies may forbid any kind of credentials saved locally in a machine. The authentication mechanism is in fact easily pluggable today (internally in Google we have a different one), so it should be very easy to fork this and use a keyring backend (https://pkg.go.dev/github.com/zalando/go-keyring seems the better at a first glance).

https://github.com/mbrt/gmailctl/blob/master/cmd/gmailctl/main.go#L9 is the place to plug in the GmailAPIProvider implementation. https://github.com/mbrt/gmailctl/blob/master/cmd/gmailctl/localcred/local_provider.go is the default one. The interface is quite stable.

@outoftime I'm reluctant to add keyring support natively in gmailctl, as it would complicate the initialization quite a bit. It would also add a bunch of new dependencies that I have to vet and monitor (for quality and status). I think a fork would be the best way to move forward.

[outoftime]

Thanks @mbrt. We do fall into this category: “company policies may forbid any kind of credentials saved locally in a machine”.

Unfortunately I don’t know any Go, so even a fairly straightforward patch as you’re describing would include a fair amount of ramp-up cost I’m guessing. I will keep it in mind for a future hack week project though! Or perhaps someone more Go-literate might come across this ticket and find it worth knocking out 🙂