Upon adding melange label, run melange builds, but do not block on them

Add inputs for workflow dispatch to manually re-build a given image.

Inputs documentation: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatchinputs

Description

Development using cgr.dev/chainguard/node on a MacBook m1 is difficult since an arm64 image is not available. I can add --platform linux/amd64 to build an image using Rosetta emulation but this makes the build MUCH slower.

Using FROM node:18-alpine

Using FROM cgr.dev/chainguard/node:18

Description

include gsutil cli in sdk image because we need to use this for syncing pkgs, in order to prevent building all the packages locally.

Seems the binary isn't found.

$ docker run -it --rm cgr.dev/chainguard/wait-for-it:latest-20221214 -t 30 google.com
Unable to find image 'cgr.dev/chainguard/wait-for-it:latest-20221214' locally
latest-20221214: Pulling from chainguard/wait-for-it
a7362c0b0fa5: Pull complete 
Digest: sha256:28b3974f83f5cdd3148e3dbc5fe44c914f86970c746ab6dc35453d43f58f0555
Status: Downloaded newer image for cgr.dev/chainguard/wait-for-it:latest-20221214
exec /usr/bin/wait-for-it: no such file or directory

Related to #118

There is a bunch of specific stuff for if additionalTags is "latest" but we need to support other tags / multitags in badge labels etc

Add a ClusterImagePolicy (see https://github.com/sigstore/policy-controller/tree/main/examples) which runs against all images on a schedule/cron, alert on any failures

Apologies if this is a stupid question.

I'm looking for a distroless nginx image and came across your repo while googling. I've pulled the image down and looked inside to see what contents are bundled.

I noted a lot of binaries in the /bin, /sbin directories, are these needed to execute nginx? If not is there a plan to produce a version of this image that doesn't include them?

Thanks in advance,
Damian.

What software would you like us to add to our image catalog? (one per issue please)

If I run the nginx image as unprivileged:

docker run -v $(pwd)/examples/hello-world/site-content:/var/lib/nginx/html -p 8080:8080 -u 1000 cgr.dev/chainguard/nginx

I'm getting this error because of the -u 1000:

nginx: [alert] could not open error log file: open() "/var/lib/nginx/logs/error.log" failed (13: Permission denied)
2022/12/20 14:14:42 [emerg] 8#8: mkdir() "/var/lib/nginx/tmp/client_body" failed (13: Permission denied)

Also, running this nginx container on port 8080 doesn't work, without any error (-p 8080:8080).

Is it possible to support the unprivilged setup of nginx like illustrated here: https://github.com/nginxinc/docker-nginx-unprivileged/?

which versions of the containerized software do you need?

No response

Add some justification for why this specific image and versions are important.

Adoption of this image if unprivileged containers are a requirement.

everything in there should eventually go away, but certain things are an artifact from missed stuff todays migration (e.g. gcc-glibc)

others like php, nginx, etc we should keep until migrated

The following images are currently failing this due to bad results etc:

• jenkins latest
• maven openjdk-17
• maven openjdk-11
• ruby latest-3.1
• ruby latest-3.0

We need a wolfi (glibc) build for this image.

Follow up issue from #32

The following images have not been migrated since we are waiting for wolfi packages:

• nginx
• php

Probably named something like cgr.dev/chainguard/node:runtime

Background: The official Docker image for node (https://hub.docker.com/_/node) contains both node and npm in the image. Both Docker's and Node's documentation recommend using this image, and our example is currently based on those examples.

In theory, npm shouldn't be needed at runtime though. In the classical multi-stage build scenario, users could have a build stage using an image containing node+npm, and a separate stage that COPYs files from the build stage that runs on an image that only contains node, and not npm.

I don't know if this isn't done in practice because it's fundamentally a bad idea for some reason, or just because the official Docker image and official docs recommend using the combined image.

Practically this will mean creating a nodejs Wolfi package that doesn't include npm (undoing wolfi-dev/os#56), and a separate npm-only Wolfi package. The current cgr.dev/chainguard/node image will include both, and chainguard/node:runtime will only include nodejs.

To make it easier for people to switch to this image from the nginx image it would be great if this core feature could be supported.

https://marcofranssen.nl/nginx-1-19-supports-environment-variables-and-templates-in-docker

This eases kubernetes deployments by using a configmap for nginx config templates. In those templates you can also make use of environment variables which are useful to inject certain variables into the template like secrets or other more dynamic aspects.

Also see https://hub.docker.com/_/nginx

#-----------------------STAGE 1------------------------------------
FROM python:3.10.7-slim-buster as build_image

RUN apt-get update && apt-get -y upgrade && \
    apt-get install -y gcc

#-----------------------STAGE 2-----------------------------------
FROM cgr.dev/chainguard/python:latest

COPY --from=build_image /usr/bin/gcc /usr/bin/gcc

ENTRYPOINT ["gcc", "--help"]

I build a docker image with the above Dockerfile and I'm getting the below mentioned error when I run that docker image

exec /usr/bin/gcc: no such file or directory

The file is copied successfully, I checked with dive tool for the layer change. Please refer the below image

Sorry if this is a silly mistake but can you guys help ?. I couldn't execute any binary files I copy. I tested this same method with google's distroless image, It works fine and I get the help menu.

NOTE : Why I'm using python image is, I actually tried to execute uwsgi binary for running python flask. But I mentioned gcc --help for simple POC

We are currently pushing with apko, signing, then running smoketest. But if test is failing, we still have an image out there that might not work. It should be caught as part of CI, but probably best to run on main too

More information and links on the TCK can be found here https://foojay.io/pedia/tck/

The above article mentions the TCK is not open source and looks like we would need to request and sign the OpenJDK Community TCK License Agreement (OCTLA).

disabling as required for now

currently PRs can merge just if generate-matrix passes. since the matrix is dynamic, we cannot put branch protection on for individual build jobs. needs a job that waits until all are done (pass or fail) and then block on that

At the moment we are setting timestamps of images to the build date.

This causes problems for tooling like digestabot which sees there is a new image, even though nothing has really changed.

To avoid this, we could:

1. Build a daily variant with SOURCE_DATE_EPOCH=0 which will set all timestamps to the Unix epoch
2. Check if this image differs from the previous day's image
   2.1) If yes, then something has changed. Build a new image with SOURCE_DATE_EPOCH set to today, which should be tagged "latest" and used as the default version
   2.2) If no, there's nothing to update

There is an argument that the default image should set all timestamps to the Epoch, which is simpler and easier to control/check. I'm currently against this:

• it can cause problems with tooling which thinks things are hugely out-of-date (e.g. blog software setting modified date on web pages)
• it confuses new users who don't understand why the image appears 52 years old (yes, this is partly due to arguably bad choices by docker images)
• we want our images to immediately appear fresh
• the date something last changed is useful information

We may revisit this decision when reproducibility becomes mainstream (which I think it will).

Modify image.yaml / monopod to add a top-level key status: <status> (string), then reflect this in a column on the readme

The current action takes in ghcr.io as an input:

    # Scan (only working for GHCR/latest images for now)
    - uses: chainguard-images/actions/vul-scans@main
      id: scans
      # TODO: support for multiple tags in inputs.apkoAdditionalTags
      if: startsWith(inputs.apkoBaseTag, 'ghcr.io/') && inputs.apkoAdditionalTags == 'latest'
      with:
        registry: ghcr.io
        image: ${{ inputs.apkoBaseTag }}
        RUN_SNYK: 'false'
        RUN_GRYPE: 'true'
        DOCKER_LOGIN: 'true'
    

** These images are using the "experimental" tag as the primary tag
*** The go image is in strange state. Wolfi-based image is being pushed as latest, but was previously multiarch/Alpine-based.

Something related to SBOM generation:

Error: failed to build package: writing SBOMs: reading SBOM file inventory: hashing SHA1 file /root/.cache/go-build/dc/dca84019db60970cab6d849f1fd6866b344de14a17bdefc7b87bbcb11f133738-d: open file /tmp/melange-workspace-3249393493/melange-out/sdk/root/.cache/go-build/dc/dca84019db60970cab6d849f1fd6866b344de14a17bdefc7b87bbcb11f133738-d: open /tmp/melange-workspace-3249393493/melange-out/sdk/root/.cache/go-build/dc/dca84019db60970cab6d849f1fd6866b344de14a17bdefc7b87bbcb11f133738-d: too many open files

This image saves a Go cache which may be a lot of files. One solution is to exclude those, but it does appear to be a type of bug in apko

See https://alexharv074.github.io/puppet/2017/10/04/merge-a-git-repository-and-its-history-into-a-subdirectory-of-a-second-git-repository.html

• alpine-base
• apko
• busybox
• gcc-glibc
• gcc-musl
• git
• glibc-dynamic
• go
• hello-world
• jdk
• ko
• melange
• musl-dynamic
• nginx
• node
• php
• postgres
• python
• ruby
• sdk
• static
• wolfi-base

Add USAGE.md with an example of how to use this image.

Shields allows using a base64 data image

?logo=data:image/png;base64,…	Insert custom logo image (≥ 14px high). There is a limit on the total size of request headers we can accept (8192 bytes). From a practical perspective, this means the base64-encoded image text is limited to somewhere slightly under 8192 bytes depending on the rest of the request header.

if we can get alpine and wolfi logos in this format, we can add to the badges

Apologies if this has been covered elsewhere but I don't see and logic for handling multiple versions of components such as the JDK, Node.js, .NET (when it arrives), or Ruby (when it arrives), etc? All of these components have overlapping LTS lifecycles where it's highly likely that multiple versions are going to be needed at the same time.

I've used all of the following patterns at some point and I don't think there is a categoric right answer, but IMHO there needs to be a consistent and well thought out one.

• Use a repo per image version e.g. jdk17 & jdk11
  • Simplest solution
• Use a primary repo e.g. jdk and fork for LTS support e.g. jdk -> jdk11
  • Consistent with current behaviour
• Use single repo for all versions e.g. jdk
  • All logic in one place

It might be useful to create a psql client only image that users can use to query a postgres server container.

We'd need to test what the minimal number of packages needed to handle this but it may be

    - ca-certificates-bundle
    - postgresql-client

So we could have a second apko-client.yaml with these packages.

A good test would be to start a container with the postgres service exposing the port 5432 and start a second container with the client and attempt to connect using the hostname, port and postgres server credentials.

what do you guys think?

This image still uses Alpine as base. We should migrate it to use Wolfi. There have been a few blockers to execute this migration, so I will track the progress in this issue.

#96

please ignore

The GCT distroless project has root and nonroot variants of the static image.

Whilst I think nonroot should remain the default (unlike GCT distroless, which can be a breaking change for migrating users), we may want to consider adding a variant with the user set to root e.g. cgr.dev/chainguard/static:latest-root and a nonroot for symmetry cgr.dev/chainguard/static:latest-root.

Need to explain what apko is, link to tutorial, show apko.yaml.

What software would you like us to add to our image catalog? (one per issue please)

haproxy

which versions of the containerized software do you need?

2.6.7 (latest lts release)

Add some justification for why this specific image and versions are important.

This is a high performance reverse proxy which are commonly internet facing and would be great with a fast and high security base image like wolfi

• alpine-base (Alpine exception) @puerco #52
• apko @jdolitsky #50
• busybox @luhring
• gcc-glibc @jdolitsky
• gcc-musl (Alpine) @kaniini #41
• git @kaniini #42
• glibc-dynamic @jdolitsky
• go (team activity) - #34
• hello-world
• jdk (drop since we have wolfi)
• ko (@cpanato) (Alpine exception) - #33
• melange (still need alpine version) @jdolitsky #51
• musl-dynamic (@cpanato) (Alpine exception) - #35
• nginx (needs to have wolfi pkg)
• node @imjasonh #36
• php (needs to have wolfi pkg)
• postgres (drop since we have wolfi)
• python @luhring (see here)
• ruby @imjasonh #37
• sdk @jdolitsky (wolfi is done, add alpine) #44
• static (still alpine) @kaniini #38
• wolfi-base @puerco #39

Create a .net image. See https://twitter.com/sbs0x/status/1573359024598405122

Consider please also having a flavor/variant of this image which contains only the JRE (runtime environment), not the whole big JDK.
The image will be much smaller.

E.g. https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.4.1%2B1/OpenJDK17U-jre_x64_alpine-linux_hotspot_17.0.4.1_1.tar.gz

In the case that the attestation from vuln scans fail, give this image less change to fail some policy. So scan in order of how the imnage would be used/checked:

• index
• amd64
• arm64
• (others)

Once ready we should use the distroless build images.

see #16 (comment)

bazel and jenkins are currently marked experimental, but we hav since added other images like kubectl which went straight to latest. Should we just latest everything?

cc @rawlingsj

Hi,

I am using the cgr.dev/chainguard/static:latest in my multi-stage Dockerfile after I build a golang application.

When I try to run the finished image (the docker build runs without an error), I get following error message:

exec /golang-server: no such file or directory

If I change the FROM to alpine:latest, everything works as expected. No other changes in the code or Dockerfile.

Here is the content of my Dockefile.

# syntax=docker/dockerfile:1
FROM cgr.dev/chainguard/go:1.19.3 AS build

WORKDIR /app

COPY go.mod ./
COPY go.sum ./
RUN go mod download
COPY *.go ./
RUN go build -o /golang-server



#FROM alpine:latest
#COPY --from=build /golang-server /golang-server
#EXPOSE 8080
#CMD ["/golang-server"]


FROM cgr.dev/chainguard/static:latest
COPY --from=build /golang-server /golang-server
EXPOSE 8080
CMD ["/golang-server"]

The "server" logic is in this repository: https://github.com/dirien/hello-server.git

If the build fails, we are able to mint the badge, but it never gets placed into the GCS bucket

if an image folder has multiple melange configs, how should we config?

Feels a bit selfish to ask for a go 1.18 version, and was looking into building my own image.

But then I noticed that Apko itself is currently built with go 1.18. Would it be possible to have a 1.18 tagged version? (We are considering upgrading soon, but there is a very minor issue that 1.19 now has an extra OmitHost bool field in the url.URL payload).

Go version 1.18 wil continue to be supported until the 1.20 release, likely around February 2023. Please close this issue if there is any good reason that go version 1.18.6 is not supported.

We are ending up with "latest" tags missing .att attestations (vuln scans), since they are pushed by apko-snapshot prior to running the scans.