Update Chisel to v1.0.0

[lbussell]

Chisel v1.0.0 has been released: https://github.com/canonical/chisel/releases/tag/v1.0.0

Release notes:

this major release introduces the Chisel "manifest" - a Zstandard-compressed "jsonwall" file generated by Chisel, to record information about the installed slices in the chiselled root filesystem. The new Chisel command info is also introduced in this release. Finally, the Chisel format chisel-v1 is now deprecated.

This is supposed to make it easier to add slices to an image after the fact - this should be investigated as part of #4811.

The GitHub release also includes sha384 artifacts that we can use to validate the tool. The update-dependencies tool and the Chiseled Dockerfiles need to be updated to support this.

[richlander]

We talked about this at the Ubuntu summit. I wanted to understand how we could use the manifest to replace the (I think) synthesized APT database we have today. The short version (if I understood correctly) is to use the manifest as an input into an SBOM. In essence, we'd replace our current solution with an SBOM and the manifest file would be an implementation detail. I suggest we do that for .NET 10 and leave .NET 8/9 unchanged.

We should switch to chisel 1.0 for all in-support versions.

Here's another link: https://discourse.ubuntu.com/t/chisel-manifest-is-supported-in-newly-released-v1-0-0/48944

[mthalman]

We can't get rid of the synthesized APT database until support for the chisel manifest is widely available by scanning tools.

[richlander]

I think you misunderstood what I wrote. My proposal is NOT to include the manifest in our images as the input to scanners.

[lbussell]

So currently we have:

flowchart LR
  A[chisel] --> B[chisel-wrapper] --> C[dpkg status file] --> D[vuln scanners]
  C[dpkg status file] --> E[SBOM]

Loading

And I believe Rich is suggesting:

flowchart LR
  A[chisel] --> B[chisel manifest] --> C[SBOM] --> D[vuln scanners]

Loading

Is that accurate?

[mthalman]

Ok, then this leads to the question of where does that SBOM reside?

[richlander]

where does that SBOM reside

I think we should use the cloud for that.

[lbussell]

Attach SBOMs to images in the container registry (dotnet/dotnet-docker#5515) seems like the move.

[mthalman]

This will require an update to the slices we install to include the chisel manifest. It will need to add base-files_chisel. See canonical/chisel-releases#357

[lbussell]

This will require an update to the slices we install to include the chisel manifest. It will need to add base-files_chisel. See canonical/chisel-releases#357

Going with what @richlander said above, should we only add that for .NET 10?

[mthalman]

Based on this post, the proposal is to only support the generation of an SBOM from chisel manifest for .NET 10. So yeah, I think it makes sense to only include that slice for .NET 10.

[richlander]

We can always re-consider but yes we should start with a 10-only approach. We have a fair bit of proving out to do and do not yet have a doc that says "here is how you do scanning using chisel manifests".

[lbussell]

I wanted to clarify that we could add the manifests to older images, but keep the synthesized dpkg status file around for scanning.

[richlander]

We could. We just need a documented reason/workflow for considering that.