Bug 1466950 - Custom Repositories built with SHA1 checksums produce incorrect SHA256 repodata
Summary: Custom Repositories built with SHA1 checksums produce incorrect SHA256 repodata
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Repositories
Version: 6.2.10
Hardware: Unspecified
OS: Unspecified
medium
urgent
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Perry Gagne
URL:
Whiteboard:
Depends On:
Blocks: 1480694
TreeView+ depends on / blocked
 
Reported: 2017-06-30 20:56 UTC by Craig Donnelly
Modified: 2021-06-10 12:32 UTC (History)
17 users (show)

Fixed In Version: rubygem-katello-3.0.0.168-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1480694 (view as bug list)
Environment:
Last Closed:
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Pulp Redmine 1618 0 High CLOSED - CURRENTRELEASE --checksum-type is broken 2017-06-30 21:05:25 UTC

Description Craig Donnelly 2017-06-30 20:56:25 UTC
Description of problem:
Currently in Satellite 6.2.10, if you create a custom product and custom repository, and set that repository to SHA1 for checksum type and upload SHA1 packages to the repo via the WebUI:

The repodata generated with have SHA1 checksums in the repomd.xml, but the primary.xml will contain SHA256 checksum type for the packages.

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

How reproducible:
100%

Steps to Reproduce:
1. Create custom product
2. Create custom repo with SHA1 checksum type
3. Upload SHA1 signed package to custom repo
4. Try to install the package on a RHEL 5 client.

Actual results:
[Errno -1] Package does not match intended download.

Expected results:
Successful install.

Additional info:

Comment 2 pulp-infra@redhat.com 2017-06-30 21:05:26 UTC
The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug.

Comment 3 pulp-infra@redhat.com 2017-06-30 21:05:29 UTC
The Pulp upstream bug priority is at High. Updating the external tracker on this bug.

Comment 4 Michael Hrivnak 2017-06-30 21:12:13 UTC
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.

Comment 5 Bernie Hoefer 2017-06-30 21:35:13 UTC
(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.

Comment 6 pulp-infra@redhat.com 2017-06-30 21:35:28 UTC
All upstream Pulp bugs are at MODIFIED+. Moving this bug to POST.

Comment 14 Jitendra Yejare 2017-10-17 09:00:05 UTC
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.

Comment 15 Justin Sherrill 2017-10-17 12:03:47 UTC
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 ! :)

Comment 20 Bryan Kearney 2018-02-21 17:33:35 UTC
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

Comment 21 Bryan Kearney 2018-02-21 17:33:57 UTC
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


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