Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop exposing real account tokens in plaintext #7533

Merged
merged 1 commit into from Jul 7, 2023

Conversation

jeffwidman
Copy link
Member

After I rotated the Gemfury/Hex.PM tokens, these unit tests started failing, which made us realize we've been exposing the account tokens in the clear.

Historically this was fine because:

  1. These private registries were used solely for test accounts, it didn't matter if they were compromised.
  2. Dependabot was a startup manned by a small team, so everyone knew these registries were publicly exposed and shouldn't be re-used for anything private.

However, 2️⃣ is no longer true... now that :dependabot: is part of GitHub, the team has grown so there's a risk that someone could upload something that should stay private to these orgs.

Unfortunately, neither Gemfury nor Hex.PM support limiting the scope of a token to particular package(s). So while they're read-only, they still expose everything on the account.

After discussing further, we decided that we no longer want to expose these tokens, so flipping them to use Env Vars.

Furthermore, these tests exercise private registry auth code in dependabot-core, but we don't use that in production at GitHub. Instead, we use a private credential
proxy
.

Long term, we've batted around the idea of open sourcing that, in which case we'd remove all the private registry auth code from dependabot-core.

So this PR removes the plain text tokens (and I will also delete them from the registry side to ensure they aren't usable). And wires up env var support so that if we do need to run these tests, we can still do that. But it does not go to the trouble of wiring up setting the env var using GitHub actions because there is a reasonable chance this code will all be deleted in the not-too-distant future. And until then, it's not even used by GitHub production, only by folks running dependabot-core standalone. So the impact if this does break is fairly small and in that case we'd happily accept a contribution to fix things, but we're unlikely to invest the engineering efforts ourselves to fix it.

This supersedes the approach I took in:

@jeffwidman jeffwidman requested a review from a team as a code owner July 7, 2023 20:09
@github-actions github-actions bot added L: php:composer Issues and code for Composer L: elixir:hex Elixir packages via hex labels Jul 7, 2023
@jeffwidman jeffwidman added the EE Engineering Efficiency label Jul 7, 2023
@jeffwidman jeffwidman force-pushed the stop-putting-account-tokens-in-the-clear branch from 6781cf6 to 30e6744 Compare July 7, 2023 20:29
After I rotated the Gemfury/Hex.PM tokens, these unit tests started
failing, which made us realize we've been exposing the account tokens
in the clear.

Historically this was fine because:
1. These private registries were used solely for test accounts, it
   didn't matter if they were compromised.
1. Dependabot was a startup manned by a small team, so everyone knew
   these registries were publicly exposed and shouldn't be re-used for
   anything private.

However, 2️⃣ is no longer true... now that :dependabot: is part of
GitHub, the team has grown so there's a risk that someone could upload
something that should stay private to these orgs.

Unfortunately, neither Gemfury nor Hex.PM support limiting the scope of
a token to particular package(s). So while they're read-only, they still
expose everything on the account.

After discussing further, we decided that we no longer want to expose
these tokens, so flipping them to use Env Vars.

Furthermore, these tests exercise private registry auth code in
`dependabot-core`, but we don't use that in production at GitHub.
Instead, we use a [private credential
proxy](https://github.com/dependabot/dependabot-core#private-registry-credential-management).

Long term, we've batted around the idea of open sourcing that, in which
case we'd remove all the private registry auth code from
`dependabot-core`.

So this PR removes the plain text tokens (and I will also delete them
from the registry side to ensure they aren't usable). And wires up env
var support so that if we _do_ need to run these tests, we can still do
that. But it does _not_ go to the trouble of wiring up setting the env
var using GitHub actions because there is a reasonable chance this code
will all be deleted in the not-too-distant future. And until then, it's
not even used by GitHub production, only by folks running
`dependabot-core` standalone. So the impact if this does break is fairly
small and in that case we'd happily accept a contribution to fix things,
but we're unlikely to invest the engineering efforts ourselves to fix
it.
@jeffwidman jeffwidman force-pushed the stop-putting-account-tokens-in-the-clear branch from 30e6744 to b522d30 Compare July 7, 2023 20:34
@jeffwidman jeffwidman merged commit 8b4e7c7 into main Jul 7, 2023
86 checks passed
@jeffwidman jeffwidman deleted the stop-putting-account-tokens-in-the-clear branch July 7, 2023 20:45
@jeffwidman
Copy link
Member Author

I have revoked the tokens that were previously exposed here in plain text.

brettfo pushed a commit to brettfo/dependabot-core that referenced this pull request Oct 11, 2023
After I rotated the Gemfury/Hex.PM tokens, these unit tests started
failing, which made us realize we've been exposing the account tokens
in the clear.

Historically this was fine because:
1. These private registries were used solely for test accounts, it
   didn't matter if they were compromised.
1. Dependabot was a startup manned by a small team, so everyone knew
   these registries were publicly exposed and shouldn't be re-used for
   anything private.

However, 2️⃣ is no longer true... now that :dependabot: is part of
GitHub, the team has grown so there's a risk that someone could upload
something that should stay private to these orgs.

Unfortunately, neither Gemfury nor Hex.PM support limiting the scope of
a token to particular package(s). So while they're read-only, they still
expose everything on the account.

After discussing further, we decided that we no longer want to expose
these tokens, so flipping them to use Env Vars.

Furthermore, these tests exercise private registry auth code in
`dependabot-core`, but we don't use that in production at GitHub.
Instead, we use a [private credential
proxy](https://github.com/dependabot/dependabot-core#private-registry-credential-management).

Long term, we've batted around the idea of open sourcing that, in which
case we'd remove all the private registry auth code from
`dependabot-core`.

So this PR removes the plain text tokens (and I will also delete them
from the registry side to ensure they aren't usable). And wires up env
var support so that if we _do_ need to run these tests, we can still do
that. But it does _not_ go to the trouble of wiring up setting the env
var using GitHub actions because there is a reasonable chance this code
will all be deleted in the not-too-distant future. And until then, it's
not even used by GitHub production, only by folks running
`dependabot-core` standalone. So the impact if this does break is fairly
small and in that case we'd happily accept a contribution to fix things,
but we're unlikely to invest the engineering efforts ourselves to fix
it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
EE Engineering Efficiency L: elixir:hex Elixir packages via hex L: php:composer Issues and code for Composer
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants