Bug 717898

Summary:	noarch rpm built without --target option inherits arch from the current system
Product:	Red Hat Enterprise Linux 6	Reporter:	Karel Srot <ksrot>
Component:	rpm	Assignee:	Panu Matilainen <pmatilai>
Status:	CLOSED NOTABUG	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.1	CC:	jkaluza, pknirsch
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-07-19 18:58:22 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Karel Srot 2011-06-30 11:13:27 UTC

Description of problem:

I was testing file bz712992 and I have realized that noarch package built without the --target noarch option is not noarch but inherits the arch from the system where it has been built. Well, such an RPM can be installed on any other arch (it is in fact noarch), just the bytes in the header says something different.


file command reads the architecture from the RPM file header, in particular it is the fifth column in RPM hexdump (http://www.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html):

TRUE noarch is 'ff00':

# hexdump dummy-1.0-1.noarch.rpm | head -n 1
0000000 abed dbee 0003 0000 ff00 7564 6d6d 2d79
# file dummy-1.0-1.noarch.rpmdummy-1.0-1.noarch.rpm: RPM v3.0 bin noarch

FAKE noarch is not 'ff00' but e.g. '0100':

# cat dummy.spec 
Summary: dummy Package
Name: dummy
Version: 1.0
Release: 1
Group: System Environment/Base
License: GPL
BuildArch: noarch
Provides: dummy

%description

This is a dummy test package created by make_dummy_package.sh script

%files

# rpmbuild -bb dummy.spec 
Processing files: dummy-1.0-1.noarch
Checking for unpackaged file(s): /usr/lib/rpm/check-files /root/rpmbuild/BUILDROOT/dummy-1.0-1.x86_64
Wrote: /root/rpmbuild/RPMS/noarch/dummy-1.0-1.noarch.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.ieAQxD
+ umask 022
+ cd /root/rpmbuild/BUILD
+ /bin/rm -rf /root/rpmbuild/BUILDROOT/dummy-1.0-1.x86_64
+ exit 0

# hexdump /root/rpmbuild/RPMS/noarch/dummy-1.0-1.noarch.rpm | head -n 1
0000000 abed dbee 0003 0000 0100 7564 6d6d 2d79
# file /root/rpmbuild/RPMS/noarch/dummy-1.0-1.noarch.rpm
/root/rpmbuild/RPMS/noarch/dummy-1.0-1.noarch.rpm: RPM v3.0 bin i386/x86_64



Version-Release number of selected component (if applicable):
rpm-4.8.0-16.el6.x86_64

How reproducible:
always

Steps to Reproduce:
see above
  
Required behavior:
rpmbuild -bb noarch.spec should built noarch package with correct bytes (ff00) in the RPM header.

Comment 1 Panu Matilainen 2011-06-30 12:24:53 UTC

If you read the rpm file format document further, you'll encounter a section called "The lead: An Abandoned Data Structure". It was already considered dead and unused back when the venerable max-rpm was written, in other words more than a decade ago. This can only be considered a bug in the spirit of "be conservative what you do, be liberal what you accept" really, the data from the lead section of rpm should not be used and cannot be trusted to be correct or even present (it might even be all zeroes except for the "magic" part).

I also suspect this issue itself is over ten years old, meaning practically every single noarch rpm in the wild has a wrong architecture in the lead. Fixing this would be easy, but it doesn't change the fact that you cannot trust the data from the lead. If libmagic wants to figure out more data from rpms, it should use parse the data from the header, not the lead.