Is this an open source repository, where people will be using forks to propose changes to your workflow?

If so, see these docs. The default setting requires approval of workflows to run for all outside collaborators, which means other people won't be able to extract your secrets.

If you have collaborator access and a personal access token with the repo scope, you can use the API to add secrets to the repository. If you can't do that, then you'll just have to wait. Alternatively, if you already have access to an alternative secret store via the GitHub Actions secrets, then you could use that.

Note that GitHub doesn't provide secret backdoors to the repository settings because the admin is slow. That's an organizational problem.

Yes, secrets are safe to use in public repositories but there are some things you should be careful about.

• All secrets are automatically masked in build logs and show as ***. However, if during your workflow you create a sensitive credential from a secret (e.g. base64 an API key) then you should mask the new value so it doesn't leak in the build log.

  echo "::add-mask::My sensitive value"
  

• If you are very concerned about the security of your secrets, I would also suggest not using third party GitHub actions directly by following the action's tags or branches. Fork the action and use your fork in workflows. This will prevent the possibility of someone modifying an action you are using to capture secrets being used by the action, and send them to some external server under their control.

  Alternatively, use the action directly and reference the commit hash for the version you want to target.

  - uses: thirdparty/foo-action@172ec762f2ac8e050062398456fccd30444f8f30
  

• Use two-factor authentication (2FA) on your account. If your account is compromised, it's trivial for an attacker to create a workflow and export your secrets.

• Repository collaborators or any organization users with write access are able to create a workflow to export secrets. So manage access to your repository carefully.

Points related to pull requests:

• Public repository pull_request events triggered by forks do not have access to secrets, except for the default GITHUB_TOKEN. Additionally, The GITHUB_TOKEN has read-only access when an event is triggered by a forked repository. These are intentional restrictions enforced by GitHub Actions to prevent an attacker creating a pull request containing a workflow that captures secrets, or uses secrets to perform operations.
• The pull_request_target event does not have secret restrictions for events triggered by forks. By default it checks out the last commit on the base branch, but it is possible to checkout the pull request HEAD. Choosing to do this requires extreme caution. Passing secrets to any code that could be modified in a pull request could allow an attacker to write code to export secrets.