profile
viewpoint
Radu M radu-matei @microsoft @azure San Francisco, CA https://radu-matei.com/ @kubernetes, containers and cloud native open-source developer tools for distributed systems. Software Engineer @microsoft @Azure.

grpc/grpc-web 4221

gRPC for Web Clients

Azure/draft 3894

A tool for developers to create cloud-native applications on Kubernetes.

brigadecore/brigade 1936

Event-based Scripting for Kubernetes.

brigadecore/kashti 342

Kashti is a dashboard for your Brigade pipelines.

engineerd/setup-kind 92

kind (Kubernetes in Docker) GitHub Action

engineerd/kube-exec 78

Lightweight Golang package for executing commands in remote Kubernetes pods

cnabio/cnab-to-oci 34

Tool to convert CNAB bundle.json to OCI index

cnabio/cnab-go 28

A Go implementation of CNAB Core 1.0

deislabs/cnab-workshop 12

CNAB / Duffle workshop for KubeCon Seattle 2018

microsoft-dx/csharp-fundamentals 11

C# Fundamentals - Code Samples for introducing C# and OOP

push eventradu-matei/wasm-wasi-api

Radu M

commit sha b31b25125236b2b1c4343d9e5ce5d14793084282

Use a linker to provide WASI imports Signed-off-by: Radu M <root@radu.sh>

view details

push time in 3 days

push eventradu-matei/krustlet

Radu M

commit sha 8fd2cb5eb3be65c926eb2cd409ba12d90076daf7

Update setup-kind GitHub Action Update configurator GitHub Action Signed-off-by: Radu M <root@radu.sh>

view details

push time in 4 days

created tagengineerd/configurator

tagv0.0.2

Cross-platform GitHub Action to download, extract, and add to path statically compiled tools

created time in 4 days

release engineerd/configurator

v0.0.2

released time in 4 days

create barnchengineerd/configurator

branch : v0.0.2

created branch time in 4 days

create barnchradu-matei/configurator

branch : v0.0.2

created branch time in 4 days

delete branch radu-matei/configurator

delete branch : update-actions-toolkit

delete time in 4 days

push eventengineerd/configurator

Radu M

commit sha 216026ec9c01e9c7e4a38e099d0b5ac799c87a7f

Bump @actions/* package versions Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha 25d4686136f22db454ac9b3423a59b48beb8b201

Merge pull request #8 from radu-matei/update-actions-toolkit

view details

push time in 4 days

create barnchradu-matei/configurator

branch : update-actions-toolkit

created branch time in 4 days

PR opened deislabs/krustlet

Update setup-kind GitHub Action

This PR updates @engineerd/setup-kind to the latest version because of a change in the underlying worker infrastructure.

+1 -1

0 comment

1 changed file

pr created time in 4 days

create barnchradu-matei/krustlet

branch : update-setup-kind

created branch time in 4 days

push eventengineerd/setup-kind

Radu M

commit sha c4d560a45d8fac0f83c37e57c48cbf33c821971f

Bump @actions/* package versions Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha ab7b8b6f2dfaf7e2bdce5020c1d6b399ff789635

Update version in readme and package.json Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha d0374c8d87edaf699660917b48fe1625a596a521

Merge pull request #22 from engineerd/fix-exdev-cross-device-link

view details

push time in 4 days

PR merged engineerd/setup-kind

Fix bug in cross-mount renaming

closes #21

Signed-off-by: Radu M root@radu.sh

+39 -45

0 comment

4 changed files

radu-matei

pr closed time in 4 days

issue closedengineerd/setup-kind

bug: EXDEV: cross-device link not permitted when moving the Kind binary

with:
    version: v0.7.0
    name: kind
    wait: 300s
    skipClusterCreation: false
  env:
    GOROOT: /opt/hostedtoolcache/go/1.13.11/x64
downloading kind from https://github.com/kubernetes-sigs/kind/releases/download/v0.7.0/kind-linux-amd64
chmod +x /home/runner/work/_temp/174cfcc2-60fa-4457-beaa-ccc15123e9e8
##[error]EXDEV: cross-device link not permitted, rename '/home/runner/work/_temp/174cfcc2-60fa-4457-beaa-ccc15123e9e8' -> '/home/runner/bin/kind'

https://github.com/crossplane/addon-oam-kubernetes-local/runs/697514545?check_suite_focus=true

closed time in 4 days

ryanzhang-oss

issue commentengineerd/setup-kind

bug: EXDEV: cross-device link not permitted when moving the Kind binary

@ryanzhang-oss - I created a new release with a fix for this - https://github.com/engineerd/setup-kind/releases/tag/v0.4.0

Thanks again for reporting!

ryanzhang-oss

comment created time in 4 days

push eventengineerd/setup-kind

Radu M

commit sha ab7b8b6f2dfaf7e2bdce5020c1d6b399ff789635

Update version in readme and package.json Signed-off-by: Radu M <root@radu.sh>

view details

push time in 4 days

created tagengineerd/setup-kind

tagv0.4.0

kind (Kubernetes in Docker) GitHub Action

created time in 4 days

release engineerd/setup-kind

v0.4.0

released time in 4 days

push eventengineerd/setup-kind

Radu M

commit sha 4e17476a3712a9f6a6d99f9e1729b6cf7dbba86d

Update version in readme and package.json Signed-off-by: Radu M <root@radu.sh>

view details

push time in 4 days

create barnchengineerd/setup-kind

branch : v0.4.0

created branch time in 4 days

PR opened engineerd/setup-kind

WIP: Fix bug in cross-mount renaming

closes #21

Signed-off-by: Radu M root@radu.sh

+35 -41

0 comment

3 changed files

pr created time in 4 days

create barnchengineerd/setup-kind

branch : fix-exdev-cross-device-link

created branch time in 4 days

issue commentengineerd/setup-kind

The plug-in seems to be break

Thanks a lot for reporting! I can confirm that this seems to be currently broken, I suspect because of a change in how the GitHub worker is set up.

I am actively working on this, and hope to have a release soon. Thanks!

ryanzhang-oss

comment created time in 4 days

push eventcnabio/cnab-go

Radu M

commit sha 246bfca30074cbf1d1ebe93c338bac6272e1c444

Fix linter settings and errors Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha c0e7d7739405baddc711bc2c9aab222a778460ac

Merge pull request #208 from radu-matei/fix-linter Fix linter settings and errors

view details

push time in 6 days

PR merged cnabio/cnab-go

Fix linter settings and errors

The goimports settings in the linter options were wrong, meaning goimports was not running properly.

This PR fixes that, as well as the linter errors.

+58 -39

2 comments

21 changed files

radu-matei

pr closed time in 6 days

push eventcnabio/cnab-spec

Trishank Karthik Kuppusamy

commit sha 022db6da65583631582160657019cc4d56606757

fix references to example bundle in 301 Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank Karthik Kuppusamy

commit sha e97d188c8834bf93b79feb114819fc4a398c781b

clarify in-toto verifications+inspections Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank Karthik Kuppusamy

commit sha 09eeb592054b4517b7bf5f65f03d6da55f65c98d

clarify a bit more Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Radu M

commit sha 7859fd10d4c85f51a2b043da1b45174a4bd60972

Merge pull request #364 from trishankatdatadog/trishankatdatadog/add-in-toto-verification-image

view details

push time in 6 days

delete branch radu-matei/cnab-spec

delete branch : 304-implementations

delete time in 6 days

push eventcnabio/cnab-spec

Radu M

commit sha 70ab70b7073443f8c5abb6b43c027f7ad3d0c17b

Add initial version of 304-known-implementations of the security spec Apply review feedback Update 304 known implementations Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha 280bd5ebd4e57d7fb97e91e4ef006a32821753ac

Merge pull request #288 from radu-matei/304-implementations

view details

push time in 6 days

PR merged cnabio/cnab-spec

CNAB Security 304: Known implementations

depends on #280

+123 -0

9 comments

1 changed file

radu-matei

pr closed time in 6 days

Pull request review commentcnabio/cnab-spec

CNAB Security 304: Known implementations

+---+title: CNAB Security: Known implementations+weight: 304+---++The security implementation prescribes the structure and format that trust metadata SHOULD follow, but _not_ which specific implementations should be used. This document presents known implementations of the CNAB security specification, and as more projects implement the specification, they will be added here.++### [Signy][signy]++[Signy][signy] is a project built to validate the feasability of integrating the [CNAB registry][cnab-reg] and CNAB security specifications by demonstrating the complete sign-push-verify workflow.++The current document is based on [v0.0.3][signy-release] of Signy, which:

Thanks for pointing it out, just released the tag.

radu-matei

comment created time in 6 days

created tagcnabio/signy

tag0.0.3

Go implementation for CNAB content trust verification using TUF, Notary, and in-toto

created time in 6 days

release cnabio/signy

0.0.3

released time in 6 days

pull request commentcnabio/cnab-go

Fix linter settings and errors

Rebased, but for some reason the build is not triggering..

radu-matei

comment created time in 6 days

push eventradu-matei/cnab-go

Carolyn Van Slyck

commit sha 7774b93b5f103d65fda1525ab7907b9b92097df0

Use GoTool task Azure Devops moved where new versions of go (1.11+) are installed and no longer recommends using the scripts we had for setting up go. They have a Task that they want you to use to pick the exact version of go you want and then use it to go get your code. Signed-off-by: Carolyn Van Slyck <carolyn.vanslyck@microsoft.com>

view details

Carolyn Van Slyck

commit sha 958fc3a29c2ea97af6bc6e89bd466142dcfba028

Merge pull request #209 from carolynvs/wth-build Use GoTool Task

view details

Radu M

commit sha 246bfca30074cbf1d1ebe93c338bac6272e1c444

Fix linter settings and errors Signed-off-by: Radu M <root@radu.sh>

view details

push time in 6 days

delete branch radu-matei/wasm-to-oci

delete branch : fix-linter

delete time in 7 days

push eventengineerd/wasm-to-oci

Radu M

commit sha 88ec37cd9fb95cd619192de7cafb8d67496cf541

Fix linter settings and errors Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha fcc8426e52e5b5a77fa96fcb245cdcadc1fb36c2

Merge pull request #11 from radu-matei/fix-linter

view details

push time in 7 days

PR merged engineerd/wasm-to-oci

Fix linter settings and errors

The goimports settings in the linter options were wrong, meaning goimports was not running properly.

This PR fixes that, as well as the linter error in cmd/pull.go.

Signed-off-by: Radu M root@radu.sh

+3 -2

0 comment

2 changed files

radu-matei

pr closed time in 7 days

create barnchradu-matei/wasm-wasi-api

branch : master

created branch time in 7 days

created repositoryradu-matei/wasm-wasi-api

created time in 7 days

Pull request review commentdeislabs/krustlet

fix(*): Makes crate publish happen on tags

 edition = "2018" license-file = "../../LICENSE" description = "A Kubernetes kubelet implementation in Rust" repository = "https://github.com/deislabs/krustlet"-readme = "README.md"

#232 introduced this field in other crates as well - should it be removed from there too?

thomastaylor312

comment created time in 7 days

PR opened cnabio/cnab-go

Fix linter settings and errors

The goimports settings in the linter options were wrong, meaning goimports was not running properly.

This PR fixes that, as well as the linter errors.

+58 -39

0 comment

21 changed files

pr created time in 7 days

create barnchradu-matei/cnab-go

branch : fix-linter

created branch time in 7 days

PR opened cnabio/signy

Fix linter settings and errors

The goimports setting in the linter options were wrong, meaning goimports was not running properly.

This PR fixes that, as well as the linter error in cmd/pull.go.

+14 -12

0 comment

3 changed files

pr created time in 7 days

create barnchradu-matei/signy

branch : fix-linter

created branch time in 7 days

PR opened engineerd/wasm-to-oci

Fix linter settings and errors

The goimports setting in the linter options was wrong, meaning goimports was not running properly.

This PR fixes that, as well as the linter error in cmd/pull.go.

Signed-off-by: Radu M root@radu.sh

+3 -2

0 comment

2 changed files

pr created time in 7 days

create barnchradu-matei/wasm-to-oci

branch : fix-linter

created branch time in 7 days

delete branch radu-matei/wasm-to-oci

delete branch : update-readme-registries

delete time in 7 days

push eventengineerd/wasm-to-oci

Radu M

commit sha 0a979286a88a9eb7a5e88982b0cc2f31b9e46e0b

Update readme with more usable registries and login note Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha 7b17685f7dd7e7845ffc02eb2320a5927507609b

Merge pull request #10 from radu-matei/update-readme-registries

view details

push time in 7 days

PR merged engineerd/wasm-to-oci

Update readme with more usable registries and login note

This PR updates the readme to point out GCR and Harbor support, and note the login step.

closes #9

Signed-off-by: Radu M root@radu.sh

+13 -6

0 comment

1 changed file

radu-matei

pr closed time in 7 days

issue closedengineerd/wasm-to-oci

Google Container Registry

I found this solution via DeisLabs' Krustlet

I'd like to use Google Container Registry (GCR) with wasm-to-oci but I'm struggling with the auth (pass-through to ORAS).

GCR supports OCI and, using ORAS, I'm able:

  • authenticate using a (Google) access token (and demonstrate that GCR support OCI containers).
  • push|pull images to a GCR repo.
REGISTRY="gcr.io"

gcloud auth print-access-token \
| oras login -u oauth2accesstoken --password-stdin https://${REGISTRY}

more ./artifact.txt 
Hello Freddie!

oras push gcr.io/${PROJECT}/hello-artifact:v1 ./artifact.txt
Uploading 0060e7e892de artifact.txt
Pushed gcr.io/${PROJECT}/hello-artifact:v1
Digest: sha256:c330be5cf8bbc34f87db380aaba72e774d7ee1064085b3e2ec2b071be292e2a2

rm artifact.txt 

oras pull gcr.io/${PROJECT}/hello-artifact:v1
Downloaded 0060e7e892de artifact.txt
Pulled gcr.io/${PROJECT}/hello-artifact:v1
Digest: sha256:c330be5cf8bbc34f87db380aaba72e774d7ee1064085b3e2ec2b071be292e2a2

cat ./artifact.txt 
Hello Freddie!

If I could understand how to reflect this authentication using wasm-to-oci, I think GCR could be added to your list of supported registries.

closed time in 7 days

DazWilkin

PR opened engineerd/wasm-to-oci

Update readme with more usable registries and login note

This PR updates the readme to point out GCR and Harbor support, and note the login step.

closes #9

Signed-off-by: Radu M root@radu.sh

+13 -6

0 comment

1 changed file

pr created time in 7 days

create barnchradu-matei/wasm-to-oci

branch : update-readme-registries

created branch time in 7 days

PR merged engineerd/cjson

Move rust-crypto to dev-dependencies

Thanks for cjson! This change helps with compiling to WASM targets.

+3 -1

0 comment

1 changed file

stoically

pr closed time in 7 days

push eventengineerd/cjson

stoically

commit sha 24a82d94e339e27a62434493869f3dce62c60e0d

Move rust-crypto to dev-dependencies

view details

Radu M

commit sha e98e5e664dd0043985eaa26ba46722fecaabd5de

Merge pull request #1 from stoically/master

view details

push time in 7 days

Pull request review commentbrigadecore/brigade-utils

feat(*): add npm release job

+import { Job } from "@brigadecore/brigadier";++export const npmReleaseImg = "brigadecore/npm-release:edge";++export class NPMReleaseJob extends Job {+  constructor(name: string, image?: string) {+    if (image == undefined) {+      image = npmReleaseImg;+    }+    super(name, image);++    let checkEnv = '\+      if [ -z "$NPM_TOKEN" ]; then \+        echo "NPM_TOKEN for npm release must be provided via job environment" && exit 1 ; \+      fi ; \+      if [ -z "$VERSION" ]; then \+        echo "VERSION for npm release must be provided via job environment" && exit 1 ; \+      fi ; '++    this.tasks = [+      checkEnv,+      "echo '//registry.npmjs.org/:_authToken=${NPM_TOKEN}' > .npmrc",+      "cat package.json | jq '.version |= \"${VERSION}\"' > package.json.tmp",+      "rm package.json",+      "mv package.json.tmp package.json",+      "npm publish"

I don't know exactly the behaviour of npm publish if the package fails to build - this is irrelevant in how we use this job, since we always build and test before publishing, but it might be worth investigating and adding a note in the readme for users.

vdice

comment created time in 8 days

Pull request review commentbrigadecore/brigade-utils

feat(*): add npm release job

+FROM node:12.16.2-alpine3.11++RUN apk add --no-cache jq

Should we just run the apk command to add jq as part of the job's tasks and not deal with another image that we have build, push, and version ourselves? What do you think?

vdice

comment created time in 8 days

Pull request review commentbrigadecore/brigade-utils

feat(*): add npm release job

+import { Job } from "@brigadecore/brigadier";++export const npmReleaseImg = "brigadecore/npm-release:edge";

Are we ok with always running the :edge tag?

vdice

comment created time in 8 days

PR closed brigadecore/brigade-utils

Add WIP NPM job

closes #22

+100 -0

2 comments

4 changed files

radu-matei

pr closed time in 8 days

pull request commentbrigadecore/brigade-utils

Add WIP NPM job

#45 supersedes this PR.

radu-matei

comment created time in 8 days

push eventbrigadecore/brigade-utils

Vaughn Dice

commit sha 7dd1f423cad0df243b6112a6b1fda017d0e8b6a5

fix(out/github.js): update github output files Signed-off-by: Vaughn Dice <vadice@microsoft.com>

view details

Vaughn Dice

commit sha aae5caf6d6028af15c0a4381a6dcf4ab753e0757

bump check-run image Signed-off-by: Vaughn Dice <vadice@microsoft.com>

view details

Radu M

commit sha 5e2718dc9e269475aee788bab94a1180445b3604

Merge pull request #46 from vdice/fix/github-updates

view details

push time in 8 days

PR merged brigadecore/brigade-utils

Reviewers
fix(out/github.js): update github output files
  • adds some github.js-related assets with updates in out but missing on master
  • bumps brigade-github-check-run image to use latest semver release tag
+3 -3

0 comment

3 changed files

vdice

pr closed time in 8 days

issue commentcnabio/cnab-spec

History section ordering

It is in chronological order. Is there anything specific we can help clarify?

paymog

comment created time in 8 days

pull request commentcnabio/cnab-go

Fix ULID generation

Oh wow.. So to recap, generating an ULID can panic, and the operation is not thread safe.

Thanks a lot for catching this, I think we can create a new release for this alone once we merge.

carolynvs

comment created time in 8 days

issue commentbrigadecore/brigade

Discussion: checking in vendored code (Node modules, Go vendor)

It has been almost one year since we initially started this conversation, and I think now it be a great time to re-open the discussion.

#1075 added support for Go modules, and I am not sure I follow still having a vendor directory. Additionally, the points node_modules not usually being checked-in in the Node ecosystem are still valid - and so now we are in a situation where both a Go and Node developer would be surprised to see the vendored code directories in the repository.

However, @krancour's points about the ease of having the directories when building everything in a containerized environment are also extremely on point and valid.

And so I believe the main question is - are the advantages gained by running in a container important enough to justify going against "established" practices in both Go and Node communities, and the friction that comes with building in a container (time and resources)?

Personally, I think not, and I would advocate for building on the host OS by default, but I would also like to understand what other maintainers and contributors think, and understand if this approach has improved the developer experience.

radu-matei

comment created time in 8 days

issue closedbrigadecore/brigade

Use Go modules

Now that Go module support has been merged into the upstream Kubernetes (1, 2), maybe we could discuss how to manage Brigade's vendor folder with Go modules.

closed time in 8 days

dgkanatsios

issue commentbrigadecore/brigade

Use Go modules

I believe this was added in #1075

dgkanatsios

comment created time in 8 days

issue commentengineerd/wasm-to-oci

Google Container Registry

Thanks a lot for the context, I appreciate taking the time!

I'll take the action item to open a PR to clarify the readme re - auth, as well as to update the list of supported registries - now both GCR and Harbor support OCI artifacts.

DazWilkin

comment created time in 12 days

issue commentengineerd/wasm-to-oci

Google Container Registry

@DazWilkin wasm-to-oci reuses the credentials from ~/.docker/config.json, so if you are logged in to a registry using any CLI tool (docker, oras, or gcloud), it should work.

Do you think adding an wasm-to-oci login command would be useful? I purposely tried to avoid that since it would just reimplement what those tools are doing, but I am open to suggestions.

DazWilkin

comment created time in 12 days

pull request commentcnabio/signy

Minimal example of a software supply chain

This is of course non-blocking for this PR - but is there anything used here (potentially in the securesystemslib wheel) that is not implemented in Go?

trishankatdatadog

comment created time in 12 days

pull request commentcnabio/signy

Minimal example of a software supply chain

This is excellent! I would assume we want to also add a document / update the readme before merging, right?

trishankatdatadog

comment created time in 12 days

Pull request review commentcnabio/signy

Minimal example of a software supply chain

+# Imports.++# 1st-party.+import os+import shutil++# 2nd-party.+from typing import Any, Dict, List++# 3rd-party.+from securesystemslib.interface import (+    generate_and_write_ed25519_keypair,+    import_ed25519_privatekey_from_file,+    import_ed25519_publickey_from_file,+)++# Constants.+# Where we use by default to store Notary private keys.+KEYSTORE_DIR = os.path.expanduser('~/.signy/private')

IIRC, Signy has a configurable config directory - do we want to keep the same convention?

trishankatdatadog

comment created time in 12 days

pull request commentcnabio/signy

Minimal example of a software supply chain

This is excellent! I would assume we want to also add a document / update the readme before merging, right?

trishankatdatadog

comment created time in 12 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

 import ( 	log "github.com/sirupsen/logrus" 	"github.com/theupdateframework/notary/client" +	"github.com/cnabio/cnab-go/bundle" 	"github.com/cnabio/signy/pkg/cnab" ) -// VerifyCNABTrust ensures the trust metadata for a given GUN matches the metadata of the pushed bundle-func VerifyCNABTrust(ref, trustServer, tlscacert, trustDir, timeout string) error {-	target, trustedSHA, err := GetTargetAndSHA(ref, trustServer, tlscacert, trustDir, timeout)-	if err != nil {-		return err-	}-	log.Infof("Pulled trust data for %v, with role %v - SHA256: %v", ref, target.Role, trustedSHA)--	log.Infof("Pulling bundle from registry: %v", ref)-	bun, err := cnab.Pull(ref)-	if err != nil {-		return fmt.Errorf("cannot pull bundle: %v", err)-	}-	buf, err := json.MarshalCanonical(bun)-	if err != nil {-		return err-	}--	err = verifyTargetSHAFromBytes(target, buf)-	if err == nil {-		log.Infof("The SHA sums are equal: %v\n", trustedSHA)-	}--	return err-}+// VerifyTrust ensures the trust metadata for a given GUN matches the metadata of the pushed bundle+func VerifyTrust(ref, localFile, trustServer, tlscacert, trustDir, timeout string) (*client.TargetWithRole, []byte, error) {+	var bun *bundle.Bundle+	var buf []byte -// VerifyFileTrust ensures the trust metadata for a given GUN matches the computed metadata of the local file-func VerifyFileTrust(ref, localFile, trustServer, tlscacert, trustDir, timeout string) error {

The reason these two methods were initially split was because I assumed at some point we will have slightly different processes for verifying a thin vs. thick bundles.

trishankatdatadog

comment created time in 12 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

 import ( 	log "github.com/sirupsen/logrus" 	"github.com/theupdateframework/notary/client" +	"github.com/cnabio/cnab-go/bundle" 	"github.com/cnabio/signy/pkg/cnab" ) -// VerifyCNABTrust ensures the trust metadata for a given GUN matches the metadata of the pushed bundle-func VerifyCNABTrust(ref, trustServer, tlscacert, trustDir, timeout string) error {-	target, trustedSHA, err := GetTargetAndSHA(ref, trustServer, tlscacert, trustDir, timeout)-	if err != nil {-		return err-	}-	log.Infof("Pulled trust data for %v, with role %v - SHA256: %v", ref, target.Role, trustedSHA)--	log.Infof("Pulling bundle from registry: %v", ref)-	bun, err := cnab.Pull(ref)-	if err != nil {-		return fmt.Errorf("cannot pull bundle: %v", err)-	}-	buf, err := json.MarshalCanonical(bun)-	if err != nil {-		return err-	}--	err = verifyTargetSHAFromBytes(target, buf)-	if err == nil {-		log.Infof("The SHA sums are equal: %v\n", trustedSHA)-	}--	return err-}+// VerifyTrust ensures the trust metadata for a given GUN matches the metadata of the pushed bundle+func VerifyTrust(ref, localFile, trustServer, tlscacert, trustDir, timeout string) (*client.TargetWithRole, []byte, error) {

This method was explicitly supposed to return an error so it would be consumed by clients who did not need to understand and use TUF objects - additionally, I would not expect a method called Verify* to return anything else other than an error.

trishankatdatadog

comment created time in 12 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

+package intoto++import (+	"encoding/json"+	"io/ioutil"+	"os"+	"path/filepath"++	"github.com/cnabio/signy/pkg/docker"+	log "github.com/sirupsen/logrus"+	"github.com/theupdateframework/notary/client"+)++const (+	// Fixed as per CNAB-100 spec

Not sure I follow this comment.

trishankatdatadog

comment created time in 12 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

+package intoto++import (+	"fmt"+	"io/ioutil"+	"path/filepath"+	"strings"++	canonicaljson "github.com/docker/go/canonical/json"+)++// Metadata represents the In-Toto metadata stored in TUF.+// All fields are represented as []byte in order to be stored in the Custom field for TUF metadata.+type Metadata struct {+	// TODO: remove this once the TUF targets key is used to sign the root layout+	Key    []byte            `json:"key"`+	Layout []byte            `json:"layout"`+	Links  map[string][]byte `json:"links"`+}++// WriteMetadataFiles writes the content of a metadata object into files in a directory+func WriteMetadataFiles(m *Metadata, dir string) error {+	abs, err := filepath.Abs(dir)+	if err != nil {+		return err+	}++	//FIXME: no need to actually write filename.+	err = ioutil.WriteFile(filepath.Join(abs, "root.layout"), m.Layout, ReadOnlyMask)+	if err != nil {+		return err+	}++	//FIXME: no need to actually write filenames.+	err = ioutil.WriteFile(filepath.Join(abs, "root.layout.pub"), m.Key, ReadOnlyMask)+	if err != nil {+		return err+	}++	for n, c := range m.Links {+		err = ioutil.WriteFile(filepath.Join(abs, n), c, ReadOnlyMask)+		if err != nil {+			return err+		}+	}++	return nil+}++// GetMetadataRawMessage takes In-Toto metadata and returns a canonical RawMessage+// that can be stored in the TUF targets custom field.+//+// TODO: layout signing key should not be passed by the library.+// Layouts should be signed with the targets key used to sign the TUF collection.+func GetMetadataRawMessage(layout string, linkDir string, layoutKey string) (canonicaljson.RawMessage, error) {+	k, err := ioutil.ReadFile(layoutKey)+	if err != nil {+		return nil, fmt.Errorf("cannot get canonical JSON from file %v: %v", layoutKey, err)+	}++	l, err := ioutil.ReadFile(layout)+	if err != nil {+		return nil, fmt.Errorf("cannot get canonical JSON from file %v: %v", layout, err)+	}++	links := make(map[string][]byte)+	files, err := ioutil.ReadDir(linkDir)+	if err != nil {+		return nil, fmt.Errorf("cannot read links directory %v: %v", linkDir, err)+	}+	for _, f := range files {+		// TODO - Radu M+		//+		// robust check if file is actually a link

This is still a valid TODO - do we actually check if the directory passed by a user contains only in-toto metadata?

trishankatdatadog

comment created time in 12 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

+package intoto++import (+	"fmt"+	"io/ioutil"+	"path/filepath"+	"strings"++	canonicaljson "github.com/docker/go/canonical/json"+)++// Metadata represents the In-Toto metadata stored in TUF.+// All fields are represented as []byte in order to be stored in the Custom field for TUF metadata.+type Metadata struct {+	// TODO: remove this once the TUF targets key is used to sign the root layout+	Key    []byte            `json:"key"`+	Layout []byte            `json:"layout"`+	Links  map[string][]byte `json:"links"`+}++// WriteMetadataFiles writes the content of a metadata object into files in a directory+func WriteMetadataFiles(m *Metadata, dir string) error {+	abs, err := filepath.Abs(dir)+	if err != nil {+		return err+	}++	//FIXME: no need to actually write filename.

I get that now the verification process takes *.layout, but under what name should we write this file? Same for below.

trishankatdatadog

comment created time in 12 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

+package intoto++import (+	"fmt"+	"io/ioutil"+	"path/filepath"+	"strings"++	canonicaljson "github.com/docker/go/canonical/json"+)++// Metadata represents the In-Toto metadata stored in TUF.+// All fields are represented as []byte in order to be stored in the Custom field for TUF metadata.+type Metadata struct {+	// TODO: remove this once the TUF targets key is used to sign the root layout

TODO.

trishankatdatadog

comment created time in 12 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

-package intoto

This is rather simple, but I hoped that at some point we would add more tests specific to CNAB here.

trishankatdatadog

comment created time in 12 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

-package docker

Why delete this?

trishankatdatadog

comment created time in 12 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

 func generateArchive(files map[string][]byte) (io.Reader, error) { 	return r, nil } -func buildFileMap(layout, key, linksDir string, targeFiles []string) (map[string][]byte, error) {+func buildFileMap(verificationDir string) (map[string][]byte, error) { 	files := make(map[string][]byte) -	lc, err := ioutil.ReadFile(layout)-	if err != nil {-		return nil, err-	}-	files[layoutPath] = lc--	kc, err := ioutil.ReadFile(key)-	if err != nil {-		return nil, err-	}-	files[keyPath] = kc--	f, err := ioutil.ReadDir(linksDir)+	filenames, err := ioutil.ReadDir(verificationDir) 	if err != nil { 		return nil, err 	}-	for _, li := range f {-		if !strings.Contains(li.Name(), ".link") {-			continue-		}-		b, err := ioutil.ReadFile(filepath.Join(linksDir, li.Name()))+	for _, filename := range filenames {+		b, err := ioutil.ReadFile(filepath.Join(verificationDir, filename.Name())) 		if err != nil { 			return nil, err 		}--		files[filepath.Join("in-toto", li.Name())] = b-	}--	for _, fi := range targeFiles {-		by, err := ioutil.ReadFile(fi)-		if err != nil {-			return nil, err-		}--		files[filepath.Join("in-toto", path.Base(fi))] = by+		files[filepath.Join(WorkingDir, filename.Name())] = b

Oh wow, this is so much cleaner.

trishankatdatadog

comment created time in 12 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

 import ( 	log "github.com/sirupsen/logrus" ) +var (+	Tag               string+	VerificationImage = "cnabio/signy-in-toto-verifier:" + Tag+)+ const (-	layoutPath = "/in-toto/layout.template"-	keyPath    = "/in-toto/key.pub"+	// Where we expect to copy in-toto artifacts to.

I would assume the linter is unhappy because the comment is not // WorkingDir is the directory...

trishankatdatadog

comment created time in 13 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

 INFO[0001] The software product passed all verification. 	cmd.Flags().StringVarP(&verify.localFile, "local", "", "", "Local file to validate the SHA256 against (mandatory for thick bundles)")  	cmd.Flags().BoolVarP(&verify.intoto, "in-toto", "", false, "If passed, will try to fetch in-toto metadata from TUF and perform the verification")-	cmd.Flags().StringVarP(&verify.verificationImage, "image", "", "github.com/cnabio/signy/in-toto-container/verification:v1", "container image to run the in-toto verification")-	cmd.Flags().BoolVarP(&verify.keepTempDir, "keep", "", false, "if passed, the temporary directory where the in-toto metadata is pulled is not deleted")-	cmd.Flags().StringArrayVarP(&verify.targetFiles, "target", "", nil, "target files to copy in container for in-toto verifications")+	cmd.Flags().BoolVarP(&verify.verifyOnOS, "verify-on-os", "", false, "If passed, will run in-toto inspections on the OS instead of in container")+	cmd.Flags().StringVarP(&verify.verificationImage, "image", "", docker.VerificationImage, "container image to run the in-toto verification")

If the --verify-on-os flag is passed, the --image flag will be ignored, right? Do we want to explicitly state this? Or maybe even make them mutually exclusive?

trishankatdatadog

comment created time in 13 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

 type verifyCmd struct { 	localFile string  	intoto            bool-	keepTempDir       bool+	verifyOnOS        bool 	verificationImage string-	// TODO: remove this-	targetFiles []string

Excellent!

trishankatdatadog

comment created time in 13 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

 endif  .PHONY: build build:-	go build $(GOFLAGS) -tags '$(GOBUILDTAGS)' -ldflags '$(LDFLAGS)' -o $(BINDIR)/$(TARGET) github.com/$(ORG)/$(PROJECT)/cmd/...+	go build $(GOFLAGS) -tags '$(GOBUILDTAGS)' -ldflags "$(LDFLAGS)" -o $(BINDIR)/$(TARGET) github.com/$(ORG)/$(PROJECT)/cmd/...

Why the switch to double quotation marks?

trishankatdatadog

comment created time in 13 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

-FROM python:latest

Now necessarily a fan of the Dockerfiles directory, neither the name, nor the capitalization - do we think we will have multiple Dockerfiles in the future to justify having a separate directory?

trishankatdatadog

comment created time in 13 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

-name: GitHub Actions-on: [push, pull_request]+name: Build, test, and lint+on:+  pull_request:+  push:+    branches: [master]+  release:+    types: [published] jobs:-   build:     name: Build     runs-on: ubuntu-latest     steps:--    - name: Set up Go 1.13-      uses: actions/setup-go@v1-      with:-        go-version: 1.13-      id: go+    - name: Set up Go+      uses: actions/setup-go@v2      - name: Check out code-      uses: actions/checkout@v1+      uses: actions/checkout@v2 -    - name: Build, Test, Lint-      run: |-        export GOPATH=$HOME/go && export GOBIN=$(go env GOPATH)/bin && export PATH=$PATH:$GOPATH&& export PATH=$PATH:$GOBIN && mkdir -p $GOBIN

The reason this was on a single line was because it is completely uninteresting, and it's a side effect of us still doing a go get somewhere for some tools, which we should remove.

But if you think it's better to have it expanded each on its, line, I'm fine with it as well.

trishankatdatadog

comment created time in 13 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

-name: GitHub Actions-on: [push, pull_request]+name: Build, test, and lint+on:+  pull_request:+  push:+    branches: [master]+  release:+    types: [published] jobs:-   build:     name: Build     runs-on: ubuntu-latest     steps:--    - name: Set up Go 1.13-      uses: actions/setup-go@v1-      with:-        go-version: 1.13-      id: go+    - name: Set up Go+      uses: actions/setup-go@v2      - name: Check out code-      uses: actions/checkout@v1+      uses: actions/checkout@v2 -    - name: Build, Test, Lint-      run: |-        export GOPATH=$HOME/go && export GOBIN=$(go env GOPATH)/bin && export PATH=$PATH:$GOPATH&& export PATH=$PATH:$GOBIN && mkdir -p $GOBIN+    - name: Build and push Docker images+      uses: docker/build-push-action@v1.1.0+      if: ${{ github.event_name == 'push' || github.event_name == 'release' }}

I think we actually need to create a release in order to test this, right? (There is a draft release that we can add to for this.)

trishankatdatadog

comment created time in 13 days

Pull request review commentcnabio/signy

Option to verify in-toto metadata on OS or container

-name: GitHub Actions-on: [push, pull_request]+name: Build, test, and lint+on:+  pull_request:+  push:+    branches: [master]+  release:+    types: [published] jobs:-   build:     name: Build     runs-on: ubuntu-latest     steps:--    - name: Set up Go 1.13-      uses: actions/setup-go@v1-      with:-        go-version: 1.13-      id: go+    - name: Set up Go+      uses: actions/setup-go@v2      - name: Check out code-      uses: actions/checkout@v1+      uses: actions/checkout@v2 -    - name: Build, Test, Lint-      run: |-        export GOPATH=$HOME/go && export GOBIN=$(go env GOPATH)/bin && export PATH=$PATH:$GOPATH&& export PATH=$PATH:$GOBIN && mkdir -p $GOBIN+    - name: Build and push Docker images+      uses: docker/build-push-action@v1.1.0

+1 for using the official Docker action here.

trishankatdatadog

comment created time in 13 days

issue commentdeislabs/krustlet

Feature: templated WASM/I developer experience with GH action for build/push

Generators like Yeoman sound like a good fit for this - additionally, I would also suggest we look at VS Code dev containers before thinking about extensions.

squillace

comment created time in 14 days

issue commentengineerd/wasm-to-oci

Try pushing to docker hub and fail

Yes, currently Docker Hub actively rejects media types outside of a clearly defined list - I also updated the readme to clearly state that pushing to Docker Hub is indeed expected to fail.

(For a bit more context, this project expects the registry to allow arbitrary artifacts - as described by the proposed OCI Artifacts proposal. Given that the proposal is fairly new, it is indeed expected that, unless explicitly tested, a registry will actively reject unknown media types, and so will reject WebAssembly modules.)

jingweno

comment created time in a month

issue commentcnabio/signy

Push verification image to a `cnabio` registry

Ideally, we would version the image together with Signy, and publish images whenever we release Signy.

For this, we should use the same registry we use for other container images, and have a GitHub action that publishes to the registry on release.

I think @vdice may have access to the credentials for the registry?

radu-matei

comment created time in a month

Pull request review commentcnabio/signy

Simplify TUF+in-toto verification logic

+package intoto++import (+	"encoding/json"+	"io/ioutil"+	"os"+	"path/filepath"++	"github.com/cnabio/signy/pkg/docker"+	log "github.com/sirupsen/logrus"+	"github.com/theupdateframework/notary/client"+)++const (+	// Fixed as per CNAB-100 spec+	BundleFilename = "bundle.json"+	ReadOnlyMask   = 0400+)++func Verify(verificationImage string, target *client.TargetWithRole, bundle []byte, logLevel string) error {+	m := &Metadata{}+	err := json.Unmarshal(*target.Custom, m)+	if err != nil {+		return err+	}++	verificationDir, err := ioutil.TempDir(os.TempDir(), "in-toto")+	if err != nil {+		return err+	}+	defer func() {+		os.RemoveAll(verificationDir)+		os.Remove(verificationDir)+	}()++	log.Infof("Writing in-toto metadata files into %v", verificationDir)+	err = WriteMetadataFiles(m, verificationDir)+	if err != nil {+		return err+	}++	bundleFilename := filepath.Join(verificationDir, BundleFilename)+	err = ioutil.WriteFile(bundleFilename, bundle, ReadOnlyMask)+	if err != nil {+		log.Fatal(err)+	}++	if verificationImage == "" {

(We should definitely discuss this in the next CNAB meeting - already on the agenda) I have some reservations around UX here - i.e. not passing an image vs. actively passing a flag that requests the verification to be performed locally.

On top of that, I think we could look into a Verifier interface that has implementations locally and inside a container, and choose the implementation based on the flag.

trishankatdatadog

comment created time in a month

delete branch cnabio/signy

delete branch : trishankatdatadog/improve-in-toto

delete time in a month

push eventcnabio/signy

Trishank Karthik Kuppusamy

commit sha 9570a5bfe0fce309a039c131d5a95b14a31b2848

add image to verify in-toto metadata Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank Karthik Kuppusamy

commit sha 13b17e2d2154678577d84b8a9a4e0a3a0d5da04c

move destructive op Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Radu M

commit sha 3a0d506bfef6085cf3cfd74861329d3c22edfd40

Merge pull request #72 from cnabio/trishankatdatadog/improve-in-toto Bootstrap image to verify in-toto metadata

view details

push time in a month

PR merged cnabio/signy

Bootstrap image to verify in-toto metadata

Signed-off-by: Trishank Karthik Kuppusamy trishank.kuppusamy@datadoghq.com

+44 -9

0 comment

9 changed files

trishankatdatadog

pr closed time in a month

more