The current batch of changes are still incomplete, but give an idea of where I'm going.

I started out just trying to remap the payloadhash field to be determined by alternate fields, but remain singular. However, when I got to the point of sorting out how this would look for CG imports, I realized that we needed to be more flexible in how the CG specifies component/buildroot rpms

I've noticed RPM v6.0.0 Supports multiple OpenPGP signatures per package, Does Koji have any plans to support multi-sign?

I've noticed RPM v6.0.0 Supports multiple OpenPGP signatures per package, Does Koji have any plans to support multi-sign?

This is handled by #4373 and its followups.

Koji doesn't really care how many signatures are in an rpm. That said, Koji needs a single unique string key for each different signature header that it stores (used for lookup and in paths). Historically, Koji has auto-chosen this key by parsing RPM_SIGTAG_{GPG,PGP,DSA,RSA} from the signature header. For more complex v6 signatures, the client that is importing the signature should specify a consistent sigkey value at import time.

This (size) field got lost and is required later in the process

The size field in rpminfo is unfortunately inconsistent. In import_rpm, we populate it with the file size, not the size field from the header. Otoh, in add_external_rpm we use the size reported by the caller, which might be either the file size (e.g. for some image components) or the header value (e.g. for rpm buildroot components).

To further complicate matters, the size field has been removed in the v6 spec (rpm will report None).

I don't think my last commit above is the right fix. Will try another approach shortly.

Some debug artifact?

Some debug artifact?

Ah, yes. An earlier version had got_digest defined by a set in the for loop, and that was me figuring out that this value did not persist after the loop in jinja.

Fixed now.

This works for me now. :thumbsup:

How is the situation with multiple GPG signatures? It seems to me that we've another family of issues there. E.g. get_sighdr_key returns only first one and we're blind to others. So, also sigcache, data/signed are referred by only first one (while sighdr contains more GPG signatures).

How is the situation with multiple GPG signatures?

See above comment - https://pagure.io/koji/pull-request/4446#comment-227271

Longer term, we could consider expanding the automatic sigkey choice to be aware of a broader range of signatures, however this could get quite complex. To do this right we'd also need to consider ima, which we've been ignoring for a while (and hypothetically, the header structures allows for each file in the rpm to be ima-signed differently, though rpmsign itself behaves more consistently).
The current code allows the client to specify the sigkey, which dodges this complexity.

Temporally untagged for testing purposes

Temporally untagged for testing purposes

Is there a merge issue? Lmk if I need to rebase something

Ah, I see this overlaps with #4472. The conflict is pretty straightforward to resolve. I'll rebase one whenever the other is merged.

Rebased. Minor conflict with #4472

Commit 86057e1b fixes this pull-request