CHECKSUM files in BaseOS/*/*/images

I would like to see CHECKSUM files in the BaseOS/x86_64|…/os|kickstart/images directories. The files in these directories, e.g. boot.iso are security sensitive as they are used to boot a new system. Securing them with GPG signed checksums would give confidence that they really originate from the AlmaLinux project and have not been altered on the way via the CDN / mirror network.

I know that the ISOs have CHECKSUM files, but

  1. extracting the images directory from the ISO image is cumbersome
  2. during beta periods of new releases the regular repo and the ISO files get separated and need to be downloaded from two different locations, which cause extra friction in an already time-critical period
  3. without CHECKSUM files, the files in the regular images directory cannot be trusted, so does it even make sense to ship them? People might use them and be exposed to man-in-the-middle security risks.

The above is based on my current level of knowledge, please correct me if I’m wrong about something,

Hi.

Checksums of images are stored in .treeinfo files. Example:
https://repo.almalinux.org/almalinux/9/BaseOS/x86_64/os/.treeinfo

Yes, .treeinfo files contain the checksum, but they are not GPG signed. That means that an attack on a compromised mirror could change both boot files and the .treeinfo file and you could not tell that the files were manipulated. If GPG signatures could be added to the .treeinfo files, that would do the trick.

OK we can sign them as well. The filenames will be .treeinfo.asc, will this work for you?

1 Like

Awesome!
Yes, this would work for me.

1 Like

We’ve signed all .treeinfo files for AlmaLinux 8.10 and 9.5.

1 Like

Great, it works! Thank you!

1 Like

Hello @alukoshko,
may I ask how you implemented this change?
I did dive into the pungi sources and don’t see signature functionality there. Did you do it afterwards in a post-processing step?

Yes it’s post-action. Previously we only signed CHECKSUM and repomd.xml files, now we’ll also sign .treeinfo

That makes sense. And it explains why this file is missing in os - someone always has to think about it and do it.
I’m thinking about integrating this function in pungi, but I don’t know whether I will have the spare time to do it. Would pungi be in a position/location in the pipeline where it could have access to the private GPG key? Pungi would need to run on a machine with high trust level.