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 bugzilla.redhat.com.
Bug 1851508
Summary: | Unable to remove gpg signatures from certain rpm files, get "ReadSignature failed" | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Steve Miller <code> | |
Component: | rpm | Assignee: | Panu Matilainen <pmatilai> | |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | medium | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 31 | CC: | hartsjc, igor.raits, mjw, packaging-team-maint, pmatilai, pmoravco, vmukhame | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | x86_64 | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | If docs needed, set a value | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1874062 (view as bug list) | Environment: | ||
Last Closed: | 2020-11-24 20:24:59 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: |
Description
Steve Miller
2020-06-26 18:17:31 UTC
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. |