avoid pushing hashes

[tac0turtle]

Description

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Performance improvement
• Refactoring

Related Issues

Fixes #(issue)

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Testing

Additional Notes

[gemini-code-assist]

Summary of Changes

Hello @tac0turtle, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a modification to the Docker image build and push workflow by preventing the generation and pushing of Software Bill of Materials (SBOMs). The primary goal is to streamline the image creation process and potentially reduce the metadata associated with pushed images, aligning with the intent to avoid pushing unnecessary hashes.

Highlights

• Docker Build Configuration: The Docker build process has been updated to explicitly disable Software Bill of Materials (SBOM) generation and pushing. This change adds the --sbom=false flag to the docker buildx build command within the docker_build_push macro in the Makefile.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[claude]

Claude finished @tac0turtle's task —— View job

---

PR Review Complete ✅

Reviewing PR #92: "avoid pushing hashes"

Todo List:

• Read and analyze the Makefile changes
• Evaluate the Docker build modification
• Assess security implications of disabling SBOM
• Check alignment with PR title and intent
• Look for related tests or documentation
• Provide comprehensive review feedback

Review Feedback

Summary of Changes

This PR adds the --sbom=false flag to the Docker buildx command in Makefile:164, specifically within the docker_build_push macro that handles cross-architecture Docker image builds.

Code Quality and Best Practices ✅

• Clean implementation: The change is minimal and focused, adding only the necessary flag
• Consistent style: The flag placement follows the existing multi-line format pattern used for other flags
• Appropriate location: The flag is correctly placed in the docker_build_push macro that handles the multi-arch builds

Potential Issues and Concerns

🔶 Title Alignment Issue
The PR title "avoid pushing hashes" is somewhat misleading. SBOMs (Software Bill of Materials) contain dependency information, not necessarily "hashes" in the typical sense. Consider a more accurate title like "disable SBOM generation for Docker builds" or "avoid pushing SBOMs".

🔶 Missing Documentation

• No explanation in the PR description for why SBOM generation should be disabled
• No comment in the Makefile explaining the reasoning for --sbom=false
• Consider adding a brief comment above line 164 explaining why SBOMs are disabled

Security Considerations ⚠️

Trade-offs of disabling SBOM:

• Reduced transparency: SBOMs provide valuable dependency and vulnerability information
• Compliance impact: Some security policies require SBOMs for container images
• Security tooling: Disables automatic vulnerability scanning that relies on SBOM data

Questions to consider:

• Is this change driven by build performance, storage concerns, or security policy?
• Are there alternative approaches to address the underlying issue?
• Should this be configurable rather than always disabled?

Performance Considerations ✅

• Positive impact: Disabling SBOM generation will slightly reduce build time and image size
• Network efficiency: Less metadata to push to the registry

Test Coverage 📋

• No direct tests needed: This is a build configuration change that doesn't affect runtime behavior
• Manual verification recommended: Test that the Docker build still works correctly without SBOM generation
• CI integration: The existing CI should validate that builds succeed with this change

Additional Notes

• The change is consistent with the existing --provenance=false flag, suggesting a deliberate choice to minimize build metadata
• Consider if this should be controlled by an environment variable for flexibility in different deployment scenarios

Recommendation

Approve with minor suggestions:

1. Update the PR title to be more descriptive
2. Add a brief explanation in the PR description
3. Consider adding a comment in the Makefile explaining the rationale

The change itself is technically sound and safe to merge.

---

[gemini-code-assist]

Code Review

This pull request updates the Makefile to disable Software Bill of Materials (SBOM) generation during the Docker build and push process. While this change is consistent with the existing flag to disable provenance information, it reduces visibility into the software supply chain. My review highlights the security implications of disabling SBOMs and recommends enabling it in the future to improve security posture.

[gemini-code-assist]

Disabling SBOM generation reduces supply chain security and transparency. SBOMs are crucial for tracking dependencies, identifying vulnerabilities, and ensuring license compliance. While this might be a necessary temporary fix for a build issue, it is strongly recommended to re-enable SBOM generation (--sbom=true) as soon as possible to maintain good security practices.