build-push-action VS checkout

Starting with version 4, docker/build-push-action builds images using the OCI format by default. OCI (Open Container Initiative) is the modern standard that is supported by AWS ECR. However, AWS Lambda does not support OCI image manifests. Lambda only accepts the older Docker v2 schema: application/vnd.docker.distribution.manifest.v2+json

docker/build-push-action

Does build-push-action solve this? I haven’t used their multi-arch configs but I was under the impression that it was pretty smooth.

https://github.com/docker/build-push-action

To publish images to Docker Hub, I use the docker/build-push-action@v6, where I specify:

Docker Build and Publish:

## Local Cache This method leverages local storage for caching Docker layers. The downside is that old cache entries aren’t deleted automatically, so the cache size might increase over time. A temporary fix involves moving and cleaning the cache after each build. ```yaml //".github/workflows/build.yml" name: Docker Build on: push: jobs: docker: runs-on: ubuntu-latest steps: - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 // highlight-start - name: Cache Docker layers uses: actions/cache@v4 with: path: /tmp/.buildx-cache key: ${{ runner.os }}-buildx-${{ github.sha }} restore-keys: | ${{ runner.os }}-buildx- // highlight-end - name: Login to Docker Hub uses: docker/login-action@v3 with: username: ${{ vars.DOCKERHUB_USERNAME }} password: ${{ secrets.DOCKERHUB_TOKEN }} // highlight-start - name: Build and push uses: docker/build-push-action@v6 with: push: true tags: user/app:latest cache-from: type=local,src=/tmp/.buildx-cache cache-to: type=local,dest=/tmp/.buildx-cache-new,mode=max // highlight-end - # Temp fix # https://github.com/docker/build-push-action/issues/252 # https://github.com/moby/buildkit/issues/1896 name: Move cache run: | rm -rf /tmp/.buildx-cache mv /tmp/.buildx-cache-new /tmp/.buildx-cache

Configuring the GitHub Actions Workflow We set up a GitHub Actions workflow to automate the integration and deployment process. The integration workflow is triggered on every pull request while the deployment workflow was triggered upon the completion of the build and push workflow for docker images gotten from the marketplace. It used the appleboy/ssh-action to execute the deployment script on the server.

We use the docker/build-push-action to build the application image. In addition to setting the correct tag, the image build step must also provide a label matching your service name. Because the image should be pushed to your container registry, we set push: true, and because we want ludicrous build speed we instruct the build step to utilize the GitHub Actions cache.

name: Lint and Dockerize the app on: push: branches: [master] pull_request: branches: [master] env: # Use docker.io for Docker Hub if empty REGISTRY: docker.io # github.repository as / IMAGE_NAME: ${{ github.repository }} jobs: build: runs-on: ubuntu-latest permissions: contents: read packages: write steps: - name: Checkout repository uses: actions/checkout@v2 - name: Set up Google Cloud uses: google-github-actions/setup-gcloud@v0.6.0 with: project_id: ${{ secrets.GCP_PROJECT_ID }} service_account_key: ${{ secrets.GCP_SA_KEY }} # Login against a Docker registry except on PR # https://github.com/docker/login-action - name: Log into registry ${{ env.REGISTRY }} # if: github.event_name != 'pull_request' uses: docker/login-action@v1 with: username: ${{ secrets.DOCKER_USERNAME }} password: ${{ secrets.DOCKER_PASSWORD }} # Extract metadata (tags, labels) for Docker # https://github.com/docker/metadata-action #- name: Extract Docker metadata # id: meta # uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38 # with: # images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} # Build and push Docker image with Buildx (don't push on PR) # https://github.com/docker/build-push-action - name: Build and push Docker image uses: docker/build-push-action@v2 with: context: ./ tags: ${{ secrets.DOCKER_USERNAME }}/magga:latest push: true file: ./Dockerfile - name: Image digest run: echo

To add on, GitHub has made it explicitly clear that they are both not working on features to focus on their Azure adoption and many core projects are in stasis even from community contributions[^1].

[^1]: https://github.com/actions/checkout#note

The actions/checkout repo still doesn't even use immutable releases so I'll believe it when I see it

https://github.com/actions/checkout/issues/2316

Well, it is a git commit hash of the action repo that contains the transpiled/bundled javascript.

Like: https://github.com/actions/checkout/tree/11bd71901bbe5b1630c...

So I'm pretty sure that for the same commit hash, I'll be executing the same content.

The offending commit seems to be: https://github.com/aquasecurity/trivy/commit/1885610c6a34811... which updates the action to `actions/checkout@70379aad1a8b40919ce8b382d3cd7d0315cde1d0 # v6.0.2`. https://github.com/actions/checkout/commit/70379aad1a8b40919... is not actually in `actions/checkout` but a fork, and it pulls malicious code from the typo-squatted "scan.aquasecurtiy.org" (note the _tiy_).

Any system with Trivy 0.69.4 on it (and being run) can be assumed to be compromised.

The first step in the job uses actions/checkout to clone the repo it runs in. We then run the ruby/setup-ruby action which installs Ruby and runs Bundler. If Brakeman is in your Gemfile (see above), that'll be installed at this stage.

Github itself provides several reusable workflows, and you've probably already used them many times. One of them is a checkout action which allows you to check out a repo.

what with actions/checkout@v4, hows that documented?

https://github.com/actions/checkout/issues/567#issuecomment-...

GH has a `permissions:` entry and this mechanism already for internal repo action sharing. And thousands of our dollars per month.

Here is an example in the wild: https://github.com/actions/checkout/actions/workflows/publis...