chore: remodule ratify package (#1552)

.github/workflows/publish-dev-assets.yml

@@ -56,7 +56,7 @@ jobs:
           docker buildx create --use         
           docker buildx build -f ./httpserver/Dockerfile \
             --platform linux/amd64,linux/arm64,linux/arm/v7 \
-            --build-arg LDFLAGS="-X github.com/deislabs/ratify/internal/version.Version=$(TAG)" \
+            --build-arg LDFLAGS="-X github.com/ratify-project/ratify/internal/version.Version=$(TAG)" \
             --label org.opencontainers.image.revision=${{ github.sha }} \
             -t ${{ steps.prepare.outputs.baseref }}:${{ steps.prepare.outputs.version }} \
             -t ${{ steps.prepare.outputs.baseref }} \
@@ -70,7 +70,7 @@ jobs:
             --build-arg build_licensechecker=true \
             --build-arg build_schemavalidator=true \
             --build-arg build_vulnerabilityreport=true \
-            --build-arg LDFLAGS="-X github.com/deislabs/ratify/internal/version.Version=$(TAG)" \
+            --build-arg LDFLAGS="-X github.com/ratify-project/ratify/internal/version.Version=$(TAG)" \
             --label org.opencontainers.image.revision=${{ github.sha }} \
             -t ${{ steps.prepare.outputs.ref }}:${{ steps.prepare.outputs.version }} \
             -t ${{ steps.prepare.outputs.ref }} \

.github/workflows/publish-package.yml

@@ -55,7 +55,7 @@ jobs:
           docker buildx create --use         
           docker buildx build -f ./httpserver/Dockerfile \
             --platform linux/amd64,linux/arm64,linux/arm/v7 \
-            --build-arg LDFLAGS="-X github.com/deislabs/ratify/internal/version.Version=$(TAG)" \
+            --build-arg LDFLAGS="-X github.com/ratify-project/ratify/internal/version.Version=$(TAG)" \
             --label org.opencontainers.image.revision=${{ github.sha }} \
             -t ${{ steps.prepare.outputs.baseref }} \
             --push .
@@ -68,7 +68,7 @@ jobs:
             --build-arg build_licensechecker=true \
             --build-arg build_schemavalidator=true \
             --build-arg build_vulnerabilityreport=true \
-            --build-arg LDFLAGS="-X github.com/deislabs/ratify/internal/version.Version=$(TAG)" \
+            --build-arg LDFLAGS="-X github.com/ratify-project/ratify/internal/version.Version=$(TAG)" \
             --label org.opencontainers.image.revision=${{ github.sha }} \
             -t ${{ steps.prepare.outputs.ref }} \
             --push .

.goreleaser.yml

@@ -19,7 +19,7 @@ builds:
       - goos: windows
         goarch: arm64
     ldflags:
-      - -w -X github.com/deislabs/ratify/internal/version.GitTag={{.Version}} -X github.com/deislabs/ratify/internal/version.GitCommitHash={{.FullCommit}}
+      - -w -X github.com/ratify-project/ratify/internal/version.GitTag={{.Version}} -X github.com/ratify-project/ratify/internal/version.GitCommitHash={{.FullCommit}}
 
   - id: sbom
     dir: plugins/verifier/sbom

CONTRIBUTING.md

@@ -12,7 +12,7 @@ Welcome! We are very happy to accept community contributions to Ratify, whether
 
 ## Pull Requests
 
-If you'd like to start contributing to Ratify, you can search for issues tagged as "good first issue" [here](https://github.com/deislabs/ratify/labels/good%20first%20issue).
+If you'd like to start contributing to Ratify, you can search for issues tagged as "good first issue" [here](https://github.com/ratify-project/ratify/labels/good%20first%20issue).
 
 We use the `dev` branch as the our default branch. PRs passing the basic set of validation can be merged to the `dev` branch, we then run the full suite of validation including cloud specific tests on `dev` before changes can be merged into `main`. All ratify release are cut from the `main` branch. A sample PR process is outlined below:
 1. Fork this repo and create your dev branch from default `dev` branch.
@@ -148,7 +148,7 @@ Sample JSON stdin
 
 Press `Ctrl+D` to send EOF character to terminate the stdin input. (Note: you may have to press `Ctrl+D` twice)
 
-View more plugin debugging information [here](https://github.com/deislabs/ratify-verifier-plugin#debugging-in-vs-code)
+View more plugin debugging information [here](https://github.com/ratify-project/ratify-verifier-plugin#debugging-in-vs-code)
 
 ### Test local changes in the k8s cluster scenario
 
@@ -161,14 +161,14 @@ Follow the steps below to build and deploy a Ratify image with your private chan
 export REGISTRY=yourregistry
 docker buildx create --use
 
-docker buildx build -f httpserver/Dockerfile --platform linux/amd64 --build-arg build_sbom=true --build-arg build_licensechecker=true --build-arg build_schemavalidator=true --build-arg build_vulnerabilityreport=true -t ${REGISTRY}/deislabs/ratify:yourtag .
+docker buildx build -f httpserver/Dockerfile --platform linux/amd64 --build-arg build_sbom=true --build-arg build_licensechecker=true --build-arg build_schemavalidator=true --build-arg build_vulnerabilityreport=true -t ${REGISTRY}/ratify-project/ratify:yourtag .
 docker build --progress=plain --build-arg KUBE_VERSION="1.29.2" --build-arg TARGETOS="linux" --build-arg TARGETARCH="amd64" -f crd.Dockerfile -t ${REGISTRY}/localbuildcrd:yourtag ./charts/ratify/crds
 ```
 
 #### [Authenticate](https://docs.docker.com/engine/reference/commandline/login/#usage) with your registry,  and push the newly built image
 
 ```bash
-docker push ${REGISTRY}/deislabs/ratify:yourtag
+docker push ${REGISTRY}/ratify-project/ratify:yourtag
 docker push ${REGISTRY}/localbuildcrd:yourtag
 ```
 
@@ -196,16 +196,16 @@ Development charts + images are published weekly and latest versions are tagged
 
 Deploy to cluster:
 ```bash
-helmfile sync -f git::https://github.com/deislabs/[email protected]
+helmfile sync -f git::https://github.com/ratify-project/[email protected]
 ```
 
 ### Deploy from local helm chart
 
-#### Update [values.yaml](https://github.com/deislabs/ratify/blob/main/charts/ratify/values.yaml) to pull from your registry, when reusing image tag, setting pull policy to "Always" ensures we are pull the new changes
+#### Update [values.yaml](https://github.com/ratify-project/ratify/blob/main/charts/ratify/values.yaml) to pull from your registry, when reusing image tag, setting pull policy to "Always" ensures we are pull the new changes
 
 ```json
 image:
-  repository: yourregistry/deislabs/ratify
+  repository: yourregistry/ratify-project/ratify
   tag: yourtag
   pullPolicy: Always
 ```
@@ -314,13 +314,13 @@ If you'd like to contribute to the collection of plugins:
 
 ## Feature Suggestions
 
-* Please first search [Open Ratify Issues](https://github.com/deislabs/ratify/issues) before opening an issue to check whether your feature has already been suggested. If it has, feel free to add your own comments to the existing issue.
+* Please first search [Open Ratify Issues](https://github.com/ratify-project/ratify/issues) before opening an issue to check whether your feature has already been suggested. If it has, feel free to add your own comments to the existing issue.
 * Ensure you have included a "What?" - what your feature entails, being as specific as possible, and giving mocked-up syntax examples where possible.
 * Ensure you have included a "Why?" - what the benefit of including this feature will be.
 
 ## Bug Reports
 
-* Please first search [Open Ratify Issues](https://github.com/deislabs/ratify/issues) before opening an issue, to see if it has already been reported.
+* Please first search [Open Ratify Issues](https://github.com/ratify-project/ratify/issues) before opening an issue, to see if it has already been reported.
 * Try to be as specific as possible, including the version of the Ratify CLI used to reproduce the issue, and any example arguments needed to reproduce it.
 
 ## CLA

Makefile

@@ -15,7 +15,7 @@ BINARY_NAME		= ratify
 INSTALL_DIR		= ~/.ratify
 CERT_DIR        = ${GITHUB_WORKSPACE}/tls/certs
 
-GO_PKG			= github.com/deislabs/ratify
+GO_PKG			= github.com/ratify-project/ratify
 GIT_COMMIT_HASH = $(shell git rev-parse HEAD)
 GIT_TREE_STATE 	= $(shell test -n "`git status --porcelain`" && echo "modified" || echo "unmodified")
 GIT_TAG     	= $(shell git describe --tags --abbrev=0 --exact-match 2>/dev/null)
@@ -75,17 +75,17 @@ build: build-cli build-plugins
 .PHONY: build-cli
 build-cli: fmt vet
 	go build --ldflags="$(LDFLAGS)" -cover \
-	-coverpkg=github.com/deislabs/ratify/pkg/...,github.com/deislabs/ratify/config/...,github.com/deislabs/ratify/cmd/... \
+	-coverpkg=github.com/ratify-project/ratify/pkg/...,github.com/ratify-project/ratify/config/...,github.com/ratify-project/ratify/cmd/... \
 	-o ./bin/${BINARY_NAME} ./cmd/${BINARY_NAME}
 
 .PHONY: build-plugins
 build-plugins:
-	go build -cover -coverpkg=github.com/deislabs/ratify/plugins/verifier/licensechecker/... -o ./bin/plugins/ ./plugins/verifier/licensechecker
-	go build -cover -coverpkg=github.com/deislabs/ratify/plugins/verifier/sample/... -o ./bin/plugins/ ./plugins/verifier/sample
-	go build -cover -coverpkg=github.com/deislabs/ratify/plugins/referrerstore/sample/... -o ./bin/plugins/referrerstore/ ./plugins/referrerstore/sample
-	go build -cover -coverpkg=github.com/deislabs/ratify/plugins/verifier/sbom/... -o ./bin/plugins/ ./plugins/verifier/sbom
-	go build -cover -coverpkg=github.com/deislabs/ratify/plugins/verifier/schemavalidator/... -o ./bin/plugins/ ./plugins/verifier/schemavalidator
-	go build -cover -coverpkg=github.com/deislabs/ratify/plugins/verifier/vulnerabilityreport/... -o ./bin/plugins/ ./plugins/verifier/vulnerabilityreport
+	go build -cover -coverpkg=github.com/ratify-project/ratify/plugins/verifier/licensechecker/... -o ./bin/plugins/ ./plugins/verifier/licensechecker
+	go build -cover -coverpkg=github.com/ratify-project/ratify/plugins/verifier/sample/... -o ./bin/plugins/ ./plugins/verifier/sample
+	go build -cover -coverpkg=github.com/ratify-project/ratify/plugins/referrerstore/sample/... -o ./bin/plugins/referrerstore/ ./plugins/referrerstore/sample
+	go build -cover -coverpkg=github.com/ratify-project/ratify/plugins/verifier/sbom/... -o ./bin/plugins/ ./plugins/verifier/sbom
+	go build -cover -coverpkg=github.com/ratify-project/ratify/plugins/verifier/schemavalidator/... -o ./bin/plugins/ ./plugins/verifier/schemavalidator
+	go build -cover -coverpkg=github.com/ratify-project/ratify/plugins/verifier/vulnerabilityreport/... -o ./bin/plugins/ ./plugins/verifier/vulnerabilityreport
 
 .PHONY: install
 install:
@@ -572,7 +572,7 @@ load-local-ratify-image:
 	kind load docker-image --name kind localbuild:test
 
 e2e-helmfile-deploy-released-ratify:
-	./.staging/helmfilebin/helmfile sync -f git::https://github.com/deislabs/[email protected]
+	./.staging/helmfilebin/helmfile sync -f git::https://github.com/ratify-project/[email protected]
 
 e2e-helm-deploy-ratify:
 	printf "{\n\t\"auths\": {\n\t\t\"registry:5000\": {\n\t\t\t\"auth\": \"`echo "${TEST_REGISTRY_USERNAME}:${TEST_REGISTRY_PASSWORD}" | tr -d '\n' | base64 -i -w 0`\"\n\t\t}\n\t}\n}" > mount_config.json

README.md

@@ -6,9 +6,9 @@
 
 Is a verification engine as a binary executable and on Kubernetes which enables verification of artifact security metadata and admits for deployment only those that comply with policies you create.
 
-[![Go Report Card](https://goreportcard.com/badge/github.com/deislabs/ratify)](https://goreportcard.com/report/github.com/deislabs/ratify)
-[![build-pr](https://github.com/deislabs/ratify/actions/workflows/build-pr.yml/badge.svg)](https://github.com/deislabs/ratify/actions/workflows/build-pr.yml)
-[![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/deislabs/ratify/badge)](https://api.securityscorecards.dev/projects/github.com/deislabs/ratify)
+[![Go Report Card](https://goreportcard.com/badge/github.com/ratify-project/ratify)](https://goreportcard.com/report/github.com/ratify-project/ratify)
+[![build-pr](https://github.com/ratify-project/ratify/actions/workflows/build-pr.yml/badge.svg)](https://github.com/ratify-project/ratify/actions/workflows/build-pr.yml)
+[![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/ratify-project/ratify/badge)](https://api.securityscorecards.dev/projects/github.com/ratify-project/ratify)
 [![Go Reference](https://pkg.go.dev/badge/github.com/deislabs/ratify.svg)](https://pkg.go.dev/github.com/deislabs/ratify)
 
 ## Table of Contents

RELEASES.md

@@ -45,18 +45,18 @@ Applicable fixes, including security fixes, may be backported to supported relea
 
 ### Minor releases
 
-When a minor release is required, the release commits should be merged with the `main` branch when ready.   
+When a minor release is required, the release commits should be merged with the `main` branch when ready.
 
-  - Alpha and Beta releases will be cut from the main branch. 
-  - For RC and stable releases, a new branch `release-X.Y` will be created from `main`. Required changes for the minor release should be PRed to the `dev`  branch, the change will then be cherry picked to `release-X.Y` from `main`.
+* Alpha and Beta releases will be cut from the main branch.
+* For RC and stable releases, a new branch `release-X.Y` will be created from `main`. Required changes for the minor release should be PRed to the `dev`  branch, the change will then be cherry picked to `release-X.Y` from `main`.S
 
 ### Major releases
 
 When a major release is required, the release commits should be merged with the `main` branch when ready.  Major versions will usually require multiple pre-release versions. Similar to minor releases, the new branch should be created for the RC and stable release.
 
 ### Tag and Release
 
-**X.Y.Z** refers to the version (git tag) of Ratify that is released. Prepare the release with a [PR](https://github.com/deislabs/ratify/pull/1031/files) to update the chart value. When the `release-X.Y` branch is ready, a tag **X.Y.Z** should be pushed. e.g. `git tag v1.1.1` and `git push --tags`.  This will trigger a [Goreleaser](https://goreleaser.com/) action that will build the binaries and creates a [GitHub release](https://help.github.com/articles/creating-releases/):
+**X.Y.Z** refers to the version (git tag) of Ratify that is released. Prepare the release with a [PR](https://github.com/ratify-project/ratify/pull/1031/files) to update the chart value. When the `release-X.Y` branch is ready, a tag **X.Y.Z** should be pushed. e.g. `git tag v1.1.1` and `git push --tags`.  This will trigger a [Goreleaser](https://goreleaser.com/) action that will build the binaries and creates a [GitHub release](https://help.github.com/articles/creating-releases/):
 
 * The release will be marked as a draft to allow an final editing before publishing.
 * The release notes and other fields can edited after the action completes.  The description can be in Markdown.
@@ -65,6 +65,7 @@ When a major release is required, the release commits should be merged with the
   * The files are named `ratify_<major>-<minor>-<patch>_<OS>_<ARCH>` with `.zip` files for Windows and `.tar.gz` for all others.
 
 ## Supported Releases
+
 Applicable fixes, including security fixes, may be cherry-picked into the release branch, depending on severity and feasibility. Patch releases are cut from that branch as needed.
 
 We expect to "support" n (current). "Support" means we expect users to be running that version in production. For example, when v1.2 comes out, v1.1 will no longer be supported for patches, and we encourage users to upgrade to a supported version as soon as possible.
@@ -73,7 +74,7 @@ We expect to "support" n (current). "Support" means we expect users to be runnin
 
 Ratify is assumed to be compatible with [GateKeeper Supported Versions](https://github.com/open-policy-agent/gatekeeper/blob/master/docs/Release_Management.md#supported-releases) and the [current Kubernetes Supported Versions](https://kubernetes.io/releases/patch-releases/#detailed-release-history-for-active-branches) per [Kubernetes Supported Versions policy](https://kubernetes.io/releases/version-skew-policy/).
 
-For example, if Gatekeeper _supported_ versions are v3.13 and v3.14, and Kubernetes _supported_ versions are v1.28, v1.29, then current version of Ratify (v1.2) are assumed to be compatible with all supported Kubernetes versions (v1.28, v1.29) and Gatekeeper version(v3.13, v3.14). 
+For example, if Gatekeeper _supported_ versions are v3.13 and v3.14, and Kubernetes _supported_ versions are v1.28, v1.29, then current version of Ratify (v1.2) are assumed to be compatible with all supported Kubernetes versions (v1.28, v1.29) and Gatekeeper version(v3.13, v3.14).
 
 ## Post Release Activity
 
@@ -82,23 +83,27 @@ After a successful release, please manually trigger [quick start action](.github
 ### Weekly Dev Release
 
 #### Publishing Guidelines
-- Ratify is configured to generate and publish dev build images based on the schedule [here](https://github.com/ratify-project/ratify/blob/main/.github/workflows/publish-package.yml#L8). 
-- Contributors MUST select the `Helm Chart Change` option under the `Type of Change` section if there is ANY update to the helm chart that is required for proposed changes in PR.
-- Maintainers MUST manually trigger the "Publish Package" workflow after merging any PR that indicates `Helm Chart Change`
-  - Go to the `Actions` tab for the Ratify repository
-  - Select `publish-ghcr` option from list of workflows on left pane
-  - Select the `Run workflow` drop down on the right side above the list of action runs
-  - Choose `Branch: main`
-  - Select `Run workflow`
-- Process to Request an off-schedule dev build be published
-  - Submit a new feature request issue prefixed with `[Dev Build Request]`
-  - In the the `What this PR does / why we need it` section, briefly explain why an off schedule build is needed
-  - Once issue is created, post in the `#ratify` slack channel and tag the maintainers
-  - Maintainers should acknowledge request by approving/denying request as a follow up comment
+
+* Ratify is configured to generate and publish dev build images based on the schedule [here](https://github.com/ratify-project/ratify/blob/main/.github/workflows/publish-package.yml#L8).
+* Contributors MUST select the `Helm Chart Change` option under the `Type of Change` section if there is ANY update to the helm chart that is required for proposed changes in PR.
+* Maintainers MUST manually trigger the "Publish Package" workflow after merging any PR that indicates `Helm Chart Change`
+  * Go to the `Actions` tab for the Ratify repository
+  * Select `publish-ghcr` option from list of workflows on left pane
+  * Select the `Run workflow` drop down on the right side above the list of action runs
+  * Choose `Branch: main`
+  * Select `Run workflow`
+* Process to Request an off-schedule dev build be published
+  * Submit a new feature request issue prefixed with `[Dev Build Request]`
+  * In the the `What this PR does / why we need it` section, briefly explain why an off schedule build is needed
+  * Once issue is created, post in the `#ratify` slack channel and tag the maintainers
+  * Maintainers should acknowledge request by approving/denying request as a follow up comment
+
 #### How to use a dev build
+
 1. The `ratify` image and `ratify-crds` image for dev builds exist as separate packages on Github [here](https://github.com/ratify-project/ratify/pkgs/container/ratify-dev) and [here](https://github.com/ratify-project/ratify/pkgs/container/ratify-crds-dev).
 2. the `repository` `crdRepository` and `tag` fields must be updated in the helm chart to point to dev build instead of last released build. Please set the tag to be latest tag found at the corresponding `-dev` suffixed package. An example install command scaffold:
-```
+
+```bash
 helm install ratify \
     ./charts/ratify --atomic \
     --namespace gatekeeper-system \
@@ -107,4 +112,5 @@ helm install ratify \
     --set image.tag=dev.<YYYYMMDD>.<ABBREVIATED_GIT_HASH_COMMIT>
     --set-file notationCerts[0]=./test/testdata/notation.crt
 ```
+
 NOTE: the tag field is the only value that will change when updating to newer dev build images