D-M

[bio-boris]

No description provided.

To fix the problem, add an explicit permissions: block at the root level of the workflow file .github/workflows/manual-build.yml (typically after the name: and before on:), or inside the job definition. The block should grant only the privileges necessary for the workflow to function. Since the workflow delegates all steps via a reusable workflow and doesn't contain steps itself, the minimal permissions are likely sufficient (e.g., contents: read). If the invoked workflow performs actions like pushing commits, creating releases, or interacting with pull requests, those permissions can be scoped down as needed in the reusable workflow. For now, setting permissions: contents: read at the root level is the recommended fix, which allows jobs to read repository contents via the GITHUB_TOKEN but not write.

---

To resolve this problem, add a permissions block to the workflow at the root level to explicitly set the minimal privileges required. The majority of GitHub workflows that build, tag, or push code only require contents: read for basic operations and may require additional permissions if interacting with pull requests (pull-requests: write, etc.). Since the workflow primarily builds and scans as part of a PR pipeline, and unless there are known requirements for write access (unlikely as all jobs use uses:), the safest starting point is contents: read. This can be expanded upon as needed if future jobs require extra access.

The change should be made by inserting the following at the top level (after the name: and before on: is conventional):

permissions:
  contents: read

No additional code, dependencies, or imports are required beyond amending this block.

---

To fix this problem, we should explicitly add a permissions block to the workflow file, at the root level (top, just under name: and before on:), to define the least privileges necessary for all jobs, unless specific jobs require more (in which case job-level blocks can be added). Given that this workflow's jobs are primarily using uses: to call reusable workflows, and absent further details, the safest and minimal useful settings are usually contents: read. If you know that the workflow only needs read access to repo contents, set contents: read; otherwise, if specific permissions such as pull-requests: write are needed (for example, if the build triggers status updates, comments, or labeling), you can include those.

The file to edit is .github/workflows/pr_build.yml and the block to add is:

permissions:
  contents: read

If you know or later find that more permissions are needed for the actions performed, you can expand this to include those additional keys. Place this block after the name: block and before on: for best clarity.

To address the issue, add a top-level permissions block to .github/workflows/pr_build.yml. This permissions block should be placed alongside the name: and on: keys, preceding the jobs: block. The minimal safe default is contents: read, unless any of the jobs or the called reusable workflows require extra privileges, such as writing to pull requests, issues, etc., in which case those should be individually added. Since the workflow only appears to build and possibly push tags (though the actual reusable workflows do the work), start with the minimal permissions: contents: read. If the reusable workflows require additional permission (e.g., pull-requests: write), the user should customize further.

Changes required:

• Insert at the top level (after name: ... and before on:):

  permissions:
    contents: read

• No changes to imports, methods, or definitions are needed.

---

To fix the problem, a permissions key should be added to the workflow file, restricting the permissions of the GITHUB_TOKEN to adhere to least privilege. The permissions block can be added at the root of the workflow (before jobs:), which will apply these permissions to all jobs unless they override it individually. Since the jobs involve building, pushing images, and performing security scans, the minimum required permissions are likely contents: read and potentially packages: write (if publishing to GitHub Packages), or pull-requests: write (if interacting with PRs). However, unless there is evidence that write operations to contents or packages are involved, the safest option is to start with contents: read, which allows reading repository contents without write access.

The single best way to fix the problem, without changing any existing functionality, is to insert:

permissions:
  contents: read

on a new line after the workflow name: ... block and before the on: block. If later it proves specific jobs/tasks require more permissions (e.g., writing to packages or interacting with pull-requests), these can be added in future edits.

To fix the problem, add a permissions block specifying the minimum required permissions at the root level of the workflow .github/workflows/pr_build.yml. This will apply reduced privileges to all jobs that do not themselves specify permissions, thereby limiting the capabilities of the GITHUB_TOKEN used in this workflow. Since the jobs here use reusable workflows, unless those require write access to specific resources, the most restrictive and commonly appropriate global permissions are contents: read (which is minimally required for most workflows to function). If later job requirements become known, they can be specified explicitly. The single best fix is to add:

permissions:
  contents: read

at the top level (between lines 2 and 3), directly under the name: field and above on:. This approach is in accordance with GitHub's recommended least-privilege workflow permission guidelines.

To fix this problem, you should add the permissions key at the root level of .github/workflows/release-main.yml. This setting will ensure all jobs in the workflow (unless overridden by their own permissions key) get only the specified minimal permissions. In general for release workflows, a safe default is contents: read unless you know you need write permissions for contents, issues, or pull-requests—then you can grant only those sub-permissions.
The best fix is to add the following block after the workflow name property and before on::

permissions:
  contents: read

If any of the reusable workflows absolutely require more permissions, you should grant those specifically; otherwise, start with minimal permissions and escalate only if necessary.

To fix this issue, we should add a permissions block to the workflow file. The recommended approach is to set the permissions block at the top level, restricting contents to read and only enabling specific writes as needed. Since the provided workflow seems to center around building and pushing images in response to release events, unless jobs need to write issues or pull requests, we should start with contents: read and add additional writes only as required (e.g., if the push image step requires extra permissions, we can extend later). The change should be made by adding the following lines just after the name: key at the start of .github/workflows/release-main.yml.

The fix requires adding a permissions block to the YAML, specifying at least:

permissions:
  contents: read

If later analysis shows jobs require further permissions, those can be added.

To fix this problem, you should add a permissions block at the workflow root. This will explicitly set least-privilege permissions for all jobs in the workflow unless a job has its own block. For minimal risk, you can start with contents: read, which allows jobs to fetch repository contents but not to push changes, and expand only as needed for jobs that require more access.

How to fix:

• At the top level of the workflow (just after the name: field and before on:), add:

  permissions:
    contents: read

  If any of the jobs require more permissions to function (for example, creating GitHub releases or modifying issues), you'll need to enumerate those specifically, but nothing in the snippet suggests that's required—these jobs primarily call reusable workflows and pass read-only inputs.

Where to change:
At the very top of .github/workflows/release-main.yml, after the name: field.

---

[bio-boris]

This pull request introduces significant updates to the project's CI/CD workflows, Python environment, and documentation. The main improvements include migrating to standardized GitHub Actions workflows for building, testing, and releasing, upgrading the Python version and dependency management tools, and enhancing documentation for integration testing. Additionally, the project now vendors key dependencies to resolve conflicts and improve security.

CI/CD Workflow Modernization:

• Replaced custom workflow files with standardized, reusable GitHub Actions workflows for build, test, pull request, manual, and release processes. This includes new workflows like .github/workflows/pr_build.yml, .github/workflows/manual-build.yml, and .github/workflows/release-main.yml, and the removal of the old .github/workflows/build-test-push.yml. [1] [2] [3] [4]
• Added a CodeQL analysis workflow for automated code scanning and security analysis.
• Added Dependabot configuration for automated dependency updates across Docker, pip, and GitHub Actions.

Python Environment and Dependency Management:

• Upgraded the base Python version from 3.7 to 3.9.19 in both the Dockerfile and GitHub Actions workflows. [1] [2] [3]
• Upgraded Poetry to version 2.1.2 and improved installation commands for better compatibility and reproducibility.
• Vendored kbase-jsonrpcbase and jsonrpc11base directly into the repository to resolve dependency conflicts and improve security. [1] [2] [3]

Testing and Documentation Improvements:

• Updated the integration testing documentation for accuracy and clarity, including new environment variable names, updated commands, and sample output reflecting the upgraded Python and test suite. [1] [2] [3]
• Updated the test workflow to use the latest GitHub Actions, Python 3.9.19, and modern Codecov integration.

Other Notable Changes:

• Added and updated changelog entries to reflect these changes.
• Minor cleanup in docker-compose.yaml and other supporting files.

These changes collectively modernize the project's development and deployment practices, improve security, and enhance maintainability.