From 6d4f963e268df83ffdf2822ff84994e2e4a61633 Mon Sep 17 00:00:00 2001 From: Simon Baird Date: Thu, 23 Jan 2025 12:36:39 -0500 Subject: [PATCH] Big search and replace name change Change Enterprise Contract and EC to "Conforma", (except when we're talking about ECP CRs). Avoid being left with "the Conforma" when it's not gramatically appropriate. The glossary might need some further attention, but at this stage I'm just aiming to get the easy changes done. --- README.md | 10 ++-- modules/ROOT/pages/cli.adoc | 6 +-- modules/ROOT/pages/configuration.adoc | 16 +++---- modules/ROOT/pages/custom-config.adoc | 8 ++-- modules/ROOT/pages/custom-data.adoc | 24 +++++----- modules/ROOT/pages/getting-started.adoc | 20 ++++---- modules/ROOT/pages/glossary.adoc | 4 +- modules/ROOT/pages/hitchhikers-guide.adoc | 14 +++--- modules/ROOT/pages/index.adoc | 9 +++- .../pages/reproducing-an-rhtap-report.adoc | 10 ++-- modules/ROOT/pages/slsa.adoc | 46 +++++++++---------- modules/ROOT/partials/contents.adoc | 8 ++-- 12 files changed, 91 insertions(+), 84 deletions(-) diff --git a/README.md b/README.md index 006ebdc..7dc5bdb 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,10 @@ -Enterprise Contract User Guide -============================ +Conforma User Guide +=================== -Some high level documentation on how to use and configure Enterprise Contract -with Konflux CI. +Some high level documentation on how to use and configure Conforma, +particularly with Konflux CI. Uses Asciidoc and Antora. The published version should be viewable -[here](https://enterprisecontract.dev/docs/user-guide/). +[here](https://conforma.dev/docs/user-guide/). diff --git a/modules/ROOT/pages/cli.adoc b/modules/ROOT/pages/cli.adoc index af4c9b1..9a50ff8 100644 --- a/modules/ROOT/pages/cli.adoc +++ b/modules/ROOT/pages/cli.adoc @@ -1,5 +1,5 @@ -= Using the Enterprise Contract command line += Using the Conforma command line == Installation @@ -125,7 +125,7 @@ kubectl get -n openshift-pipelines secret public-key -o jsonpath='{.data.cosign\ ---- //// -If you've run EC at least once using an integration test, as described in +If you've run Conforma at least once using an integration test, as described in xref:getting-started.adoc[Getting started...], the public key is visible in the logs for the pipeline run. @@ -138,7 +138,7 @@ xref:ecc:ROOT:index.adoc[the configuration docs] for more information on the `policy.yaml` file, or take a look at the examples link:https://github.com/enterprise-contract/config[here]. -See also the how-to on xref:reproducing-an-rhtap-report.adoc[reproducing the Enterprise Contract output from a Konflux +See also the how-to on xref:reproducing-an-rhtap-report.adoc[reproducing the Conforma output from a Konflux integration test]. == Validating arbitrary inputs diff --git a/modules/ROOT/pages/configuration.adoc b/modules/ROOT/pages/configuration.adoc index a40aec0..c7acb83 100644 --- a/modules/ROOT/pages/configuration.adoc +++ b/modules/ROOT/pages/configuration.adoc @@ -1,20 +1,20 @@ -= Enterprise Contract Configuration += Conforma Configuration -Enterprise Contract configuration is described xref:ecc:ROOT:index.adoc[here]. +Conforma configuration is described xref:ecc:ROOT:index.adoc[here]. -The configuration used by EC can be provided by an +The configuration used by Conforma can be provided by an xref:ecc:ROOT:reference.adoc[`EnterpriseContractPolicy` cluster resource], or it can be fetched from a git url. -For xref:cli.adoc[command line use] of Enterprise Contract a local file can also be used. +For xref:cli.adoc[command line use] of Conforma a local file can also be used. There are some pre-defined configuration files available link:https://github.com/enterprise-contract/config[here]. == Finding the configuration used -The output of the Enterprise Contract task includes a copy of the configuration +The output of the Conforma task includes a copy of the configuration used. You can find it under the `policy` key in the raw YAML output where it can be copy and pasted. @@ -23,12 +23,12 @@ image::c64db6a88c99447507fb87e42c966fda.png[] TIP: Notice that the public key used to verify both the signed images and the signed attestations created by Tekton Chains is available in the YAML output -also. This public key is useful if you want to use Enterprise Contract outside the +also. This public key is useful if you want to use Conforma outside the Konflux cluster as described xref:cli.adoc[here]. -== Modifying the Enterprise Contract configuration used in Konflux +== Modifying the Conforma configuration used in Konflux -To change which configuration is used by the Enterprise Contract integration +To change which configuration is used by the Conforma integration test, it is necessary to modify the applicable "IntegrationTestScenario" cluster resouce. diff --git a/modules/ROOT/pages/custom-config.adoc b/modules/ROOT/pages/custom-config.adoc index 4e52a2e..b53db0a 100644 --- a/modules/ROOT/pages/custom-config.adoc +++ b/modules/ROOT/pages/custom-config.adoc @@ -58,7 +58,7 @@ available] in that same repo. You can of course substitute your own git repo with your own customized policy file. NOTE: The `//` syntax in the git url is used to separate the git repo location -and the subdirectory inside the git repo. EC will look for a `policy.yaml` or +and the subdirectory inside the git repo. Conforma will look for a `policy.yaml` or `.ec/policy.yaml` file in the directory specified, or at the top level of the git repo if no directory is specified. For details on this syntax consult the link:https://github.com/hashicorp/go-getter#url-format[go-getter documentation]. @@ -80,7 +80,7 @@ kind: EnterpriseContractPolicy metadata: name: ec-policy spec: - description: An example custom EC policy + description: An example custom Conforma policy publicKey: k8s://openshift-pipelines/public-key sources: - name: Release policies @@ -140,7 +140,7 @@ policy configuration parameter value. == Retriggering the integration test There's currently no way to retrigger just the integration test, so to rerun -the Enterprise Contract pipeline a retrigger of the build pipeline is required. +the Conforma pipeline a retrigger of the build pipeline is required. This can be achieved by opening a new PR, typing `/retest` in an existing PR, or by pushing a commit to `main` branch. An empty commit works fine, so you @@ -151,6 +151,6 @@ could do this for example: $ git commit -m "Trigger a Konflux rebuild" --allow-empty && git push origin main ---- -For testing and debugging Enterprise Contract policies conveniently on your +For testing and debugging Conforma policies conveniently on your workstation, you can use command line ec xref:cli.adoc[as described here]. diff --git a/modules/ROOT/pages/custom-data.adoc b/modules/ROOT/pages/custom-data.adoc index 179848d..ed17b60 100644 --- a/modules/ROOT/pages/custom-data.adoc +++ b/modules/ROOT/pages/custom-data.adoc @@ -1,5 +1,5 @@ -= Customizing EC data += Customizing Conforma data I'll work through real-world example. @@ -37,7 +37,7 @@ kubectl get -n openshift-pipelines secret public-key -o json | jq -r '.data."cos kubectl get -n enterprise-contract-service enterprisecontractpolicy default -o yaml | yq .spec > policy.yml ---- -== Running EC locally +== Running Conforma locally Install ec as per xref:cli.adoc[these instructions] then do the following. @@ -54,7 +54,7 @@ ec validate image --image $IMAGE --public-key cosign.pub --policy "$(yq -ojson - In the above example we downloaded the public key and the policy, but since we -have cluster access, it's not actually required. EC can find the public key and +have cluster access, it's not actually required. Conforma can find the public key and the policy configuration in the cluster. For example we can do this, which should give the same result: @@ -102,7 +102,7 @@ sources: - '@minimal' ---- -Notice that the EC is currently passing. There are no violations and the top +Notice that Conforma is currently passing. There are no violations and the top level success value is `true`. == Modify the policy so all rules are applied @@ -119,9 +119,9 @@ You can also use ec to produce a list of the rules like this: ec inspect policy --source quay.io/enterprise-contract/ec-release-policy --collection minimal --output text ---- -By default EC applies all the rules found in the policy source. So we can just remove the collection configuration to make this happen. +By default Conforma applies all the rules found in the policy source. So we can just remove the collection configuration to make this happen. -Let's do that and re-run the EC locally. +Let's do that and re-run Conforma locally. Edit the policy.yml file: @@ -140,7 +140,7 @@ NOTE: To make these examples tidier I removed some `description` and `name` fields that won't be consequential. You can leave them alone or modify them if you wish. -Running the EC with this new policy configuration produces some violations: +Running Conforma with this new policy configuration produces some violations: [.console-input] [source, bash] @@ -339,9 +339,9 @@ link:https://github.com/simonbaird/ec-data-demos/blob/example1/step_registry_pre here]. That's not a real registry prefix of course, but let's start with that and see -what results EC produces. +what results Conforma produces. -=== Configuring EC to use the data source +=== Configuring Conforma to use the data source Let's modify the `policy.yml` file to add an extra data source: @@ -399,7 +399,7 @@ Step 4 in task 'build-container' has disallowed image ref 'registry.access.redha Step 5 in task 'build-container' has disallowed image ref 'quay.io/konflux-ci/cosign@sha256:18b3716a6225727877475e1ab4f2493915e72cffd2ce431e9901d2ed2e4b2c0b' ---- -As you might have predicted, EC is now reporting that all the steps are using disallowed image refs. +As you might have predicted, Conforma is now reporting that all the steps are using disallowed image refs. Let's fix that now. Back in the git repo for your custom data source, modify `step_registry_prefixes/data.yml` to look like this: @@ -456,7 +456,7 @@ key: ... == Adding a custom policy source Now imagine your organization has a need for a custom policy. A policy that doesn't exactly fit in -with the default. The solution is to create a custom policy repo and apply that to your next EC run. +with the default. The solution is to create a custom policy repo and apply that to your next Conforma run. === Creating the custom policy source To create a custom policy, we'll start by creating a git repo for it. @@ -508,7 +508,7 @@ deny contains result if { ---- The above policy will throw a violation if a task named `myorg-task` is not found in the build. -=== Configuring EC to use the custom policy source +=== Configuring Conforma to use the custom policy source Let's modify the `policy.yml` file to add an extra policy source: .policy.yaml diff --git a/modules/ROOT/pages/getting-started.adoc b/modules/ROOT/pages/getting-started.adoc index c895ea8..f1a9533 100644 --- a/modules/ROOT/pages/getting-started.adoc +++ b/modules/ROOT/pages/getting-started.adoc @@ -1,15 +1,15 @@ -= Getting started with Enterprise Contract & Konflux CI += Getting started with Conforma & Konflux CI == Creating an application If you don't already have an application defined in Konflux, follow the link:https://konflux-ci.dev/docs/how-tos/creating/[guide]. Once that's done you should have an application with at least one component. -To get the most out of Enterprise Contract, be sure to follow the steps in the guide so Konflux sends a pull request to your repository to define a custom build pipeline in your GitHub repository. +To get the most out of Conforma, be sure to follow the steps in the guide so Konflux sends a pull request to your repository to define a custom build pipeline in your GitHub repository. == Creating an integration test -To run the Enterprise Contract pipeline automatically after each build, an integration test is +To run the Conforma pipeline automatically after each build, an integration test is used. One should be automatically created when a new application is created. The process of recreating it manually is link:https://konflux-ci.dev/docs/advanced-how-tos/managing-compliance-with-ec/[described here]. @@ -29,21 +29,21 @@ pipeline definition in its git repo instead of as a Tekton bundle image reference. It's expected this will become the preferred way to specify the integration test pipeline. -== Viewing Enterprise Contract results +== Viewing Conforma results -With the Enterprise Contract integration test created, each successful build +With the Conforma integration test created, each successful build pipeline run will trigger an integration test pipeline run. You can find the integration test pipeline runs by clicking the integration test under the "Integration Tests" tab. -The Enterprise Contract results can be seen under the "Security" tab, for example -this shows a passing Enterprise Contract test: +The Conforma results can be seen under the "Security" tab, for example +this shows a passing Conforma test: -.Enterprise Contract results in the "Security" tab +.Conforma results in the "Security" tab image::05a225eebbec005e079a084226e869f3.png[] -The raw output from the Enterprise Contract task is YAML formatted and can be +The raw output from the Conforma task is YAML formatted and can be seen in the pipeline run logs, particularly under the "STEP-REPORT" heading: -.Raw Enterprise Contract results in the task log +.Raw Conforma results in the task log image::0dfd56dd2c4d8d000ab18e9d8a75bf99.png[] diff --git a/modules/ROOT/pages/glossary.adoc b/modules/ROOT/pages/glossary.adoc index afbd81c..8a4f5db 100644 --- a/modules/ROOT/pages/glossary.adoc +++ b/modules/ROOT/pages/glossary.adoc @@ -1,6 +1,6 @@ = Glossary -Here is a list of terms we use when discussing Enterprise Contracts +Here is a list of terms we use when discussing Conforma. :toc: @@ -9,6 +9,8 @@ Here is a list of terms we use when discussing Enterprise Contracts A set of requirements imposed upon software delivery artifacts implemented in a <<_enterprise_contract_policy>> fulfilling a gating role allowing or preventing a release of these artifacts +Also, Enterprise Contract is the former name for Conforma. + [[_enterprise_contract_policy]] == Enterprise Contract Policy diff --git a/modules/ROOT/pages/hitchhikers-guide.adoc b/modules/ROOT/pages/hitchhikers-guide.adoc index d63a3e7..9fbec18 100644 --- a/modules/ROOT/pages/hitchhikers-guide.adoc +++ b/modules/ROOT/pages/hitchhikers-guide.adoc @@ -1,8 +1,8 @@ -= Hitchhiker's Guide to Enterprise Contract += Hitchhiker's Guide to Conforma -The Enterprise Contract can be used to validate a software artifact, e.g. a container image, that +Conforma can be used to validate a software artifact, e.g. a container image, that has already been signed and attested. This document assumes you do not have such an artifact. It -walks you through the process of signing and attesting a container image, then how to use EC to +walks you through the process of signing and attesting a container image, then how to use Conforma to validate those operations. == Required Tooling @@ -147,11 +147,11 @@ $ cosign tree "$REPOSITORY:latest" ---- -We are ready to verify the image with the Enterprise Contract CLI! +We are ready to verify the image with the Conforma CLI! == Basic Verification -The most basic verification that can be done with the EC cli is to verify the image has a signature +The most basic verification that can be done with the Conforma cli is to verify the image has a signature and a SLSA Provenance attestation matching a given public key. [source, bash] @@ -214,7 +214,7 @@ The above contains a single policy rule that ensure the `builder.id` in the SLSA the expected value. The `METADATA` comment block is rego's way to specify -https://www.openpolicyagent.org/docs/latest/policy-language/#metadata[annotations] for rules. EC +https://www.openpolicyagent.org/docs/latest/policy-language/#metadata[annotations] for rules. Conforma leverages this in order to provide additional information in its report, see https://enterprisecontract.dev/docs/ec-policies/authoring.html#_rule_annotations[here]. @@ -269,7 +269,7 @@ violations: == Conclusion -I hope you enjoyed this high level overview of the Enterprise Contract. You are now officially an EC +I hope you enjoyed this high level overview of Conforma. You are now officially a Conforma Hero! By the way, once you are done experimenting, it is a good idea to tear down the local container diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc index c9fbeb3..ff521b4 100644 --- a/modules/ROOT/pages/index.adoc +++ b/modules/ROOT/pages/index.adoc @@ -1,9 +1,14 @@ -= Enterprise Contract User Guide += Conforma Contract User Guide -This documentation will describe how to use Enterprise Contract, particularly +This documentation describes how to use Conforma, particularly with link:https://github.com/konflux-ci[Konflux CI]. +NOTE: Conforma was previously known as "Enterprise Contract". You can consider +"Conforma" and "Enterprise Contract" to be synonynous. See +link:/posts/whats-in-a-name/[this article] for more details about the name +change. + See also the link:https://konflux-ci.dev/docs/[Konflux-CI Documentation]. == Contents diff --git a/modules/ROOT/pages/reproducing-an-rhtap-report.adoc b/modules/ROOT/pages/reproducing-an-rhtap-report.adoc index 9c5dd24..13af55a 100644 --- a/modules/ROOT/pages/reproducing-an-rhtap-report.adoc +++ b/modules/ROOT/pages/reproducing-an-rhtap-report.adoc @@ -1,13 +1,13 @@ -= Reproducing a Konflux Enterprise Contract report locally += Reproducing a Konflux Conforma report locally This requires that you installed `ec` locally as described in -xref:cli.adoc[Command line EC], and that you have at least one Enterprise +xref:cli.adoc[Command line Conforma], and that you have at least one Enterprise Contract integration test pipeline run in your Konflux environment. include::partial$oc_login.adoc[] Run the following commands to extract the raw YAML output from the most recent -Enterprise Contract pipeline run. +Conforma pipeline run. [,bash] ---- @@ -16,7 +16,7 @@ POD_NAME=$( kubectl get $TR_NAME -o jsonpath='{.status.podName}' ) kubectl logs -c step-report $POD_NAME | tee ec-report.yaml ---- -Extract some useful parts of the EC report output and save them to files. +Extract some useful parts of the Conforma report output and save them to files. [,bash] ---- @@ -31,7 +31,7 @@ Extracting the components list is similar, but a little more complicated. Note t yq -o json '{"components":.components.[] | [{"name":.name, "containerImage":.containerImage}]}' ec-report.yaml | tee snapshot.json ---- -With the snapshot file, the public key and the policy file, we can reproduce the Enterprise Contract output like this: +With the snapshot file, the public key and the policy file, we can reproduce the Conforma output like this: [,bash] ---- diff --git a/modules/ROOT/pages/slsa.adoc b/modules/ROOT/pages/slsa.adoc index 428f91a..d4ddf76 100644 --- a/modules/ROOT/pages/slsa.adoc +++ b/modules/ROOT/pages/slsa.adoc @@ -1,20 +1,20 @@ -= Konflux CI, Enterprise Contract, and SLSA += Konflux CI, Conforma, and SLSA .Overview **** Konflux CI is a build and CI/CD system that aims to meet or exceed https://slsa.dev/spec/v1.0/levels[SLSA Build L3 (v1.0)]. -Enterprise Contract is an +Conforma is an https://slsa.dev/spec/v1.0/verifying-artifacts[artifact verifier] and customizable policy checker designed to be easily integrated with Konflux's CI/CD workflows. -A lot of the default policies created for Konflux and enforced by EC are closely +A lot of the default policies created for Konflux and enforced by Conforma are closely related to SLSA requirements, based on both the recent SLSA v1.0, and the older SLSA v0.1 specification. In this documentation we'll describe in more detail -how Konflux and EC work together to provide a high standard of supply chain +how Konflux and Conforma work together to provide a high standard of supply chain security, informed and guided by the link:https://slsa.dev/[SLSA specifications]. @@ -22,10 +22,10 @@ specifications]. == SLSA Requirements -=== SLSA requirements verified explicitly by Enterprise Contract +=== SLSA requirements verified explicitly by Conforma -Enterprise Contract comes with a set of policy rules designed for use with -Konflux. Using EC to verify that a build passes all the checks defined by the +Conforma comes with a set of policy rules designed for use with +Konflux. Using Conforma to verify that a build passes all the checks defined by the policy provides a high level of confidence that the build was built securely and can be trusted. @@ -33,7 +33,7 @@ Many of the policy rules are linked to specific SLSA requirements, for example: [cols="1,1,3"] |=== -|SLSA reference|EC policy rule|Notes +|SLSA reference|Conforma policy rule|Notes a| https://slsa.dev/spec/v0.1/requirements#scripted-build[Scripted build (v0.1)] a| xref:ec-policies:ROOT:release_policy.adoc#slsa_build_scripted_build__build_script_used[Build task contains steps] @@ -51,7 +51,7 @@ described in SLSA v1.0. a| https://slsa.dev/spec/v0.1/requirements#hermetic[Hermetic Builds (v0.1)] a| xref:ec-policies:ROOT:release_policy.adoc#hermetic_build_task__build_task_hermetic[Build task called with hermetic param set] a| This rule verifies that the build task was called with a particular parameter specifying the build should be done hermeticly. This rule is specific -to Konflux's task definitions, since EC isn't able to explicitly confirm that the build was indeed hermetic. But, when combined with the strictest +to Konflux's task definitions, since Conforma isn't able to explicitly confirm that the build was indeed hermetic. But, when combined with the strictest xref:ec-policies:ROOT:release_policy.adoc#trusted_task__trusted[trusted tasks rule], and a trustable source for the task definition, we can use the rule to ensure that only builds performed hermeticly can be released. @@ -64,25 +64,25 @@ is the default used by Tekton Chains, though this may change in the future.) a| https://slsa.dev/spec/v1.0/threats#f-upload-modified-package[Threat (G) - Upload modified package], https://slsa.dev/spec/v1.0/threats#h-use-compromised-package[Threat (H) - Use compromised package] (v1.0) a| xref:ec-policies:ROOT:release_policy.adoc#builtin_image__signature_check[Image signature check passed] -a| Enterprise Contract uses a public key to validate the signature of the image using https://docs.sigstore.dev/cosign/overview/[Cosign]. If the image +a| Conforma uses a public key to validate the signature of the image using https://docs.sigstore.dev/cosign/overview/[Cosign]. If the image signature can't be verified for any reason, a failure will be reported. There are other ways to verify image signatures, e.g. by using `cosign` directly, -but EC will happily do it for you. +but Conforma will happily do it for you. -There is also experimental support in EC for validating signatures for images signed keylessly +There is also experimental support in Conforma for validating signatures for images signed keylessly using https://docs.sigstore.dev/fulcio/overview/[Sigstore Fulcio], though Konflux currently uses long-lived signing keys to sign images and attestations. a| https://slsa.dev/spec/v1.0/verifying-artifacts[Verifying Artifacts (v1.0)] a| xref:ec-policies:ROOT:release_policy.adoc#builtin_attestation__signature_check[Attestation signature check passed] -a| As well as verifying the image signature, EC also verifies the signature of the attestation, which is an important part of the artifact +a| As well as verifying the image signature, Conforma also verifies the signature of the attestation, which is an important part of the artifact verification process. For Konflux the same key is used to sign the attestation and the image itself. As mentioned above, there is experimental support for verifying keylessly signed attestations. a| https://slsa.dev/spec/v1.0/verifying-artifacts#step-1-check-slsa-build-level[Verifying Artifacts (v1.0)] a| xref:ec-policies:ROOT:release_policy.adoc#slsa_build_scripted_build__subject_build_task_matches[Provenance subject matches build task image result] a| SLSA recommends an artifact verifier checks that the provenance statement’s subject matches the digest of the artifact in question. -This is a good sanity check to confirm that the provenance being considered is for the expected image. Because EC uses Cosign under the hood, and -Cosign does this check as part of its signature verification, we get this confirmed automatically. The EC rule linked here performs an additional +This is a good sanity check to confirm that the provenance being considered is for the expected image. Because Conforma uses Cosign under the hood, and +Cosign does this check as part of its signature verification, we get this confirmed automatically. The Conforma rule linked here performs an additional confirmation by comparing the image reference produced by the build task and confirming that also matches the provenance subject. a| https://slsa.dev/spec/v1.0/verifying-artifacts#step-1-check-slsa-build-level[Verifying Artifacts (v1.0)] @@ -98,10 +98,10 @@ task match what appears in the "materials" provenance. |=== -=== SLSA requirements not explicitly verified by Enterprise Contract +=== SLSA requirements not explicitly verified by Conforma There are numerous SLSA Build requirements that are met by Konflux CI, but not -explicitly verifiable with an Enterprise Contract policy rule. We won't go +explicitly verifiable with an Conforma policy rule. We won't go into depth in this document, but for example: [cols="1,3"] @@ -110,7 +110,7 @@ into depth in this document, but for example: a| https://slsa.dev/spec/v1.0/levels#build-l2-hosted-build-platform[Build L2: Hosted build platform] a| Due to its design, its architecture, and operational management, Konflux CI, -meets these requirements implicitly. And, as we've seen above, the Enterprise Contract +meets these requirements implicitly. And, as we've seen above, Conforma can be used to verify the authenticity of the signed provenances. a| https://slsa.dev/spec/v1.0/levels#build-l3-hardened-builds[Build L3: Hardened builds] @@ -126,19 +126,19 @@ Linking to a general system overview of Konflux would also be useful here also I == Notes and caveats -Because EC was designed initially for use with Konflux, and Konflux uses Tekton +Because Conforma was designed initially for use with Konflux, and Konflux uses Tekton CI/CD, many of the specific rules mentioned above are currently Tekton specific in that they use details about the Tekton pipeline run, which are currently made available in the SLSA attestation created by Tekton Chains. -This is not a limitation of EC itself, but rather just an attribute of the +This is not a limitation of Conforma itself, but rather just an attribute of the xref:ec-policies:ROOT:release_policy.adoc[policies created for Konflux] in their current state. In the future we're aiming to extract the Tekton specific rules from the general SLSA rules to make the rules more generally applicable. We expected that policy rules for build systems not based on Tekton and Tekton Chains could be created easily. -Note also that since EC can conveniently apply any policy defined in +Note also that since Conforma can conveniently apply any policy defined in https://www.openpolicyagent.org/docs/latest/policy-language/[OPA/Rego], it is able to be used for a wide range of purposes, e.g. to verify certain tests were run and passed, and to apply any business specific release policies. Browse the @@ -147,10 +147,10 @@ what other rules have been defined for use by Konflux within Red Hat. == Conclusion -Enterprise Contract can be used as a convenient and customizable SLSA artifact +Conforma can be used as a convenient and customizable SLSA artifact verifier. It's doing that now within Konflux, and we think it's capable and flexible enough to become a part of other build systems where supply chain security is a priority. If you have questions, or want to provide feedback, please reach out to the -Enterprise Contract team via https://github.com/enterprise-contract[GitHub]. +Conforma team via https://github.com/enterprise-contract[GitHub]. diff --git a/modules/ROOT/partials/contents.adoc b/modules/ROOT/partials/contents.adoc index 9e43627..2290483 100644 --- a/modules/ROOT/partials/contents.adoc +++ b/modules/ROOT/partials/contents.adoc @@ -4,12 +4,12 @@ * How-to guides ** xref:cosign.adoc[Using Cosign] -** xref:cli.adoc[Command line EC] -** xref:reproducing-an-rhtap-report.adoc[Reproducing a Konflux EC report locally] +** xref:cli.adoc[Command line Conforma] +** xref:reproducing-an-rhtap-report.adoc[Reproducing a Konflux Conforma report locally] ** xref:custom-config.adoc[Using custom configuration] ** xref:custom-data.adoc[Using custom data] -** xref:hitchhikers-guide.adoc[Hitchhiker's Guide to EC] +** xref:hitchhikers-guide.adoc[Hitchhiker's Guide to Conforma] -* xref:slsa.adoc[EC & SLSA] +* xref:slsa.adoc[Conforma & SLSA] * xref:glossary.adoc[Glossary]