rpm-4.16.0-beta3 looks to not have the error, but still fails

# rpmsign --delsign /root/teams-1.3.00.16851-1.x86_64.rpm ; echo $?
/root/teams-1.3.00.16851-1.x86_64.rpm:
1


Also this is not limited to MSFT RPMs, as was informed of this issue on RHEL for other third party RPMs.

Ack, easily reproduced the behaviors on both 4.15.x and 4.16.x. I'll look into it.

> Also this is not limited to MSFT RPMs, as was informed of this issue on RHEL for other third party RPMs.

If you can point me to other failing packages, that would help to make sure we get it nailed for good.

It would also be interesting + helpful to know what was used for signing this package, rpm 4.14.1 which was used for building this package or some other version/custom tool. The symptom (for 4.15) is essentially the same as trying to sign rpm5 packages (https://github.com/rpm-software-management/rpm/issues/1002) which tends to suggest the latter, but there could of course be other factors.

Since opening this bug, I have tried to work with Microsoft on the specific issue with the way they are signing the MS Teams RPMs. However, this attempt did not go anywhere. 

If curious:
https://docs.microsoft.com/en-us/answers/questions/48594/teams-rpm-signature-issue.html

I personally do not know of other RPMs that see this issue. Perhaps James can chime in with examples.

The package I have is proprietary 3rd party, and have shared it within Red Hat.  But as such I do not know how it was created either, but I am told that previous releases of this product/rpm did not have this issue. So very likely something changed on packaging side, but no indication on what to narrow focus at this point.  Seeing if I can find out more.

After some meditative hexdump staring: the issue is that the package is slightly corrupted, almost certainly by whatever tool was used to sign it as the "corrupted" internal structure value indicating number of tags in the immutable header region is off by two, which equals the the number of tags added by signing. So it seems the tool used for signing the teams packages fails to update the negative offset in the region trailer to match the additional data. The catch here is that the issue is only detected on headerGet() of RPMTAG_HEADERSIGNATURES from the signature header, which a structure that is not even visible to outside tools in normal operation, so its easy to miss in testing. 

This will fixup the wrong value in the package, making signature deletion and resigning possible (this is not an universal fix but works for at least this particular version and also teams-1.3.00.16851-1.x86_64.rpm):

    $ printf '\x70' | dd bs=1 count=1 seek=5103 conv=notrunc of=teams-1.3.00.5153-1.x86_64.rpm

The question is what to do about it. Rpm could warn and work around, but then it *is* corrupted and working around data structure corruption can also open the door for new security issues and the other possible conclusion is that rpm should detect the corruption and refuse to open the package at all.

FEDORA-2020-4b3beb9b1d has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-4b3beb9b1d

FEDORA-2020-4b3beb9b1d has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-4b3beb9b1d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4b3beb9b1d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-4b3beb9b1d has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.