The new --addsign semantics is that signatures are indeed added, no longer replaced, which is the correct and sane thing to do... At least for rpmv6 signatures. We currently keep adding new rpmv4 (legacy) signatures regardless (by having duplicate tags). This is because we lack the check (in putSignature()) that would prevent that.
As a result, a package gets a new RPMSIGTAG_DSA or RPMSIGTAG_RSA each time --addsign is called. During verification, it seems like only the first one is ever used (as it should), but it's a bug nonetheless (if just for the fact that duplicate tags are prohibited in the RPM v6 specification).
Note that this does not happen specifically when signing a v4 package and using --rpmv6. This is because there actually is a check that prevents that (in rpmSign()) by unsetting the respective flag that creates a v4 (or v3) compat signature. But the other variants (a v4 package without --rpmv6 or a v6 package with --rpmv4) are still affected.
This is fixed by a small patch that I have (almost) ready.
The new
--addsignsemantics is that signatures are indeed added, no longer replaced, which is the correct and sane thing to do... At least for rpmv6 signatures. We currently keep adding new rpmv4 (legacy) signatures regardless (by having duplicate tags). This is because we lack the check (inputSignature()) that would prevent that.As a result, a package gets a new
RPMSIGTAG_DSAorRPMSIGTAG_RSAeach time--addsignis called. During verification, it seems like only the first one is ever used (as it should), but it's a bug nonetheless (if just for the fact that duplicate tags are prohibited in the RPM v6 specification).Note that this does not happen specifically when signing a v4 package and using
--rpmv6. This is because there actually is a check that prevents that (inrpmSign()) by unsetting the respective flag that creates a v4 (or v3) compat signature. But the other variants (a v4 package without--rpmv6or a v6 package with--rpmv4) are still affected.This is fixed by a small patch that I have (almost) ready.