profile
viewpoint
jonjohnsonjr Never offended by friendly pings

GoogleContainerTools/distroless 11339

🥑 Language focused docker images, minus the operating system.

GoogleContainerTools/kaniko 9362

Build Container Images In Kubernetes

google/git-appraise 4260

Distributed code review system for Git repos

google/ko 3605

Build and deploy Go applications on Kubernetes

google/go-containerregistry 1374

Go library and CLIs for working with container registries

google/crfs 1190

CRFS: Container Registry Filesystem

GoogleCloudPlatform/docker-credential-gcr 212

A Docker credential helper for GCR users

google/git-appraise-web 173

Web UI for git-appraise

google/todo-tracks 158

Web dashboard for tracking the TODOs in a Git repo

ahmetb/rundev 29

(alpha, contact me if you’re using)

IssuesEvent
PullRequestReviewEvent

issue commentgoogle/ko

Support for generated files

I'm liking this pattern of skaffold supporting use cases that feel inappropriate for ko ❤️

fsaintjacques

comment created time in 2 hours

pull request commentgoogle/go-containerregistry

remote: disable http2 for transports by default

FWIW this seems like a reasonable hack to work around this:

But, exporting GODEBUG=http2client=0 fixes the issue.

steved

comment created time in 2 hours

issue commentgoogle/go-containerregistry

Slow uploads to quay.io

Sounds a lot like https://github.com/google/go-containerregistry/pull/799

akshaymankar

comment created time in 2 hours

PullRequestReviewEvent

Pull request review commentgoogle/ko

Enable talking to tunneled registries via KO_DOCKER_REPO_HOST

 func AddPublishArg(cmd *cobra.Command, po *PublishOptions) { 	if dockerRepo, exists := os.LookupEnv("KO_DOCKER_REPO"); exists { 		po.DockerRepo = dockerRepo 	}+	if dockerRepoHost, exists := os.LookupEnv("KO_DOCKER_REPO_HOST"); exists {

KO_DOCKER_REPO_HOST doesn't feel like the right name for this, but I don't think I understand this well enough to suggest a better name.

markusthoemmes

comment created time in 2 hours

issue commentgoogle/go-containerregistry

Support crane push tarBall contains more than one image?

I don't understand that why function remote.MultiWrite says that all refs must share the same repository. I can not understand it...

It's a limitation of the current implementation. Currently, we assume all the operations happen within a single repository because authentication is scoped to a single repository. We don't have any way to track requests and auth across multiple repositories (currently). This could easily be fixed.

dashjay

comment created time in 2 hours

issue commentopencontainers/distribution-spec

Streamed Blob Upload not defined by spec

This seems ubiquitous enough that it should probably be documented?

ttymck

comment created time in 2 hours

PullRequestReviewEvent

Pull request review commentgoogle/ko

Add support for writing SBOMs when the `build.Result` is `oci.Signed*`.

 func (g *gobuild) buildOne(ctx context.Context, refStr string, base v1.Image, pl  	empty := v1.Time{} 	if g.creationTime != empty {-		return mutate.CreatedAt(image, g.creationTime)+		image, err = mutate.CreatedAt(image, g.creationTime)+		if err != nil {+			return nil, err+		}+	}++	si := signed.Image(image)++	if !g.disableSBOM {

I'd flip disableSBOM around to avoid the double negative here.

mattmoor

comment created time in 9 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentopencontainers/tob

Proposal: working group for reference types

+# Working Group Proposal: Reference Types++Proposal created from [OCI WG template](https://github.com/opencontainers/tob/blob/master/WG-TEMPLATE.md).++Proposal copied from [Proposal: Working Group for Reference Types #96](https://github.com/opencontainers/tob/issues/96)++## Reference Types OCI Working Group - Governance Charter++This document describes the basic governance principles for the Reference Types Working Group (the “WG”).++The WG operates as an OCI Working Group under the [Open Container Initiative (OCI) Charter](https://github.com/opencontainers/tob/blob/master/CHARTER.md), which describes the responsibilities of the OCI Technical Oversight Board (the "TOB”). The WG is established by the TOB as an OCI Working Group pursuant to the OCI Charter. Accordingly, the WG will operate in accordance with the OCI Charter and OCI's other policies and procedures, supplemented by the details below.++## Purpose++As cloud native development continues to grow, there is increased interest in evolving registries to natively store, discover, and pull a graph of content associated with specific container images in a registry. Use cases for said associated artifacts include but are not limited to Software Bill of Materials (SBoM), security scan results, and signing. Having a native way to store and discover artifacts associated with other artifacts enables end-users to answer the question of: “What SBOMs or signatures are associated with this container image?”++## Scope++* Define and deliver the capability to store, discover, and pull a graph of artifacts associated with a specific artifacts to OCI distribution compliant registries. These set of capabilities has been commonly known as "reference types" or "references".+  * Define supported use cases+  * Document impact to existing user-facing tools and registries+  * Define the method for creating, distributing, and discovering referenced objects+  * Document user expectations for promoting an artifact between registries with its references+  * Document onboarding process for registries and user-facing tools to adopt reference types+  * Defined expectations for artifact reference lifecycle management+  * Deliver a reference implementation of the reference types proposal++## Out of Scope++* Identified out of scope items will be listed here as WG progresses+++## Intended work product++* Referrers API specification that provides the ability to discover references to existing container images. These include listing signatures, SBoMs, security scan results that refer to the digest of a manifest. The referrers API specification will sit within or along side the Distribution specification.+* Identify, and document the pros and cons for versioning the existing manifests, compared with creating a new manifest to support reference types.++## Proposed Owners+* Lachlan Evenson (@lachie83)+* Justin Cormack (@justincormack)+* Michael Brown (@michaelb990)+* Derek McGowan (@dmcgowan)+* Jon Johnson (@jonjohnsonjr)++## Sponsors++* Microsoft+* AWS+* Docker+

There's also an open clarification regarding the set of sponsors being exclusively corporations: https://github.com/opencontainers/tob/issues/96#issuecomment-965897973

The only mention of sponsorship in the WG requirements I can find says:

a list of OCI Projects, non-OCI projects, or organizations sponsoring the working group and participating in the implementation and use case validation of the work done by the group

I can't speak on behalf of Google as a whole, and I expect anyone who can would want a much more formal definition of sponsorship. I'm happy for the vote to proceed without Google as a sponsor, but I'm not happy with the current list of sponsors. I'd expect to see sponsorship from oras, notation, cosign, harbor, distribution, quay, distribution-spec, image-spec, etc. -- not just companies.

SteveLasker

comment created time in 11 days

PullRequestReviewEvent

pull request commentgoogle/go-containerregistry

Windowsify layers when `crane append`ing

Now I have been running mutate to change the entrypoint to be set to the command and that actually fails.

How is it failing?

imjasonh

comment created time in 11 days

issue commentgoogle/go-containerregistry

daemon.Image doesn't return an error if the image isn't in the daemon

Well that's annoying. Maybe we should send a cheap request to make sure it exists (e.g. access the image ID)?

sharifelgamal

comment created time in 12 days

PullRequestReviewEvent

issue commentgoogle/go-containerregistry

Crane Login auth failing

This issue also highlights a need for better tagging for :debug images, so debug users can downgrade. I'll open a separate issue for that.

$ crane ls gcr.io/go-containerregistry/crane/debug | tail
f0ce2270b3b4dd83f214d1660e11d10fe73296f3
f30efdd9b874ae20d38892316d1c68fc5c2b041e
f337ecf430c03d614d622b7e71808fa81b050373
f9a1886f3df0e2b00d6c62715114fe1093ab1ad7
fbb5e78799eda8b37c6c624c2c496a9ad49582d9
latest
v0.5.0
v0.5.1
v0.6.0
v0.7.0
tbuchier

comment created time in 12 days

issue commentgoogle/go-containerregistry

Question: remote.Catalog lists all repos from all GCR projects and organizations

The problem is that despite the fact that I have performed an explicit gcloud config set project to a specific project, invocation of the above program will list ALL repos of ALL organizations and ALL projects my gcloud has access to.

Yeah this is awful and a problem with how the catalog API is implemented.

Is there a way to limit the code above so that it lists the gcr repos of a specific org/project?

google.List and google.Walk expose the response that GCR returns, which includes some extensions to the distribution API.

The google.Tags response contains Children, which are basically subdirectories for your repository.

I'd use gcrane ls as an example for how you might want to use this: https://github.com/google/go-containerregistry/blob/c90c44474acce673c0719a67e0f45a85f3dff157/cmd/gcrane/cmd/list.go#L57-L94

pantelis-karamolegkos

comment created time in 13 days

Pull request review commentsigstore/cosign

Add layout package for writing and loading signatures from disk

 import (  // WriteSignedImage writes the image and all related signatures, attestations and attachments func WriteSignedImage(path string, si oci.SignedImage) error {-	// First, write the image-	if err := write(path, imagePath, si); err != nil {-		return errors.Wrap(err, "writing image")+	// First, write an empty index+	layoutPath, err := layout.Write(path, empty.Index)+	if err != nil {+		return err+	}+	// write the image+	if err := appendImage(layoutPath, si, imageAnnotation); err != nil {+		return errors.Wrap(err, "appending signed image") 	}+	// write the signatures 	sigs, err := si.Signatures() 	if err != nil { 		return errors.Wrap(err, "getting signatures") 	}-	if err := write(path, signaturesPath, sigs); err != nil {-		return errors.Wrap(err, "writing signatures")+	if err := appendImage(layoutPath, sigs, sigsAnnotation); err != nil {

Generally clients take the first entry that matches their criteria (platform).

This might be a reasonable knob to expose when pushing to a registry? By default, just push all the entries in index.json, but optionally include that index.json as a top-level index for everything related to the artifact. I don't know how this is intended to be used.

priyawadhwa

comment created time in 13 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

pull request commentgoogle/go-containerregistry

Check for Podman's auth.json in DefaultKeychain

This may result in a subtle behavior change for users who have auth configured in both locations. Before this change, the Podman config would be ignored completely; after this change, it will be preferred over Docker's preferred location.

I think for this reason I'd prefer falling back to podman config rather than falling back to docker config. Any reason to do this order?

imjasonh

comment created time in 13 days

issue commentgoogle/ko

Consider not adding `-trimpath` flag by default when disabling compiler optimizations

Skaffold doesn't use these flags, right? I'd be ok with exposing the -trimpath functionality as a build.Option.

I don't know if we want to drop DisableOptimizations and just lump this and trimpath into a single option that appends to config.Flags or just add a TrimPath option that defaults to true...

halvards

comment created time in 13 days

issue commentgoogle/ko

Support for generated files

GoRelease supports the pre/post hooks, are you open to a patch?

I think the ideal end-state is that make it possible (or the default) to support everything goreleaser does. Right now, it's unclear to me what kind of relationship makes the most sense between the projects. I don't think it make sense to just vendor all of goreleaser or reimplement everything, but there may be some way to make this more pluggable...

fsaintjacques

comment created time in 14 days

more