Fix security-related issues in github actions flagged by zizmor

[peytondmurray]

Issue number of the reported bug or feature request: Closes #287.

Describe your changes
This PR addresses a number of security-related issues in the github actions (and dependabot config) that were flagged by zizmor. Most of the changes are:

• Pinning action versions to commit hashes
• Disable persisting credentials in workflows after checkout
• The default permissions are now set as conservatively as possible

This PR also adds a zizmor action to ensure these issues don't arise in the future.

Note that the container images used during the wheel builds workflow remain unpinned. After weighing the dangers of running a compromised container here, it was decided that the effort of keeping pinned containers up to date was not worth the effort. As a result we have zizmor configured to ignore these rule violations here.

Testing performed
This will be tested by running the CI in this PR.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.22%. Comparing base (4bcc46b) to head (a49f153).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #292   +/-   ##
=======================================
  Coverage   79.22%   79.22%           
=======================================
  Files          51       51           
  Lines        5550     5550           
  Branches      581      581           
=======================================
  Hits         4397     4397           
  Misses       1153     1153           

Flag	Coverage Δ
cpp	79.22% <ø> (ø)
python	79.22% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lkollar]

Looks like this format isn't valid and the build fails.

We chatted about this with @godlygeek and it would be good to leverage Dependabot for keeping the Docker images up to date as well. It seems it's supported.

[peytondmurray]

Great, I've added the Docker section to the dependabot config. It sounds like we also need labels on each image if we want downstream projects that rely on dependabot to pull in metadata about new releases. I've added

LABEL org.opencontainers.image.source="https://github.com/bloomberg/pystack"

to the last image to do this.

The other thing is that the Dependabot config only works if

maintainers must tag the repository with the same tags as the published Docker images. For an example, see the dependabot-fixtures/docker-with-source repository.

I assume they're talking about git tags, right?

[sarahmonod]

I know this was already the case before this PR, but I don't like the fact that the upload and download actions are of different versions.

Can you please check if the latest version for both of them works together?

[peytondmurray]

Sure! I figured I'd let dependabot take care of it, but I'd be happy to update all of the actions, which probably makes the most sense.

[peytondmurray]

Okay, after a few minutes investigation it seems like there is currently a version discrepancy between actions/upload-artifact and actions/download-artifact. So this is fine as is, and in fact it is configured in accordance with the download-artifact usage instructions: https://github.com/actions/download-artifact#download-multiple-filtered-artifacts-to-the-same-directory

I did take the opportunity to bump the setup-uv action to v8, though.