Revert "sc: add Tobin to SC for NVIDIA"

This has to be approved by 2/3rds of the SC.

Signed-off-by: Tobin Feldman-Fitzthum <tfeldmanfitz@nvidia.com>

.github/ISSUE_TEMPLATE/release-check-list.md

@@ -20,6 +20,7 @@ flowchart LR
     Guest-Components .-> Client-tool
     Guest-Components --> enclave-agent
     enclave-cc --> kustomization.yaml
+    Operator --> versions.yaml
     Guest-Components --> versions.yaml
     Trustee --> versions.yaml
     Kata --> versions.yaml
@@ -47,7 +48,8 @@ flowchart LR
 Starting with v0.9.0 the release process no longer involves centralized dependency management.
 In other words, when doing a CoCo release, we don't push the most recent versions of the subprojects
 into Kata and enclave-cc. Instead, dependencies should be updated during the normal process of development.
-Releases of most subprojects are now decoupled from releases of the CoCo project.
+After the release, we typically cut a release of the subprojects that reflects whatever commit was used
+in the Kata release.
 
 ## The Steps
 
@@ -72,13 +74,9 @@ Identify/create the bundles that we will release for Kata and enclave-cc.
     If you absolutely cannot use a Kata release,
     you can consider releasing one of these bundles.
 
-- [ ] 3. :eyes: **Create a peer pods release**
+### Update the Operator
 
-    Create a peer pods release based on the Kata release, by following the [documented flow](https://github.com/confidential-containers/cloud-api-adaptor/blob/main/docs/Release-Process.md).
-
-### Test Release with Operator
-
-- [ ] 4. :eyes: **Check operator pre-installation and open PR if needed**
+- [ ] 3. :eyes: **Check operator pre-installation and open PR if needed**
     
     The operator uses a pre-install container to setup the node.
     Check that the container matches the dependencies used in Kata
@@ -88,7 +86,7 @@ Identify/create the bundles that we will release for Kata and enclave-cc.
         * Compare the `nydus-snapshotter` version in Kata [versions.yaml](https://github.com/kata-containers/kata-containers/blob/main/versions.yaml) (search for `nydus-snapshotter` and check its `version` field) with the [Makefile](https://github.com/confidential-containers/operator/blob/main/install/pre-install-payload/Makefile) (check the `NYDUS_SNAPSHOTTER_VERSION` value) for the operator pre-install container.
             * **If they do not match, stop and open a PR now. In the PR, update the operator's Makefile to match the version used in kata. After the PR is merged, continue.**
 
-- [ ] 5. :wrench: **Open a PR to the operator to update the release artifacts**
+- [ ] 4. :wrench: **Open a PR to the operator to update the release artifacts**
 
     Update the operator to use the payloads identified in steps 1, 2, 3, and 4.
 
@@ -114,13 +112,39 @@ Identify/create the bundles that we will release for Kata and enclave-cc.
 
 ### Final Touches
 
-- [ ] 6. :trophy: **Cut an operator release using the GitHub release tool**
+- [ ] 5. :trophy: **Cut an operator release using the GitHub release tool**
+
+- [ ] 6. :wrench: **Create a peer pods release**
+
+    Create a peer pods release based on the Kata release, by following the [documented flow](https://github.com/confidential-containers/cloud-api-adaptor/blob/main/docs/Release-Process.md).
 
 - [ ] 7. :green_book: **Make sure to update the [release notes](https://github.com/confidential-containers/confidential-containers/tree/main/releases) and tag/release the confidential-containers repo using the GitHub release tool.**
 
-- [ ] 8. :hammer: **Poke Wainer Moschetta (@wainersm) to update the release to the OperatorHub. Find the documented flow [here](https://github.com/confidential-containers/operator/blob/main/docs/OPERATOR_HUB.md).**
-
 ### Post-release
 
-- [ ] 9. :wrench: **Open a PR to the operator to go back to latest payloads after release**
+- [ ] 8. :wrench: **Open a PR to the operator to go back to latest payloads after release**
     After the release, the operator's payloads need to go back to what they were (e.g. using "latest" instead of a specific commit sha). As an example, the v0.9.0-alpha1 release applied [these changes](https://github.com/confidential-containers/operator/pull/389/files). You should use `git revert -s` for this.
+
+- [ ] 9. :pushpin: **Tag the version of guest-components used in the release**.
+
+    Go look at [versions.yaml](https://github.com/kata-containers/kata-containers/blob/main/versions.yaml)
+    in Kata Containers and find the version of the guest-components that was used in the Kata release.
+    Tag this commit in guest-components with the latest version of guest components.
+    Note that the version of guest-components might not be the same as the version of CoCo.
+
+- [ ] 10. :scissors: **Cut a release of guest-components using GitHub release tool**
+
+- [ ] 11. :pushpin: **Tag the version of Trustee used in the release**
+
+    Follow the same process as step 9 but for Trustee.
+
+- [ ] 12. :scissors: **Cut a release of Trustee using GitHub release tool**
+
+- [ ] 13. :wrench: **Tag the Trustee release images**
+
+    Use the Trustee release helper script to push the CI images corresponding to the released hash
+    as the release images.
+
+- [ ] 14. :pushpin: **Tag the latest version of the website for the release**
+
+    Make sure the website is up-to-date for the latest release, and then tag the repo.

CONTRIBUTING.md

@@ -78,6 +78,8 @@ with the community as early as possible. Consider making an `RFC` issue
 that explains the changes. You might also try to break large contributions
 into smaller steps.
 
+Any new feature must be accompanied by new unit tests.
+
 ### Making a Pull Request
 
 If you aren't familiar with Git or the GitHub PR workflow, take a look at [this section](https://github.com/kata-containers/community/blob/main/CONTRIBUTING.md#github-workflow)

MAINTAINERS

@@ -10,7 +10,6 @@ magowan, James Magowan, IBM
 fitzthum, Tobin Feldman-Fitzthum, IBM
 jiazhang0, Zhang Jia, Alibaba
 jiangliu, Jiang Liu, Alibaba
-larrydewey, Larry Dewey, AMD
 ryansavino, Ryan Savino, AMD
 sameo, Samuel Ortiz, Rivos
 zvonkok, Zvonko Kaiser, NVIDIA

governance.md

@@ -85,9 +85,9 @@ Further, as leaders in the community, the SC members will make themselves famili
 
 The current members of the SC are:
 
-* Larry Dewey (@larrydewey) and Ryan Savino (@ryansavino) - AMD
+* Ryan Savino (@ryansavino) - AMD
 * Jiang Liu (@jiangliu) and Jia Zhang (@jiazhang0) - Alibaba
-* James Magowan (@magowan)  and Tobin Feldman-Fitzthum (@fitzthum) - IBM
+* James Magowan (@magowan) and Nina Goradia (@ninag) - IBM
 * Peter Zhu (@peterzcst) and Mikko Ylinen (@mythi) - Intel
 * Pradipta Banerjee (@bpradipt)  and Ariel Adam (@ariel-adam) - Red Hat
 * Samuel Ortiz (@sameo) - Rivos
@@ -97,6 +97,8 @@ The current members of the SC are:
 ### Emeritus Members
 
 * Dan Middleton [dcmiddle](https://github.com/dcmiddle) (he/him)
+* Larry Dewey (@larrydewey) - AMD
+* Tobin Feldman-Fitzthum (@fitzthum) - IBM
 
 #### Selection
 

guides/ephemeral_storage.md

@@ -47,7 +47,6 @@ spec:
       storage: 1Gi
   storageClassName: open-local-lvm
 ```
-Before deploy the workload, we can follow this [documentation](https://github.com/kata-containers/kata-containers/blob/CCv0/docs/how-to/how-to-build-and-test-ccv0.md) and use [ccv0.sh](https://github.com/kata-containers/kata-containers/blob/CCv0/docs/how-to/ccv0.sh) to enable CoCo console debug(optional, check whether working as expected).
 
 Create the workload:
 ```sh

releases/v0.15.0.md

@@ -0,0 +1,88 @@
+# Release Notes for v0.15.0
+
+Release Date: July 23rd, 2025
+
+This release is based on [3.19.1](https://github.com/kata-containers/kata-containers/releases/tag/3.19.1) of Kata Containers
+and [v0.11.0](https://github.com/confidential-containers/enclave-cc/releases/tag/v0.11.0) of enclave-cc.
+
+Trustee and the guest components use KBS protocol v0.4.0.
+
+Please see the [quickstart guide](https://confidentialcontainers.org/docs/getting-started/) or [project documentation](https://confidentialcontainers.org/docs) for more information.
+
+
+## What's New
+
+* Attestation can account for confidential devices attached to a guest in addition to the CPU.
+  So far only one confidential device is supported (the Deep Computing Unit from Hygon),
+  but more are coming soon.
+* The full (plaintext) Init-Data is transmitted to Trustee where it is provided as input
+  to the KBS policy. This allows KBS policies to check configuration fields in the Init-Data.
+* The image-rs registry config file can be specified directly in the CDH config, allowing it
+  to be provisioned via Init-Data.
+* Trustee has Prometheus support, allowing admins to track attestation metrics. 
+* Trustee can store resources with HashiCorp Vault.
+* Trustee can be configured to allow cross-origin requests, such as from browser-based tools.
+* Trustee supports reference values of any type that can be represented as JSON including
+  complex types like maps and lists.
+* The KBS-Client can be used to set reference values of multiple types using the KBS admin
+  interface.
+* Trustee has more sophisticated [CC eventlog](https://uefi.org/specs/UEFI/2.11/38_Confidential_Computing.html#virtual-platform-cc-event-log) parsing, allowing boot information to be parsed into TCB claims.
+* When using Trustee with Docker compose, the required admin keypair is automatically generated. 
+* Trustee can attest SNP guests on Milan, Genoa, and Turin hosts with report version 3 or 4.
+
+## Hardware Support
+
+Attestation is supported and tested on three platforms: Intel TDX, AMD SEV-SNP, and IBM SE.
+Not all features have been tested on every platform, but those based on attestation
+are expected to work on the platforms above.
+
+Make sure your host platform is compatible with the hypervisor and guest kernel
+provisioned by CoCo.
+
+This release has been tested on the following stacks:
+
+### AMD SEV-SNP
+
+* Processor: AMD EPYC 7413
+* Kernel: 6.12.0-snp-host-adc218676 (upstream 6.11+) 
+* OS: Ubuntu 22.04.4 LTS
+* k8s: v1.30.1 (Kubeadm)
+* Kustomize: v4.5.4
+
+### Intel TDX
+
+* Kernel: [6.8.0-1022-intel](https://git.launchpad.net/~kobuk-team/ubuntu/+source/linux-intel/tree/?h=noble-main-next)
+* OS: Ubuntu 24.04 LTS
+* k8s: v1.30.2 (Kubeadm)
+* Kustomize: v5.0.4-0.20230601165947-6ce0bf390ce3
+
+### Secure Execution on IBM zSystems (s390x) running LinuxONE
+
+* Hardware: IBM Z16 LPAR
+* Kernel: 5.15.0-113-generic
+* OS: Ubuntu 22.04.1 LTS
+* k8s: v1.28.4 (Kubeadm)
+* Kustomize: v5.3.0
+
+## Limitations
+
+The following are limitations and known issues with this release.
+
+* Credentials for authenticated registries are exposed to the host.
+* Not all features are tested on all platforms.
+* Nydus snapshotter support is not mature.
+  * Nydus snapshotter sometimes fails to pull an image.
+  * Host pulling with Nydus snapshotter is not yet enabled.
+  * Nydus snapshotter is not supported with enclave-cc.
+* Pulling container images inside guest may have negative performance implications including greater resource usage and slower startup.
+* `crio` support is still evolving.
+* Platform support is rapidly changing
+* SELinux is not supported on the host and must be set to permissive if in use.
+* Complete integration with Kubernetes is still in progress.
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
+  * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
+* The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
+
+## CVE Fixes
+
+None

releases/v0.16.0.md

@@ -0,0 +1,104 @@
+# Release Notes for v0.16.0
+
+Release Date: September 26th, 2025
+
+This release is based on [3.21.0](https://github.com/kata-containers/kata-containers/releases/tag/3.21.0) of Kata Containers
+and [v0.11.0](https://github.com/confidential-containers/enclave-cc/releases/tag/v0.11.0) of enclave-cc.
+
+Trustee and the guest components use KBS protocol v0.4.0.
+
+Please see the [quickstart guide](https://confidentialcontainers.org/docs/getting-started/) or [project documentation](https://confidentialcontainers.org/docs) for more information.
+
+## Deprecation Notices
+* Support for process-based confidential computing via enclave-cc will be removed in the v0.18.0 release.
+  The enclave-cc project will be archived.
+* This will be the last release of CoCo and Trustee that supports `simple` attestation tokens.
+  Today, EAR attestation tokens are the default, but Trustee can be configured to use `simple` tokens.
+  This option will be removed.
+
+## Breaking Changes
+
+* Previously the Init-Data was set for a pod via the `io.katacontainers.config.runtime.cc_init_data` annotation.
+  Now the `io.katacontainers.config.hypervisor.cc_init_data` annotation must be used.
+
+## What's New
+
+* The affirming resource policy now checks that every submod is affirming. With multi-device attestation,
+  KBS policies should be aware of all submods.
+* Experimental support for attesting some NVIDIA GPUs, such as the H100. Either ITA or the Trustee
+  Attestation Service can be used to verify the device evidence, with some limitations.
+* Experimental support for using pre-provisioned VMs in cloud-api-adaptor via "bring-your-own-machine (BYOM) provider
+* Runtime measurements can be extended from inside a workload container using a REST API.
+* Improved support for runtime measurements with AAEL on TDX
+* Trustee supports AMD-SNP guests with report version 5.
+* Additional/improved TCB claims generated by TDX verifier.
+* Extractor modules can now receive configuration if required.
+* SWID/RIM-IM extractor improved.
+* Confidential guest kernel updated to v6.16.7 with certain security-focused configs.
+* CSV verifier supports AAEL.
+* Eventlog parsing supports SM3 hashes.
+* A default GPU attestation policy is provided by Trustee, but it is very limited.
+* eHSM sealed secret backend no longer enabled by default.
+* evidence-getter tool now exposes primary and additional evidence.
+
+## Bug Fixes
+
+* Fixed issue where Init-Data checks could be maliciously bypassed when using dm-verity rootfs, such as with the base `kata-qemu-tdx` runtime. [GHSA-989w-4xr2-ww9m](https://github.com/kata-containers/kata-containers/security/advisories/GHSA-989w-4xr2-ww9m)
+* Fixed issue with attestation service policy endpoint permissions
+* Fixed issue with AR4SI vectors containing underscores
+* Various RUST advisories resolved by updating crates.
+
+## Hardware Support
+
+Attestation is supported and tested on three platforms: Intel TDX, AMD SEV-SNP, and IBM SE.
+Not all features have been tested on every platform, but those based on attestation
+are expected to work on the platforms above.
+
+Make sure your host platform is compatible with the hypervisor and guest kernel
+provisioned by CoCo.
+
+This release has been tested on the following stacks:
+
+### AMD SEV-SNP
+
+* Processor: AMD EPYC 7413
+* Kernel: 6.16.1
+* OS: Ubuntu 22.04.4 LTS
+* k8s: v1.33.0 (Kubeadm)
+* Kustomize: v5.6.0
+
+### Intel TDX
+
+* Kernel: [6.8.0-1028-intel](https://git.launchpad.net/~kobuk-team/ubuntu/+source/linux-intel/tree/?h=noble-main-next)
+* OS: Ubuntu 24.04 LTS
+* k8s: v1.30.2 (Kubeadm)
+* Kustomize: v5.0.4-0.20230601165947-6ce0bf390ce3
+
+### IBM Secure Execution for Linux
+
+* Hardware: IBM Z16 LPAR
+* Kernel: 6.8.0-60-generic
+* OS: Ubuntu Ubuntu 24.04.2 LTS
+* k8s: v1.31.1 (Kubeadm)
+* Kustomize: v5.7.1
+
+## Limitations
+
+The following are limitations and known issues with this release.
+
+* Credentials for authenticated registries are exposed to the host.
+* Not all features are tested on all platforms.
+* Nydus snapshotter support is not mature.
+  * Nydus snapshotter sometimes fails to pull an image.
+  * Host pulling with Nydus snapshotter is not yet enabled.
+  * Nydus snapshotter is not supported with enclave-cc.
+  * There is an experimental option to force guest image pull without a snapshotter.
+    This is also not mature.
+* Pulling container images inside guest may have negative performance implications including greater resource usage and slower startup.
+* `crio` support is still evolving.
+* Platform support is rapidly changing
+* SELinux is not supported on the host and must be set to permissive if in use.
+* Complete integration with Kubernetes is still in progress.
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
+  * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
+* The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.