Allow RPM to get signature salt for OpenPGP v6 signatures

[Jakuje]

Most of the content is the same as in #91, but attempts to address the hashing issue using the new API for RPM.

[pmatilai]

Rpm side at rpm-software-management/rpm#3848

Haven't tried with the actual test-suite, just manual verify:

$ ./tools/rpmkeys -Kv /tmp/hello-2.0-1.x86_64.rpm
/tmp/hello-2.0-1.x86_64.rpm:
Header OpenPGP V6 Ed25519/SHA512 signature, key fingerprint: 036824f0ac60aed6f1a3256f88190469f6d7255e3d8e41c577233aa03e0bb9d3: OK
Header SHA256 digest: OK
Payload SHA256 digest: OK

[Jakuje]

Run of this branch against the rpm-software-management/rpm#3848 is here (not sure why it did not run in the pr directly):

https://github.com/Jakuje/rpm-sequoia/actions/runs/15995286790/job/45117251685

[Jakuje]

Latest run in my fork with recent changes from Panu worked:

https://github.com/Jakuje/rpm-sequoia/actions/runs/15998694606/job/45128059715

[pmatilai]

So this works and the Salt() interface is what I suggested in the other PR, I'm just pondering whether there is any real value in returning an error code over just returning NULL if there's no salt, ie

const uint8_t *pgpDigParamsSalt(pgpDigParams digp, size_t *lenp)

I've no strong opinions on this, just thinking out loud.

[Jakuje]

I do not really have a preference. I slightly prefer the current approach approach (what is now in the PR) as I like the Error/Success is written in the rust way with the Result(Ok/Err) being mapped directly to ErrorCode. While I agree that we could return the salt directly, we would remove the Ok/Err semantics, possibly hiding the errors (as you mentioned that this should really not be called on non-signature contexts).

[pmatilai]

Ok, in that case lets just keep it as it is 👍

[nwalfield]

Unfortunately, I'm not able to run the test suite using the instructions in the README. Could you help me debug the issue, please?

[nwalfield]

I'm closing this in favor of #93 .