Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1851508 - Unable to remove gpg signatures from certain rpm files, get "ReadSignature failed"
Summary: Unable to remove gpg signatures from certain rpm files, get "ReadSignature fa...
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 31
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2020-06-26 18:17 UTC by Steve Miller
Modified: 2020-11-24 20:24 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1874062 (view as bug list)
Last Closed: 2020-11-24 20:24:59 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github rpm-software-management rpm pull 1330 0 None closed Work around buggy signature region preventing resigning (RhBug:1851508) 2020-10-20 11:20:26 UTC

Internal Links: 1874062

Description Steve Miller 2020-06-26 18:17:31 UTC
Description of problem:
Unable to remove signatures from ALL versions of Microsoft teams. The RPMs are created, managed, and released by Microsoft. All other rpms work as expected.

Version-Release number of selected component (if applicable): 4.15.1

How reproducible:
With Microsoft Teams rpm (any version).

Download latest rpm from:

Steps to Reproduce:
1. Download teams rpm from Microsoft
2.Execute "sudo rpm --delsign teams-                    

Actual results:
Signature remains

Get the following error:
error: teams- rpmReadSignature failed: signature region 62: tag number mismatch il 9 ril 7 dl 4852 rdl 4852

Expected results:
Signature is removed.

Additional info:
Also cannot do a addsign or resign (which is really what I want to be able to do)

I assume this is Microsoft's way they are creating the rpm, however, it could be a bug in rpm as well. I have been able to work with other Microsoft created rpm's before, just not Teams.

Comment 1 James Hartsock 2020-07-28 21:16:32 UTC
rpm-4.16.0-beta3 looks to not have the error, but still fails

# rpmsign --delsign /root/teams- ; echo $?

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

Comment 2 Panu Matilainen 2020-08-05 08:13:45 UTC
Ack, easily reproduced the behaviors on both 4.15.x and 4.16.x. I'll look into it.

Comment 3 Panu Matilainen 2020-08-05 08:15:29 UTC
> 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.

Comment 4 Panu Matilainen 2020-08-05 09:03:37 UTC
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 ( which tends to suggest the latter, but there could of course be other factors.

Comment 6 Steve Miller 2020-08-06 01:15:21 UTC

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:

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

Comment 7 James Hartsock 2020-08-06 13:37:23 UTC
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.

Comment 8 Panu Matilainen 2020-08-13 08:59:08 UTC
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-

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

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.

Comment 12 Fedora Update System 2020-08-31 10:36:57 UTC
FEDORA-2020-4b3beb9b1d has been submitted as an update to Fedora 33.

Comment 15 Fedora Update System 2020-08-31 18:57:44 UTC
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:

See also for more information on how to test updates.

Comment 16 Fedora Update System 2020-09-25 16:39:50 UTC
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.

Comment 17 Ben Cotton 2020-11-03 17:10:32 UTC
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.

Comment 18 Ben Cotton 2020-11-24 20:24:59 UTC
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

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

Note You need to log in before you can comment on or make changes to this bug.