I've just checked in patches for RPM to reserve space
for signatures (to be added later) when a package is built.

The goal is to make signing packages less I/O intensive.

Currently, signing *.rpm packages forces (because the
added signature is inserted, not appended) a rewrite of the package  
file,
which, when dealing with all the packages in some distro, leads
to gigabytes of I/O. Signing itself is a rather lightweight event
involving only the I/O to read the metadata header itself.

(aside) Yes there is the header+payload MD5 digest, but that
value need not be recomputed and rewritten when signing a package.

The other reason for padding the signature header is to
place the metadata header at a known offset for more
efficient downloads. With a variable length signature
header, two reads are needed to load package metadata,
the first read to find the size of the signature header,
the second to load the metadata header once its offset is known.

The padding currently pushes the metadata header to a (1024 - 8)
byte offset. The "minus 8" skips the on-disk header magic and leaves
the portion of the metadata needed from a package by RPM itself on
a 0x400 boundary.

For now, 1024 is more than sufficient for reserving space for package
signatures. The value has been chosen mostly because 1024 is very easy
to remember. There are reasons for both a smaller value, and there
may also be reasons (like page alignment with mmap(2)) for a larger
padding value.

So its too early to tell what value will be eventually used, 1024
will do for the short term

There should be no legacy consequences with the implementation
whatsoever other than that actual package size produced by
rpmbuild will be ~900 or so bytes larger.

73 de Jeff