Bug 457678 - It's possible to include a different spec in the srpm than the one used in build
It's possible to include a different spec in the srpm than the one used in build
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
9
All Linux
medium Severity low
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-03 08:14 EDT by Vasile Gaburici
Modified: 2009-07-14 10:34 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 10:34:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vasile Gaburici 2008-08-03 08:14:02 EDT
Description of problem:
There's a race condition when the srpm is packaged: the spec file included in the srpm need not be the same file that was used to start the build process. This can  actually be useful in that one can build a rpm and continue editing the spec at the same time, but the srpm built that way is not reproducible, which make this race a low security threat.

IMHO a warning should be issued if the checksum of the spec started the build differs from the one just before the srpm is packaged.

Version-Release number of selected component (if applicable):
rpm-4.4.2.3-2.fc9.i386

How reproducible:
Always.

Steps to Reproduce:
1. Start building a rpm
2. While the build part is taking place, which can take a while, edit the spec

Actual results:
The spec included in the srpm is not the one that was used to start the build but the edited version.

Expected results:
Ideally, the spec included in the srpm should be the one that started the build, not the one at the end of the build. At least a warning should be issued when the two differ.
Comment 1 Jeff Johnson 2008-08-03 16:58:02 EDT
Sure. recursion at N+1 is different than recursion at N in general. IOTW, the
recipe used to produce a SRPM at stage N is not (in general) the same as
the included spec file at N+1.

Furthermore, even if the spec files were identical, recursion (as in rebuilding)
is not guaranteed because of the large amount of additional configure information.
Checking digest (or other content verifier) on spec files will never guarantee that the
N -> N+1 build succeeds.

But yes, I understand your expectations.
Comment 2 Vasile Gaburici 2008-08-03 18:27:49 EDT
(In reply to comment #1)
> Sure. recursion at N+1 is different than recursion at N in general. IOTW, the
> recipe used to produce a SRPM at stage N is not (in general) the same as
> the included spec file at N+1.
> 
> Furthermore, even if the spec files were identical, recursion (as in
> rebuilding)
> is not guaranteed because of the large amount of additional configure
> information.
> Checking digest (or other content verifier) on spec files will never guarantee
> that the
> N -> N+1 build succeeds.
> 
> But yes, I understand your expectations.

I'm afraid you misunderstood them a bit. I'm not expecting a guaranteed rebuild. What I'm arguing for is (a bit more) atomicity of the build process w.r.t. to the files that get included in the srpm: {sources, patches, spec}.

On a snapshotting file system you could easily fetch exactly the {sources, patches, spec} file versions that started the build and include those in srpm if/after the build succeeds. Since you don't normally have the luxury of snapshotting file system, the fallback (that doesn't involve changes to build process) is to print some stern warning if the {sources, patches, spec} differ at the end. An alternative that does alter the build process would be (for -ba) to create the srpm before initiating the build process, then to unpack it in some temp dir, and build the binaries from what was in the srpm. YMMV.
Comment 3 Vasile Gaburici 2008-08-03 18:36:20 EDT
(In reply to comment #2)

Forgot to add that checking anything but the spec at the end is overkill since the other stuff not likely to get changed, which is why I didn't mention it in the initial report. Checking the spec at the end is similar to a rpmlint check; it won't guarantee that stuff won't break, but will flag some accidental edit while the build is in progress. Besides, computing a hash on the spec file hardly takes any time...
Comment 4 Jeff Johnson 2008-08-03 19:17:38 EDT
Sure hashes are easy to generate.

The issue is when/how the "reference" and the "produced" spec file
digest gets compared.

You could already build from a *.src.rpm (which verifies the digest),
and look at the produced *.src.rpm (which would verify the included
spec file).

Note that a snapshot file system is not an available solution to rpm.

Note also that its not just spec files that can change. If preload runs
against just built libraries, then the libraries will be changed from
what was built, and can/will cause binary rpm packaging issues.

There's certainly no reason not to attempt to solve all these problems,
but I'm not sure that rpm is the place to do it, and the incidence is
small enough that "Don't modify the spec file while building the package."
is perhaps gud enough (once you understand the issue).
Comment 5 Bug Zapper 2009-06-09 22:21:45 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 WONTFIX if it remains open with a Fedora 
'version' of '9'.

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 prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Bug Zapper 2009-07-14 10:34:17 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.

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.