Dependabot PR's actions lost access to secrets

[ShockwaveNN]

I think something changed in the logic of GitHub actions triggered via dependabot update, around a week ago, but I didn't find any mention in any GitHub changelog

So, my situation is:

I've got several projects of RubyGems, which triggers GitHub Actions with specs on each PR. Those actions require access to secrets, and fail without secrets

Before a week ago if I got Dependabot PRs - all Actions failed, but if I retrigger them manually with my usual Github account via web interface - after retrigger they became aware of secrets and become green

But something happened last week and now the only way to trigger Action with access to secrets - is to checkout this branch locally, making git commit --amend so GitHub think I'm an author and after that Actions are green

Could you point out in the direction if I'm doing something wrong or why it was changed a week or two ago?

Package ecosystem
rubygems and bundler
Package manager version
bundler 2.3.19
Language version
ruby 3.1
dependabot.yml content

version: 2
updates:
  - package-ecosystem: bundler
    directory: "/"
    schedule:
      interval: daily
      time: "08:00"
      timezone: "Europe/Moscow"
    open-pull-requests-limit: 10
    allow:
      - dependency-type: direct
      - dependency-type: indirect

[jurre]

Thanks for reporting this, I'm not aware of anything having changed, but I will check with the Actions team! Could you share your actions workflow file as well maybe?

[ShockwaveNN]

I can share the whole repo, one of my several

https://github.com/ONLYOFFICE-QA/onlyoffice_s3_wrapper/blob/master/.github/workflows/ruby.yml

I'm surprise that I'm only one reporting this, I've checked issues at Dependabot and Github Actions daily and today I'm finally gave up and made my own report )

I got a little chance that I'm doing something wrong and maybe you can help me with that, or maybe it's really an issue

[jurre]

          S3_KEY: ${{ secrets.S3_KEY }}
          S3_PRIVATE_KEY: ${{ secrets.S3_PRIVATE_KEY }}

Do you have those secrets set up as both Dependabot secrets and Actions secrets? It's curious to me that it used to work and stopped working, but Dependabot triggered actions have access to Dependabot secrets but not Actions ones by default, so exposing them as Dependabot Secrets could be a potential fix if they're not.

[mkrakowitzer]

We have this same issue at the moment. Actions triggered by dependabot would fail as it did not have access to secrets, and then someone from the team could retrigger them and they would now pass (As the user triggering the action to rerun has access to those secrets).

Secrets are not configured as dependabot secrets, However we would prefer not to add these secrets to dependebot and prefer retriggering them as a user after the changes have been reviewed.

[ShockwaveNN]

@jurre

Do you have those secrets set up as both Dependabot secrets and Actions secrets?

No, where was never Dependabot specific secrets configures, as I mention earlier I've triggered task manually

Frankly this is first time I'm aware that specific secrets for Dependabot are exists )

[ShockwaveNN]

@mkrakowitzer

Actions triggered by dependabot would fail as it did not have access to secrets, and then someone from the team could retrigger them and they would now pass (As the user triggering the action to rerun has access to those secrets).

This is the point. For me it was like this everytime as I understand is correct behavior
But right now even if I trigger action manually via my personal account - dependabot actions still have no access to secretd

[jurre]

That's surprising, manually triggered workflows should have access to regular Actions secrets. I'm following up with the Actions team as it's not something we can fix or even really investigate on our end. Will keep you posted as I hear more from them.

Edit: turns out this has not been true for a while

[ShockwaveNN]

@jurre Ok thanks, I think tomorrow morning there will be some new PRs from dependabot and I'll leave this open for you to investigate

[jurre]

So, the Actions team have gotten back to me with:

re-run has used the original actor at least in that case of dependabot.

So it does seem like this is by design, and the suggested solution is to add the secrets as Dependabot secrets. I'm trying to find if there is any communication that we've sent out on this, and looking to add it to our documentation.

[mkrakowitzer]

What do we do in the case where we do not want a third party (dependabot) to have access to these secrets?

[jurre]

I did manage to find this mentioned in our docs, for what it's worth: https://docs.github.com/en/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions#manually-re-running-a-workflow

What do we do in the case where we do not want a third party (dependabot) to have access to these secrets?

Dependabot is not a third party, we're a native to and a part of GitHub, the way we store secrets is shared with the way Actions does it. The code in dependabot-core does not have direct access to these secrets, instead requests are routed through a short-lived and job-specific proxy where the credentials are appended to requests if they match a configuration in your dependabot private registry config.

If you still don't want to configure this, right now the only way I can think of to make this work is something fairly contrived, like to have some sort of action that monitors PRs opened by Dependabot, grabs it's contents and re-opens a new PR under a different user. I would not recommend this though.

[jcscottiii]

If the GitHub team needs more information, I wrote up an issue about the previous behavior and the new behavior: web-platform-tests/wpt.fyi#2928

[ShockwaveNN]

And an example that I've promised

So this is actions run which was created by dependabot, I've not touched anything in it
It shows empty secrets:

And this one which I've retriggered manually by main usual main account (this one) - same problem with empty keys

Am I right that I need to redone my configuration to use Dependabot secrets? It's no problem for me

But I still do not understand that the Actions team has confirmed that something changed in dependabot configs a week or two ago. Or does no one know why this happened?

Scenario with manual retrigger of dependabot update 100% worked for me several weeks ago daily, I cannot we wrong about this