Possible to automagically use ${{ github.token }} ?

[jcbhmr]

Currently:

github-wiki-action/action.yml

Lines 10 to 16 in 7f44b14

	required: false
	default: 'wiki/'
	GH_TOKEN:
	description: 'The GitHub Token for this action to use. Specify secrets.GITHUB_TOKEN.'
	required: true
	GH_MAIL:
	description: 'The email associated with the token.'

But, I think you can make it magic so you don't need to specify the GH_TOKEN variable:

  GH_TOKEN:
    description: 'The GitHub Token for this action to use. Specify secrets.GITHUB_TOKEN.'
    required: true
    default: ${{ github.token }}
    # 🔺

I don't know 100% for sure, but I think this is possible. I think it's at least worth investigating though.

Here's what I know does work: https://github.com/jcbhmr/publish-wiki-action/blob/a9cd93ca56fd5ed2bf562abc26af3771fb8e63bd/action.yml

runs:
  using: composite
  steps:
    - id: gh-action
      run: '"${GITHUB_ACTION_PATH%/}/index.sh"'
      shell: bash
      # https://github.com/actions/runner/issues/665
      env:
        GITHUB_TOKEN: ${{ github.token }}
        INPUT_PATH: ${{ inputs.path }}

[Andrew-Chen-Wang]

That is pretty interesting, and honestly pretty surprising security wise. Without specified user input of a GitHub token, public repositories (from first glance) are at risk of write vulnerabilities from a third party library/action. Does the above code actually permit pushing without the GitHub action yml file specifying token?

[jcbhmr]

That is pretty interesting, and honestly pretty surprising security wise. Without specified user input of a GitHub token, public repositories (from first glance) are at risk of write vulnerabilities from a third party library/action

I think they were until the default got switched to read-only https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/

Does the above code actually permit pushing without the GitHub action yml file specifying token?

This workflow works!

name: Test
on:
  push:
    paths: [index.sh, action.yml, wiki/**, .github/workflows/test.yml]
concurrency: test
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - uses: ./

https://github.com/jcbhmr/publish-wiki-action/blob/a9cd93ca56fd5ed2bf562abc26af3771fb8e63bd/.github/workflows/test.yml

I don't think that it would work if I created a new repo today since the default is contents: read not contents: write (see Changelog blog https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/)

Yeah so that repo has inherited the default read-write and I could change it if I wanted

[Andrew-Chen-Wang]

I think doing this implicitly is not great practice, so closing. Feel free to add more comments.

[jcbhmr]

I think doing this implicitly is not great practice, so closing.

To play advocate for the other side, I think that this:

- uses: actions/checkout@v3 # doesn't need GH_TOKEN to pull from repo
- uses: Andrew-Chen-Wang/github-wiki-action # to conform with others, it'd be nice to have default pick it up
- uses: actions/deploy-pages@v1 # picks up token to deploy a website
- uses: stefanzweifel/git-auto-commit-action@v4 # literally pushes to the repo with one line, no token

is preferable to the verbosity of this:

- uses: actions/checkout@v3
  with:
    token: ${{ github.token }}
- uses: Andrew-Chen-Wang/github-wiki-action
  with:
    GH_TOKEN: ${{ github.token }}
- uses: actions/deploy-pages@v1
  with:
    token: ${{ github.token }}
- uses: stefanzweifel/git-auto-commit-action@v4
  with:
    token: ${{ github.token }}

note that you STILL NEED TO DECLARE PERMISSIONS to give that token access to writing the pages, repo, issues, whatever: https://github.com/actions/deploy-pages

    # Grant GITHUB_TOKEN the permissions required to make a Pages deployment
    permissions:
      pages: write      # to deploy to Pages
      id-token: write   # to verify the deployment originates from an appropriate source

[Andrew-Chen-Wang]

Will look into it. I think actually having tests with the CI would help and also having a test on private repos would be great too