There are multiple places where checksums are computed:

• for createrepo_c: current options are sha or sha256. At least createrepo_c is fine with sha512 as well, so this should be allowed.
• for live media, isos and images we compute checksums that go into metadata and the CHECKSUM files in compose dir: this supports any checksum provided by hashlib and is not restricted by config (but the documentation needs to be updated though to mention this explicitly)
• .treeinfo files contain checksums of some files, and this is currently hardcoded to sha256. The value contains the checksum type, so it should be possible to change these, but care needs to be taken to not break consumers. (example).
• when extra files are copied to the compose (not used for fedora), we create a file with checksums for them. Right now it uses a sha256 checksum, but it's written in a way to support multiple checksums, and probably should reuse the config for live media.

As for the .treeinfo Pungi is using productmd which does not seem to support multiple checksums (the format looks like it could support it, but the code can not write it). Before changing that we need to find out what reads the value and whether it could break.

On the subject of bad checksums, the sigkeys and signing_key_id settings should probably enforce a longer key length (see https://evil32.com/).

The key ids are passed to koji to get paths to signed copies of the files, so Koji itself first needs to support longer keys. Currently the ID is just put into a path as is.

Checking again the .treeinfo file does not support multiple checksums for a single file and it can't without big changes.The INI format uses file path as key, and these can not be duplicated. The best we can do is to just switch it, which could break consumers.

The checksums in treeinfo are now switched to whatever createrepo_checksum is configured to.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/pungi/pungi/issues/591

Please continue any further discussion there.