Revert repository to commit 244d656

[antonis]

This reverts all changes made after commit 244d656

To fix the problem, you should add a permissions block to the workflow to explicitly restrict the GITHUB_TOKEN permissions to the minimum required. In this case, the workflow only needs to read repository contents (for actions/checkout) and upload artifacts (which does not require write access to repository contents). The recommended fix is to add permissions: contents: read at the root level of the workflow (above jobs:), which will apply to all jobs unless overridden. This change should be made at the top of the .github/workflows/build-ios.yml file, after the name: and before the on: block.

To fix the problem, add a permissions block to the workflow file. This can be done at the top level (applies to all jobs) or at the job level (applies to individual jobs). Since none of the jobs in this workflow appear to require write access (they only call reusable workflows and run builds/tests), the safest minimal starting point is to set permissions: read-all at the workflow level. This restricts the GITHUB_TOKEN to read-only permissions for all scopes, adhering to the principle of least privilege. If any job or called workflow requires additional permissions, those can be added explicitly in the relevant workflow files.

What to change:

• Add the following block after the name: line and before on: in .github/workflows/build.yml:

  permissions: read-all

• No other changes are needed unless a job requires more permissions, in which case those should be set in the called workflow files.

---

To fix the problem, you should add a permissions block to the workflow. The best way is to add it at the root level, so it applies to all jobs unless overridden. The minimal starting point is usually contents: read, which is sufficient for most build and test workflows that do not need to write to the repository or interact with issues or pull requests. If any job requires additional permissions, you can override the block at the job level. In this case, since all jobs use reusable workflows and there is no evidence that write permissions are needed, adding permissions: contents: read at the root of .github/workflows/build.yml (after the name: and before on:) is the best fix.

To fix the problem, add a permissions block at the top level of the workflow (recommended), or at the job level if different jobs require different permissions. The minimal starting point is contents: read, but some jobs (such as those pushing tags/branches or creating releases) require contents: write. The bump-version and publish-release jobs both perform git operations and create releases, so they require contents: write. The build-android and build-ios jobs only call reusable workflows and do not need elevated permissions, so they can inherit the default or be set to contents: read.

The best way to fix this is to add a permissions block at the workflow root, setting contents: write (since at least two jobs require it). If you want to be more restrictive, you could set contents: write only for the jobs that need it, and contents: read for the rest. For simplicity and clarity, adding at the workflow root is sufficient and safe for this workflow.

Change to make:

• Add the following at the top level of .github/workflows/release.yml, after the name and before on or after on:

  permissions:
    contents: write

---

To fix the problem, you should add a permissions block to the workflow, either at the root level (to apply to all jobs) or to individual jobs as needed. The minimal starting point is to set contents: read, which allows jobs to read repository contents but not write. For jobs that require additional permissions (such as creating releases or pushing tags/branches), you should grant only the necessary write permissions (e.g., contents: write, pull-requests: write). In this case, since the workflow includes jobs that push tags/branches and create releases, those jobs will need contents: write and possibly pull-requests: write, while build jobs likely only need contents: read. The best way to fix this is to add a root-level permissions block with contents: read (as a safe default), and then override with more permissive settings for jobs that require them (e.g., bump-version and publish-release). The changes should be made at the top of the .github/workflows/release.yml file, and within the relevant jobs.

To fix the problem, you should add an explicit permissions block to the workflow. The best way is to add it at the top level of the workflow (just after the name: and on: blocks), so it applies to all jobs unless overridden. You should set the permissions to the minimum required for the workflow to function. Based on the jobs shown:

• The bump-version job pushes tags and branches, so it needs contents: write.
• The publish-release job creates a release, so it needs contents: write.
• The build-android and build-ios jobs use reusable workflows, so their permissions should be set in those workflows, but it's safe to set minimal permissions here.

A good minimal starting point is:

permissions:
  contents: write

If you know that only releases and pushes are needed, you can further restrict, but contents: write is the standard for workflows that push code or create releases.

Add the following block after the name: and before env: in .github/workflows/release.yml.

To fix the problem, you should add a permissions block to the workflow or to each job, specifying only the permissions required for the actions performed. For this workflow, the jobs that push tags/branches and create releases need contents: write, while jobs that only read code or artifacts may only need contents: read. The minimal fix is to add a permissions block at the workflow root, setting contents: write, or to each job as appropriate. Since the bump-version and publish-release jobs perform git pushes and create releases, they need contents: write. The build-android and build-ios jobs likely only need contents: read (assuming they do not push or create releases). The best fix is to add a workflow-level permissions block with contents: write, or, for stricter control, add job-level permissions blocks.

You should edit .github/workflows/release.yml to add the permissions block. The block should be placed at the top level (after name: and before on: or after on:), or within each job as needed.

To fix the problem, add a permissions block to the workflow to explicitly set the minimum required permissions for the GITHUB_TOKEN. Since the workflow appears to only need to download artifacts and check out code (no evidence of writing to the repository, creating issues, or making pull requests), the minimal permission required is likely contents: read. This can be set at the workflow level (applies to all jobs) or at the job level (applies only to the specified job). The best practice is to add it at the top level, just after the name and before on, to ensure all jobs inherit the least privilege unless otherwise specified.

Required change:

• Insert the following block after the name field and before the on field in .github/workflows/test.yml:

  permissions:
    contents: read

No additional methods, imports, or definitions are needed.

---