Update APT repository on full release/pre-release #1807
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| runs-on: | ||
| - self-hosted | ||
| - Linux | ||
| - X64 | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v4 | ||
| - name: Download .deb assets from release | ||
| env: | ||
| GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| run: | | ||
| mkdir debs | ||
| gh release download "${{ github.event.release.tag_name }}" \ | ||
| --pattern "*.deb" \ | ||
| --dir debs | ||
|
|
||
| - name: Install ruby with deb-s3 | ||
| run: | | ||
| sudo apt-get install -y ruby | ||
| gem install deb-s3 | ||
| echo "$(ruby -r rubygems -e 'puts Gem.user_dir')/bin" >> $GITHUB_PATH | ||
|
|
||
| - name: Upload DEB to APT repository | ||
| run: | | ||
| if [[ "${{ github.event.release.prerelease }}" == "true" ]]; then | ||
| component="pre-release" | ||
| else | ||
| component="release" | ||
| fi | ||
|
|
||
| for deb_file in debs/*.deb; do | ||
| if [[ "$deb_file" == *"ubuntu-22-04-lts"* ]]; then | ||
| codename="bookworm" | ||
| else | ||
| codename="trixie" | ||
| fi | ||
|
|
||
| echo "Uploading $deb_file to $codename" | ||
| deb-s3 upload -l \ | ||
| --bucket=apt.defguard.net \ | ||
| --access-key-id=${{ secrets.AWS_ACCESS_KEY_APT }} \ | ||
| --secret-access-key=${{ secrets.AWS_SECRET_KEY_APT }} \ | ||
| --s3-region=eu-north-1 \ | ||
| --no-fail-if-exists \ | ||
| --codename="$codename" \ | ||
| --component="$component" | ||
| "$deb_file" | ||
| done | ||
|
|
||
| apt-sign: |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 3 days ago
To fix the problem, explicitly restrict GITHUB_TOKEN permissions in this workflow to the least privilege needed. Since the workflow only downloads release assets and does not modify repository data, it should only require read access to repository contents. The recommended minimal block is permissions: contents: read.
The best, non‑breaking fix is to add a top‑level permissions block (so it applies to all jobs) just after the on: section and before jobs: in .github/workflows/update-repositories.yml. This way, both update-apt and apt-sign inherit the restricted permissions, and no job needs write access. No additional imports, methods, or definitions are required; it’s just a YAML configuration change.
Concretely: in .github/workflows/update-repositories.yml, insert:
permissions:
contents: readbetween the existing on: block (lines 3–5) and the jobs: key (line 7).
| @@ -4,6 +4,9 @@ | ||
| release: | ||
| types: [published] | ||
|
|
||
| permissions: | ||
| contents: read | ||
|
|
||
| jobs: | ||
| update-apt: | ||
| runs-on: |
| needs: | ||
| - update-apt | ||
| runs-on: | ||
| - self-hosted | ||
| - Linux | ||
| - X64 | ||
| steps: | ||
| - name: Sign APT repository | ||
| run: | | ||
| export AWS_ACCESS_KEY_ID=${{ secrets.AWS_ACCESS_KEY_APT }} | ||
| export AWS_SECRET_ACCESS_KEY=${{ secrets.AWS_SECRET_KEY_APT }} | ||
| export AWS_REGION=eu-north-1 | ||
| sudo apt update -y | ||
| sudo apt install -y awscli curl jq | ||
|
|
||
| for DIST in trixie bookworm; do | ||
| aws s3 cp s3://apt.defguard.net/dists/${DIST}/Release . | ||
|
|
||
| curl -X POST "${{ secrets.DEFGUARD_SIGNING_URL }}?signature_type=both" \ | ||
| -H "Authorization: Bearer ${{ secrets.DEFGUARD_SIGNING_API_KEY }}" \ | ||
| -F "file=@Release" \ | ||
| -o response.json | ||
|
|
||
| cat response.json | jq -r '.files["Release.gpg"].content' | base64 --decode > Release.gpg | ||
| cat response.json | jq -r '.files.Release.content' | base64 --decode > InRelease | ||
|
|
||
| aws s3 cp Release.gpg s3://apt.defguard.net/dists/${DIST}/ --acl public-read | ||
| aws s3 cp InRelease s3://apt.defguard.net/dists/${DIST}/ --acl public-read | ||
|
|
||
| done | ||
| (aws s3 ls s3://apt.defguard.net/dists/ --recursive; aws s3 ls s3://apt.defguard.net/pool/ --recursive) | awk '{print "<a href=\""$4"\">"$4"</a><br>"}' > index.html | ||
| aws s3 cp index.html s3://apt.defguard.net/ --acl public-read |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 3 days ago
In general, to fix this issue you must explicitly declare a permissions block in the workflow (either at the top level or per job) that limits GITHUB_TOKEN to the minimal required scopes. Since this workflow only needs to read repository contents (for checkout and downloading release assets) and does not write back to GitHub, we can safely restrict contents to read and leave all other scopes at their implicit default of none.
The best fix here is to add a single, top‑level permissions block just under the on: section so that it applies to both update-apt and apt-sign jobs. Based on the current steps, no job writes to the repository or manipulates issues/PRs, so contents: read is sufficient. No existing functionality changes: actions/checkout@v4 and gh release download continue to work with read access; all other interactions use explicit AWS and custom API secrets, not GITHUB_TOKEN.
Concretely, in .github/workflows/update-repositories.yml, after the on: block (after line 5), insert:
permissions:
contents: readNo additional imports, methods, or definitions are needed, since this is purely a YAML configuration change in the workflow.
| @@ -4,6 +4,9 @@ | ||
| release: | ||
| types: [published] | ||
|
|
||
| permissions: | ||
| contents: read | ||
|
|
||
| jobs: | ||
| update-apt: | ||
| runs-on: |
jakub-tldr
changed the title
Involves: https://github.com/DefGuard/internal/issues/40