Bug 1466950
Summary: | Custom Repositories built with SHA1 checksums produce incorrect SHA256 repodata | |||
---|---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Craig Donnelly <cdonnell> | |
Component: | Repositories | Assignee: | satellite6-bugs <satellite6-bugs> | |
Status: | CLOSED ERRATA | QA Contact: | Perry Gagne <pgagne> | |
Severity: | urgent | Docs Contact: | ||
Priority: | medium | |||
Version: | 6.2.10 | CC: | bbuckingham, bmbouter, cwelton, daviddavis, dkliban, ehelms, ggainey, ipanova, jbhatia, jcallaha, jsherril, jyejare, mhrivnak, pcreech, rchan, ttereshc, xdmoon | |
Target Milestone: | Unspecified | Keywords: | PrioBumpGSS, Triaged | |
Target Release: | Unused | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | rubygem-katello-3.0.0.168-1 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1480694 (view as bug list) | Environment: | ||
Last Closed: | 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: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1480694 |
Description
Craig Donnelly
2017-06-30 20:56:25 UTC
The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug. The Pulp upstream bug priority is at High. Updating the external tracker on this bug. It sounds like this might be a regression in Satellite 6.2.10, based on customer experience. The bug in Pulp however has been present for a long time. The bug could be avoided if the call to /pulp/api/v2/repositories/<repo_id>/actions/import_upload/ specified in the "unit_metadata" object: {"checksum_type": "sha1"}. If that is not specified, the uploaded RPM defaults to sha256, and this bug can be experienced. http://docs.pulpproject.org/dev-guide/integration/rest-api/content/upload.html#import-into-a-repository It's theoretically possible that previous uploads were including that, but for some reason in 6.2.10 or in this particular workflow, that is not getting set, and thus the user would see a change in behavior. Any such change would be in Katello. Not to throw Katello under the bus at all, because this is definitely a Pulp bug. That's just the only scenario I can come up with where this would be experienced as a regression. (In reply to Michael Hrivnak from comment #4) === > It sounds like this might be a regression in Satellite 6.2.10, > based on customer experience. === I have reason to suspect this is present in 6.2.9. I was helping this customer, today, using my test Satellite 6.2.9. I, too, was experiencing problems where I would create a new product, new repository with the sha1 checksum and new content view but the end result was a RHEL5 client giving me the "[Errno -1] Package does not match intended download" error. All upstream Pulp bugs are at MODIFIED+. Moving this bug to POST. I have signed RPMs with Sha1 and created repo with sha1 checksum as well. But somehow when I attempting to install those packages on rhel5 client, the client is saying bad signed key. I don't whether it's my environment issue or steps issue, So leaving in a default pool to take by someone else to verify. Jitendra, RHEL 5 boxes can only install packages signed with gpg keys created in a very certain way. Just because its sha1 doesn't mean that it will work. see https://technosorcery.net/blog/2010/10/pitfalls-with-rpm-and-gpg/ for more information. Also make sure you select a 'RSA (sign only)' key. Hope that helps! and good luck ! :) Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0336 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0336 |