profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/dlorenc/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

bazelbuild/rules_k8s 243

This repository contains rules for interacting with Kubernetes configurations / clusters.

dlorenc/chains 2

Tekton Chains

asraa/test-sigstore-root 1

Test repo for creating sigstore root metadata

dlorenc/appengine 0

Go App Engine packages

dlorenc/application 0

Application metadata descriptor CRD

dlorenc/base-images-docker 0

Base images for Google Docker containers.

dlorenc/bash-it 0

A community bash framework.

PR opened sigstore/cosign

Add the URIs subject to our outputting.

GitHub certificates in Fulcio use the URIs field, while others use email. Let's add both to the output formatting.

Signed-off-by: Dan Lorenc lorenc.d@gmail.com

<!-- Thanks for opening a pull request!

Please remember to:

  • mention any issue(s) that this PR closes using a closing keyword as well as the issue number, such as "Closes #XYZ" or "Resolves sigstore/repo-name#XYZ", cf. documentation
  • ensure your commits are signed-off, as sigstore uses the DCO using git commit -s, or git commit -s --amend if you want to amend already existing commits
  • lastly, ensure there are no merge commits! Thank you :) -->

Summary

<!-- A description of what this pull request does, as well as QA test steps (if applicable and if not already added to the Jira ticket). -->

Ticket Link

<!-- If this pull request addresses a Help Wanted ticket, please link the relevant GitHub issue, e.g.

Fixes https://github.com/sigstore/YYYYYY/issues/XXXXX

--> Fixes

Release Note

<!-- Add a release note for each of the following conditions:

  • Config changes (additions, deletions, updates)
  • API additions—new endpoint, new response fields, or newly accepted request parameters
  • Database changes (any)
  • Websocket additions or changes
  • Anything noteworthy to a Mattermost instance administrator (err on the side of over-communicating)
  • New features and improvements, including behavioural changes, UI changes and CLI changes
  • Bug fixes and fixes of previous known issues
  • Deprecation warnings, breaking changes, or compatibility notes

If no release notes are required write NONE. Use past-tense.

-->


+13 -2

0 comment

1 changed file

pr created time in 6 minutes

create barnchdlorenc/cosign

branch : csub

created branch time in 6 minutes

push eventdlorenc/cosign

Matt Moore

commit sha 65f3a2d9c725ce03d9887bfeb6d9ed39dd32ec36

Skip empty values, not just missing keys. (#708) One of my previous changes switch from skipping `""` fetched from the map to using this syntax: ```go blah, ok := themap[thekey] if !ok { ... } ``` However, it seems like there may be paths where we actually have these keys, but they contain empty string. I'm seeing an index-out-of-bounds with both open PRs and HEAD trying to `cosign verify dockerfile` with `gcr.io/distroless/base`. I'm sending this while I do a big more digging into the signatures there, but wanted to eliminate this delta quickly to avoid tripping others up. Signed-off-by: Matt Moore <mattomata@gmail.com>

view details

Scott Nichols

commit sha d0944b3e8892cf5537e5c44d296d5abbaaa0d091

Migrate sget to cobra. (#709) Signed-off-by: Scott Nichols <deoryp@gmail.com>

view details

Matt Moore

commit sha 210f7eebbbcb2584eef5d4cee2d291d9916184a7

Start to sketch `internal/oci/remote.SignedImage[Index]`. (#705) This follows the pattern GGCR uses for functional `remote.Options`, and starts to define `SignedImage[Index]` methods, which build upon the `Signatures` implementation from a prior change. This also tries to start adopting this pattern a few places, which drops bits of boilerplate (or changes them to functional options). As part of this, I'm combining `FetchSignaturesForImage[Digest]` and tweaking it's signature a bit (no pun intended!), but I think long term we'll just want folks to consume the `remote` package directly themselves. Signed-off-by: Matt Moore <mattomata@gmail.com>

view details

Jake Sanders

commit sha cd3e36b51f3a85d5d30ba975b0dd32312a041bad

move `verify-manifest` to `manifest verify` (#712) Signed-off-by: Jake Sanders <jsand@google.com>

view details

Jake Sanders

commit sha 71cd9d887d8fc72fb533e28647522031148e3b60

add -allow-insecure-registry flag to copasetic (#710) Signed-off-by: Jake Sanders <jsand@google.com>

view details

Carlos Tadeu Panato Junior

commit sha 3061c71ec84e369171f7d23d367b147896fba02d

ci/operations: fixing milestone workflow, when running a fork the temp token is not set (#713) Signed-off-by: Carlos Panato <ctadeu@gmail.com>

view details

Matt Moore

commit sha e21fae39589bedd6a73c0a047a266c777021dd96

Break apart `remote[_test].go`. (#714) These files were starting to feel large in my previous change, but I didn't want to combine a bunch of functionality with breaking everything apart, so I left it large. This change is just moving logic into separate files. Related: https://github.com/sigstore/cosign/issues/666 Signed-off-by: Matt Moore <mattomata@gmail.com>

view details

Matt Moore

commit sha 1e055235dc5bdab5f9d446ad5fd31dbc72225312

Rename `FetchSignaturesForImage` to `Reference` (#715) This is sort of a throwaway, since I want to kill this method, but I realized staring at it that it's a misnomer since it actually needs to handle `ImageIndex` as well today. The name misled me into using `ociremote.SignedImage` here where I really wanted `ociremote.SignedEntity`. Anyways, VS Code made it easy to change, so I changed it :D Signed-off-by: Matt Moore <mattomata@gmail.com>

view details

Matt Moore

commit sha 9d4f3d43de6ba0513620d7848fda119b969dc24e

Have `Signatures` take `ociremote.Options`. (#717) This was a TODO in the previous PR that introduces `ociremote.Option`. This is mostly for consistency of these interfaces. Signed-off-by: Matt Moore <mattomata@gmail.com>

view details

Dan Luhring

commit sha ae960b97774baf1e3449588af9c1b9794bb7a9d3

Remove go.mod replace directive (#716) Signed-off-by: Dan Luhring <dan.luhring@anchore.com>

view details

push time in 25 minutes

push eventdlorenc/hello-ko

Dan Lorenc

commit sha 146d4d4e2c38170f3df2c536d69a6e5368c422cd

First commit! Signed-off-by: Dan Lorenc <lorenc.d@gmail.com>

view details

push time in 28 minutes

push eventdlorenc/hello-ko

Dan Lorenc

commit sha 0461bb0d3c372fc5600d2279fa65dbf209a81492

First commit! Signed-off-by: Dan Lorenc <lorenc.d@gmail.com>

view details

push time in 30 minutes

push eventdlorenc/hello-ko

Dan Lorenc

commit sha b9b91943dd02fb75cab675895d3db7da8177c694

First commit! Signed-off-by: Dan Lorenc <lorenc.d@gmail.com>

view details

push time in 38 minutes

push eventdlorenc/hello-ko

Dan Lorenc

commit sha dd4173d62c13bf2a5f5d584bfe445985c68aa461

First commit! Signed-off-by: Dan Lorenc <lorenc.d@gmail.com>

view details

push time in 40 minutes

push eventdlorenc/hello-ko

Dan Lorenc

commit sha 232cdc881a98f1298c6358495de80ac775804582

First commit! Signed-off-by: Dan Lorenc <lorenc.d@gmail.com>

view details

push time in 43 minutes

push eventdlorenc/hello-ko

Dan Lorenc

commit sha a603b14968d5752ee376f95a753d08a1f5262984

First commit!

view details

push time in 44 minutes

create barnchdlorenc/hello-ko

branch : main

created branch time in an hour

created repositorydlorenc/hello-ko

Hello Ko App

created time in an hour

PR opened tektoncd/pipeline

Bump some stale dependencies in go.mod.

This bumps:

  • go-containerregistry (and k8schain)
  • multierr
  • x/net
  • zap

Signed-off-by: Dan Lorenc lorenc.d@gmail.com

<!-- 🎉🎉🎉 Thank you for the PR!!! 🎉🎉🎉 -->

Changes

<!-- Describe your changes here- ideally you can get that description straight from your descriptive commit message(s)!

In addition, categorize the changes you're making using the "/kind" Prow command, example:

/kind <kind>

Supported kinds are: bug, cleanup, design, documentation, feature, flake, misc, question, tep -->

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

  • [ ] Docs included if any changes are user facing
  • [ ] Tests included if any functionality added or changed
  • [ ] Follows the commit message standard
  • [ ] Meets the Tekton contributor standards (including functionality, content, code)
  • [ ] Release notes block below has been filled in or deleted (only if no user facing changes)

Release Notes

<!-- Describe any user facing changes here, or delete this block.

Examples of user facing changes:

  • API changes
  • Bug fixes
  • Any changes in behavior
  • Changes requiring upgrade notices or deprecation warnings

For pull requests with a release note:

Your release note here

For pull requests that require additional action from users switching to the new release, include the string "action required" (case insensitive) in the release note:

action required: your release note here

For pull requests that don't need to be mentioned at release time, use the /release-note-none Prow command to add the release-note-none label to the PR. You can also write the string "NONE" as a release note in your PR description:

NONE

-->

+26684 -1527

0 comment

197 changed files

pr created time in 2 hours

create barnchdlorenc/build-pipeline

branch : bumpsomedeps

created branch time in 2 hours

push eventdlorenc/build-pipeline

Khurram Baig

commit sha 6a578884454bb61b15a02606148cbab3a030a0d2

Fix Concurrency issue in the metrics A double locking was happening in recorder mutex which was creating unexpected behaviour. Lock needs to be done only in the function that calls opencensus stats recorder.

view details

Khurram Baig

commit sha 9c61cdf6d4b7b5e26c787d62447c0eed1c92b68f

Docs for Metrics Configuration Added docs for configuring metrics using config-observability. Level and type of metrics and how to configure them using cm has been documented.

view details

Scott

commit sha 78d6d75473ea00118fa1e07cbf6b8e97439689ad

Document Pipeline's use of Pod termination messages Prior to this commit we primarily documented use of termination messages through a lens of Task Results, but the mechanism is used more broadly than this. This commit adds notes to our developer docs explaining use of pod termination messages, giving examples of the data included, how the data is distributed to other parts of the Pipelines machinery and describing the lack of guarantees around the message's content.

view details

Scott

commit sha 5fa4348bdbb7f28280bcfd518f6025c94670e420

Add controller flag to turn off built-in resolution We're currently trying to work out what the best way forward for TEP-0060 (remote resolution) is for Tekton Pipelines. As part of that we're creating a controller in the experimental repo that we can use to test out a bunch of the Alternatives from the TEP and figure out what works best in terms of implementation and DX. Right now the experimental controller would race with the Pipelines controllers since they're all going to try and "resolve" any taskRef in Taskruns and PipelineRuns. This commit adds a flag to the pipelines controller that explicitly switches off resolution performed by the taskrun and pipelinerun reconcilers. This gives us just enough room to perform resolution out-of-band and try out some of the alternatives. When the `-experimental-disable-in-tree-resolution` flag is set the taskrun and pipelinerun controllers will ignore taskruns and pipelineruns that don't have `status.taskSpec` or `status.pipelineSpec` populated.

view details

Matt Moore

commit sha fc0a2d740f832cab40b289bade189ca3c693390c

Allow `.` in param/result names via subscript. This change allow folks to use `.` in parameter names (e.g. `dev.mattmoor.my-param`), and reference them via the subscript operator (e.g. `params["dev.mattmoor.my-param"]`) to avoid ambiguity introduced by the mixing of `.`s. TEP: https://github.com/tektoncd/community/pull/503

view details

Matt Moore

commit sha 4642f04ab4597657027778c913ce4951f8299e93

Update docs/ with params/results syntax changes

view details

Dan Lorenc

commit sha 64b5bbf6cf056095e426981f3345966dd40a4929

Bump github.com/cloudevents/sdk-go to v2.5.0 This updates the cloudevents dependency from v2.1.0 to v2.5.0. This is over a year old and catches us up quite far. There was one manual change in the cloud_event_controller_test.go file. CloudEvents changed the string representation of an event, which our tests looked for. This matches the change to their upstream test: github.com/cloudevents/sdk-go/pull/639. Signed-off-by: Dan Lorenc <lorenc.d@gmail.com> Signed-off-by: Dan Lorenc <dlorenc@google.com>

view details

Shivam Mukhade

commit sha db62a612c54704f335deb36307f805af8b8dc730

Converts ResultType in PipelineResourceResult string to int This converts the ResultType in PipelineResourceResult from string to int enum to curtail the size of json object emittted by steps. ResultTypes were removed because they made JSON messages bigger, which in turn limited the amount of space in termination messages for task results. String support is maintained for backwards compatibility. Closes #4150 Signed-off-by: Shivam Mukhade <smukhade@redhat.com>

view details

Jason Hall

commit sha b47ed53c15d18b7f4a72339192972c5964e24d95

Remove unnecessary replace directives in go.mod The comment previously indicated these `replace`s were necessary for knative v0.20 deps. The knative/pkg deps were recently updated by mattmoor in 8afd1563782dffe7e256859cf81b22f21b2f81c0 (and presumably many times since 0.20), and seem to no longer need the `replace`s. Dropping these `replace`s updates our deps: - azure-sdk-for-go dep updates to a package released in Jun 2020, from one released Jan 2020. - we seem to no longer depend on the stackdriver package, so the `replace` was unnecessary. This change was generated by: - remove `replace` directives - `go mod tidy` - `./hack/update-deps.sh` - `go build ./...` to make sure things didn't break 🤞

view details

Billy Lynch

commit sha f597c92ba052aaf23510b0165dd9fbc07c4c93c2

Implement implicit parameter resolution. This is the implementation of [TEP-0023](https://github.com/tektoncd/community/blob/main/teps/0023-implicit-mapping.md). This adds information to the defaulting context to allow parameters to be passed down the stack during evaluation. This functionality is gated behind the alpha feature flag. Additionally, Tasks are now allowed to accept more params than are actually used. This should generally be safe, since extra params that are provided should not affect the behavior of the Task itself.

view details

Vincent Demeester

commit sha ff860dfadf2faea858ba0dbcb923fb641550dd8a

Revamp how pipeline supports Limitranges Up until now, pipeline support for LimitRange is rather limited and confusing and can lead to inconsistency: - It is not applied to `InitContainers` - It zero-out user requests to keep the max and assign to one step, which can lead to invalid `Pod` definition. - It uses only `Min` and never reads `Default` and `DefaultRequest` - It also doesn't support `MaxLimitRequestRatio` This commits aims to fix that by adding more support to LimitRange. Note that, to understand some of the choice, some assumption on how LimitRange works is required. On `Pod` Containers: - *Requests* are not enforced. If the node has more resource available than the request, the container can use it. - *Limits* on the other hand, are a hard stop. A container going over the limit, will be killed. It is thus important to get `Requests` right, to allow scheduling. Requests and limits can come from both Containers and Init Containers. - For init containers, the max of each type is taken - For containers, it sums all requests/limits for each containers This means, if you got the following: - initContainer1 : 1 CPU, 100m memory - initContainer2 : 2 CPU, 200m memory - container1 : 1 CPU, 50m memory - container2 : 2 CPU, 250m memory - container3 : 3 CPU, 500m memory The computation will be: - CPU : 2 (max init containers) + 6 (sum of containers) = 8 CPU - Memory: 200m (max init containers) + 800m (sum of containers) = 1000m (1G) LimitRange enforce (mutates the `Pod`) some Limits and Requests (using `Default` and `DefaultRequest`) and validate those (`Min`, `Max` and `MaxLimitRequestRatio`). They are applied by namespace, and it is possible to have multiple `LimitRange` in a namespace. The way Limits and Requests works in Kubernetes is because it is assumed that all containers run in parallel (which they do — except in tekton with some hack), and init container run before, each one after the others. That assumption — running in parallel — is not really true in Tekton. They do all start together (because there is no way around this) *but* the /entrypoint hack/ is making sure they actually run in sequence and thus there is always only one container that is actually consuming some resource at the same time. This means, we need to handle limits, request and LimitRanges in a /non-standard/ way. Let's try to define that. Tekton needs to take into account all the aspect of the LimitRange : the min/max as well as the default. If there is no default, but there is min/max, Tekton need then to *set* a default value that is between the min/max. If we set the value too low, the Pod won't be able to be created, similar if we set the value too high. *But* those values are set on *containers*, so we *have to* do our own computation to know what request to put on each containers. To add to the complexity here, we also need to support `MaxLimitRequestRatio`, which is just adding complexity on top of something complex. That said, ideally, if we take the default correctly, we should be able to have support for `MaxLimitRequestRatio` for free. This commits tries to add support for this, by computing the minimum request to apply that satisfy the `LimitRange`(s), applying them to `Containers` as well `InitContainers`. Note: If there is multiple `LimitRange` in the namespace, Tekton tries to make the best out of it *but* if they are conflicting with each other (a `Max` on one that is smaller than the `Min` on the other), its the user responsability. Signed-off-by: Vincent Demeester <vdemeest@redhat.com>

view details

Vincent Demeester

commit sha adaae90b9bb93aa96cb345f75bf7797a12f8c308

Use an Informer to list LimitRanges 🥼 Using a LimitRange lister here instead, so this doesn't end up hitting the real API server on each call. Taking into account a review : https://github.com/tektoncd/pipeline/pull/4176#issuecomment-920366660. Signed-off-by: Vincent Demeester <vdemeest@redhat.com>

view details

Billy Lynch

commit sha 69edb2affd897503dbcfa80bc3bc6789adf5bc96

Revamp Tekton developer docs for /tekton paths. The content is largely the same, this just reorganizes some of the content into a table and provides a sample filetree to show what files/directories are present. Additionally, this adds docs for the following directories that were not already present: - /tekton/downward - /tekton/creds Other diffs are formating caused by `prettier --prose-wrap always`

view details

Billy Lynch

commit sha 0fcdd3962fd611aff512cc56cbf1fb9e73116855

Mount entrypoint volume as read-only. This change makes the entrypoint binary read-only by separating the /tekton/tools directory: - /tekton/bin - Mounted as RW by the place-tools init container, and RO for all user steps. This directory will hold Tekton provided binaries (i.e. entrypoint). - /tekton/run - Named after Linux's /run directory (https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard). This directory will hold Tekton runtime data (i.e. step post/wait files). This is being done as an extra layer of security to prevent any tampering of Tekton provided tools. This is similar in spirit to 89a623317e57a10ff83ad6a2b823e4f617ac644e (making the scripts directory read-only). /tekton/tools was considered an internal directory, so this change is not bound to API compatibility/deprecation policies. This change should have no affect on the user API surface. This change does not try to address any issues with the shared post/wait file volume - this will be handled in another change.

view details

push time in 3 hours

pull request commenttektoncd/community

TEP e2e provenance

Thanks for filing this! We should definitely do this. Chains started with taskruns, but we've always intended to extend this to pipelineruns.

/assign dlorenc

nadgowdas

comment created time in 3 hours

push eventsigstore/rekor

Dan Luhring

commit sha c519868c22720b98af346c9fdaf9d481715c8d1e

Export search UUIDs field (#438) Signed-off-by: Dan Luhring <dan.luhring@anchore.com>

view details

push time in 3 hours

PR merged sigstore/rekor

Enable JSON format for search command

Summary

<!-- A description of what this pull request does, as well as QA test steps (if applicable and if not already added to the Jira ticket). -->

I noticed that there was an inconsistency in the output for the rekor-cli search command between the default format and the JSON format:

$ rekor-cli search --email dan.luhring@anchore.com              
Found matching entries (listed by UUID):
30c398a619c5eb00856bc41df6ab4c660e321ed06e745b562947c48e0dc5ef64
$ rekor-cli search --email dan.luhring@anchore.com --format json
Found matching entries (listed by UUID):
{}

Diagnosis: The searchCmdOutput struct wasn't able to be marshaled because its field uuids wasn't exported. This PR exports that field.

Testing

Run the search command and specify the JSON format:

$ go run ./cmd/rekor-cli/main.go search --email dan.luhring@anchore.com --format json                   

See that the JSON output has the UUIDs field populated correctly:

Found matching entries (listed by UUID):
{"UUIDs":["30c398a619c5eb00856bc41df6ab4c660e321ed06e745b562947c48e0dc5ef64"]}

Ticket Link

<!-- If this pull request addresses a Help Wanted ticket, please link the relevant GitHub issue, e.g.

Fixes https://github.com/sigstore/YYYYYY/issues/XXXXX

--> (n/a)

Release Note

Enable JSON format for search command

Signed-off-by: Dan Luhring dan.luhring@anchore.com

+3 -3

1 comment

1 changed file

luhring

pr closed time in 3 hours

PullRequestReviewEvent

pull request commentsigstore/rekor

Enable JSON format for search command

Great catch!

luhring

comment created time in 3 hours

push eventsigstore/cosign-installer

Carlos Tadeu Panato Junior

commit sha 7436096ebe77ccbdf68687dd67ee84b3dc073dfb

adding permission scope documentation (#27) Signed-off-by: Carlos Panato <ctadeu@gmail.com>

view details

push time in 6 hours

PR merged sigstore/cosign-installer

Reviewers
adding permission scope

Summary

Add permission scope documentation for the GH Action and also set those in the CI

Ticket Link

Fixes: https://github.com/sigstore/cosign-installer/issues/26

Release Note

<!-- Add a release note for each of the following conditions:

  • Config changes (additions, deletions, updates)
  • API additions—new endpoint, new response fields, or newly accepted request parameters
  • Database changes (any)
  • Websocket additions or changes
  • Anything noteworthy to a Mattermost instance administrator (err on the side of over-communicating)
  • New features and improvements, including behavioural changes, UI changes and CLI changes
  • Bug fixes and fixes of previous known issues
  • Deprecation warnings, breaking changes, or compatibility notes

If no release notes are required write NONE. Use past-tense.

-->

document permission scopes
+147 -0

0 comment

2 changed files

cpanato

pr closed time in 6 hours

issue closedsigstore/cosign-installer

Define permissions for actions

The cosign action doesn't provide the default permissions that are required. This increases the attack vector. https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/

It is recommended to define permissions. https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions

closed time in 6 hours

naveensrinivasan
PullRequestReviewEvent
PullRequestReviewEvent

pull request commentsigstore/cosign

feat: add validation for predicates via cue policy files support

It totally ok, we know you are busy 😋 but actually we are waiting for your thoughts about supporting to validate predicates by using Rego policies also, if you want us to do this, we are so excited to implement it 🥳🙋🏻‍♂️

Sure!

developer-guy

comment created time in 6 hours

pull request commentsigstore/cosign

feat: add validation for predicates via cue policy files support

Sorry I lost track of this one last week! I'll get some time to play with it this week and get it merged!

developer-guy

comment created time in 7 hours

issue commentsigstore/cosign

Error when downloading cosign

Yeah, we should cut a 1.2.1 this week.

ericofusco

comment created time in 9 hours

startedovotech/gitoops

started time in 9 hours

issue commentsigstore/cosign

Installing cosign from solutions in #588

No worries! Thanks for explaining how you fixed this. It might help someone else some day!

syhv-git

comment created time in a day

push eventsigstore/cosign

Dan Luhring

commit sha ae960b97774baf1e3449588af9c1b9794bb7a9d3

Remove go.mod replace directive (#716) Signed-off-by: Dan Luhring <dan.luhring@anchore.com>

view details

push time in a day