Changelog

Breaking: shared Google OAuth client deletion — gcalendar, gmail, gtakeout sync has stopped or will stop

We deleted the shared Google OAuth client that the gcalendar,gmail, and gtakeout sources used for authentication.

What breaks

Any connection to one of these three sources that was authorized against the shared client has failed or will fail to refresh its Google access token. Google returns a non-retryable error on refresh. Sync stops when the connection's current Google access token expires — immediately for some connections, and within about an hour for all of them.

This affects every self-hosted install whose stored credentials reference the shared client — which is all installs that connected before user-registered OAuth apps were available. We do not collect install telemetry, so we cannot identify who is affected — this notice is the only channel we have.

Why we did this

We exposed the shared client's secret publicly, so it can no longer be treated as confidential and we retired it. This is remediation of our own mistake, not a security improvement. Each affected source must be reconnected using your own Google OAuth application.

Recovery — gcalendar

1. Register your own Google OAuth client athttps://console.cloud.google.com/apis/credentials. Add<your shenas server URL>/api/auth/source/gcalendar/callbackas an authorized redirect URI. Enablehttps://www.googleapis.com/auth/calendar.readonly. If your Google Calendar source also schedules events onto a shenas-created calendar, addhttps://www.googleapis.com/auth/calendar.app.created as well — Google confines that scope to calendars shenas itself created, so it cannot reach your own calendars. If you are not sure, start with the read scope alone; you can add the second one later if authorization asks for it.

2. If you see Client ID and Client Secretfields in the Google Calendar source's Auth tab, paste your new credentials there and click Authenticate. If you do not see those fields, set SHENAS_GCALENDAR_CLIENT_ID andSHENAS_GCALENDAR_CLIENT_SECRET on your deployment instead.

3. Re-authenticate in the Auth tab (env-var path only). Setting environment variables alone does not rewrite an existing connection's stored credentials — you must re-authorize to mint a new token bound to your own client.

Recovery — gmail and gtakeout

1. Register your own Google OAuth client athttps://console.cloud.google.com/apis/credentials. Add<your shenas server URL>/api/auth/source/<source>/callbackas an authorized redirect URI (replace <source> withgmail or gtakeout). Enable the scope for your source:

   • gmail →https://www.googleapis.com/auth/gmail.readonly
   • gtakeout →https://www.googleapis.com/auth/drive.readonly

2. Set the two environment variables for your source on your shenas deployment:

   Source	Environment variables
   gmail	SHENAS_GMAIL_CLIENT_ID /SHENAS_GMAIL_CLIENT_SECRET
   gtakeout	SHENAS_GTAKEOUT_CLIENT_ID /SHENAS_GTAKEOUT_CLIENT_SECRET

3. Re-authenticate the source. Setting the variables alone does not rewrite an existing connection's stored credentials — you must re-authorize in the Auth tab to mint a new token bound to your own client.

If you leave your registered app in testing mode, Google displays an unverified-app consent screen and limits the connection to accounts on your test-user list. Publish the app (or add your account to the test-user list) to connect normally.

In-product credential-entry fields are planned for gmail andgtakeout in a future release.