podvm-mkosi: Install libtdx-attest

[fidencio]

Although not required by all the CSPs, libtdx-attest should be present in the images for the cases where TPMs are not used.

The rpm provided comes from Intel's way of providing this to RPM based distros, which is a tar'd repo file present in:
https://download.01.org/intel-sgx/latest/linux-latest/distro/centos-stream9/

[mkulke]

I think that's a great, least-intrusive way to include the package. Can we download the RPM in the Makefile instead of committing it into the repo?

[fidencio]

I think that's a great, least-intrusive way to include the package. Can we download the RPM in the Makefile instead of committing it into the repo?

I'd say we could, but I'm not sure if I'd prefer doing that, though.
I don't fully trust Intel when it comes to Intel's abilities to packaging something, and / or not screwing up with already existent packages.

[stevenhorsman]

As I thought it might - this breaks the s390x mkosi image build: https://github.com/confidential-containers/cloud-api-adaptor/actions/runs/13282665508/job/37084284158, so I guess we need some way to guard the architecture?

[mkulke]

I think that's a great, least-intrusive way to include the package. Can we download the RPM in the Makefile instead of committing it into the repo?

I'd say we could, but I'm not sure if I'd prefer doing that, though. I don't fully trust Intel when it comes to Intel's abilities to packaging something, and / or not screwing up with already existent packages.

We will also regularly have to bump fedora versions, and the package might stop working, so a binary blob in the repo might still cause build failures. Can we have a src.rpm and build that as part of the build process? If this is not possible and we have to include a binary blob from an unknown provenance, I would suggest to guard this behind an opt-in feature toggle in the Makefile.

[bpradipt]

I think that's a great, least-intrusive way to include the package. Can we download the RPM in the Makefile instead of committing it into the repo?

I'd say we could, but I'm not sure if I'd prefer doing that, though. I don't fully trust Intel when it comes to Intel's abilities to packaging something, and / or not screwing up with already existent packages.

We will also regularly have to bump fedora versions, and the package might stop working, so a binary blob in the repo might still cause build failures. Can we have a src.rpm and build that as part of the build process? If this is not possible and we have to include a binary blob from an unknown provenance, I would suggest to guard this behind an opt-in feature toggle in the Makefile.

@fidencio can we install it from the fedora copr repo for the time being ?

[fidencio]

@fidencio can we install it from the fedora copr repo for the time being ?

This will make things a little bit more complicated, but I can revisit this path.

[wainersm]

Hi @fidencio !

What if publish the rpm either on quay.io or ghcr.io as an oras image? We could even have a workflow to pull from intel and push to the registry to ease updates.