Thanks for the patch! From looking at the native RPM tool sources, it appears that the sig size header is always set to the exact size of the generated signature. I'll take this patch and see about modifying the code to set the correct size for any generated signature size. Really appreciate the test case too!

The long and the short of it is, the size should not be hard coded in the RPM tools either, I reckon.

That probably explains why some versions of RPM only accept 2048 keys and fail on anything else. (And most of them can't handle subkeys either.)

Don't quote me on that though. :) And it must depend on version, because the latest RPM versions don't have trouble with V4 signing keys like older RPM versions do. Which I found out the hard way. Heh.

Yeah, that first go didn't quite work. Hard-coding the header size just isn't going to cut it, basically.

I updated the fork with better size handling, which actually seems to work now (using a buffer that was too big for the smaller keys broke the RPMs, though they passed that initial test), but it's still basically hard-coded, there's just 3 options instead of one.

I tried not setting the size of the header until after it had been generated, which would be the best solution, but that borked things and I have no idea why. :) Hopefully you'll have more luck there. Heck, if the latest RPM tools have it hard-coded, maybe there's another way. Kinda scratching my head at how though, as bigger keys are, um, bigger, but stranger things... :)

I added a setting related to this: "useV3Signatures", for using the old PGPV3Signatures which some RPM/yum distros require (older distros mostly). Now I can RPM -Kvv and get good signatures even on older versions of RPM.

Caveats being:
older versions cannot handle keys above 2048
older versions cannot handle the V4 signature format
most versions cannot handle subkeys

Also updated the unit tests so they won't give false negatives when testing.

FWIW, setting the size ahead of time would work if I understood where the size comes from.

A 2048 key is 255, not 286, and 4096 is 512, not 543, so where does the 31 "padding" come from?

I thought it was static at 31 (whatever it is), but the V3 sigs are only 280, vs. 287, which blew that idea out of the water. I'm sure it's something simple I'm overlooking but I'll be damned if I know what. :)

Yeah, I've been browsing around for some info on how the signature size can be derived from the key size and algorithm, but haven't hit on anything yet. Might be acceptable to work around it for now with a simple lookup-table matching known combinations (e.g. 2048 and 4096 in v3) with it's known sig size.

It looks like the RPM tool's approach is to generate the full signature and then build the header structures with the actual size of the output signature, but that doesn't work well with the current Redline architecture which requires reserving the proper header size before calculating the signatures.

It's kind of a chicken/egg deal, neh?

I was did something similar for .deb file signing, and there the signature was generated first, which avoided the problem, but it also requires the whole shebang to be in memory I reckon (I'd have to look again but I think so).

I like the channel approach, as it should perform way better with a smaller memory footprint ta boot.

Is this issue still open? It would be great to have a fix for this.
Unfortunately I myself have no knowledge about rpm package structure but may be could get some inspiration from here: https://github.com/eclipse/packagedrone/blob/master/bundles/org.eclipse.packagedrone.utils.rpm/src/org/eclipse/packagedrone/utils/rpm/signature/RsaHeaderSignatureProcessor.java

Hi @craigwblake, any chance that @denuno's latest version of the fork could make it into the main branch? Or at least have a method of supplying an arbitrary signature size so that the ospackage-plugin (and then those using it) can use one for a key of known size?

this issue is still present and prevents signing of rpms...