We should definitely double check that this is sane and correct.

For Koji's use, we're mostly concerned with signature headers. We have a function for ripping the main header too, but we never call it

There is a bit in the hub (_scan_sighdr) where we calculate the main header size in order to write out a signed copy with no payload. I doubt that the padding makes a difference there.

Trying to convince myself this is really correct.
A detour into the rpm code finds this bit in hdrblobRead

if (regionTag == RPMTAG_HEADERSIGNATURES) {
    size_t sigSize = uc + sizeof(rpm_header_magic);
    size_t pad = (8 - (sigSize % 8)) % 8;
    size_t trc;
    if (pad && (trc = Freadall(fd, block, pad)) != pad) {
        rasprintf(emsg, _("sigh pad(%zd): BAD, read %zd bytes"), pad, trc);
        goto exit;
    }
}

The uc value here is calculated the same as our initial hdrsize value (8 + 16 * il + dl). For signature headers only, rpm calculates the padding the same way we do and reads past it.

So it seems that only the signature is padded. I guess this is because they want the following header to be 8 byte aligned. I presume this is not needed for the main header because alignment does not matter for the payload the follows it. Meanwhile, the signature header itself is always 8 byte aligned because the lead has a fixed length of 96.

:thumbsup:

Testing notes -- I've added a unit test based on a script I was using to validate this code. The test just uses the handful of test rpms we have in the repo. It reports a failure if I run it on the current main branch (as it should) and passes on this PR branch.

If anyone wants the original script for more extensive testing, just msg me.

Can this be merged now? I'd like to rebase a pending PR on top of it.

Commit 72c6495a fixes this pull-request