The main problem with the implementation of v4 rpm signatures is that the generated hash (sent to key server) now needs to "contain" the respective public key algorithm.

According to RFC4880, these values are hashed (public key alg is between them):

- One-octet version number (4).

- One-octet signature type.

- One-octet public-key algorithm.

- One-octet hash algorithm.

- Two-octet scalar octet count for following hashed subpacket data. Note that this is the length in octets of all of the hashed subpackets; a pointer incremented by this number will skip over the hashed subpackets.

- Hashed subpacket data set (zero or more subpackets).

- Two-octet scalar octet count for the following unhashed subpacket data. Note that this is the length in octets of all of the unhashed subpackets; a pointer incremented by this number will skip over the unhashed subpackets.

However, the public key is not generally present on the client where the hash is generated, which is unfortunate. Because of that we cannot easily generate the final hash on the client.

The preferred solution would be to send just the base hash state made just of rpm data (rpm's header-only SHA1/SHA256 hash and header+payload hash). It's the state before writing any additional values into the hash - that should be done on the remote (key-)server.

The problem with this approach is that libgrypt library does not easily allow this as far as I have discovered. So far I haven't found a way to initialize gcry_md_context by the received data and then continue with hashing from there. At the moment, the hash is finalized prematurely for me, that is before writing the above mentioned additional data. The relevant piece of code is this:

mdb = gcry_md_read(mfx.md, opt.def_digest_algo); // this itself finalizes the hash

in gpg2: g10/sign.c.

These are pretty much my findings so far.