Jos Vos wrote:
What I tried to point out on the Nahant list was that generating
binary rpms with -bb and source rpms with -bs -- all in separate
steps -- was not the way RPM was intended to be used, even when
the same source/spec files were used. IMHO one of the ideas of
proper RPM packaging is that a binary rpm has a more formal relation
to a source rpm than "someone says they used the same sources at
build time".
I was just about to send you email that I asked about this on RPM
mailing list (haven't intended doing things behind your back, scouts
honor ;-)
Anyhow, what I wanted to point out was that cookies as such seem to be
ignored by many RPM builders. Including some big and well known ones.
I gave an example from Fedora Core repository, and I wouldn't be
surprised if RHEL is the same (after all, they are using same building
system). Another example is Dag's repository (apt.sw.be). I've checked
couple of binary RPMs there, none has cookie.
Cookie itslef isn't very reliable way to tell that this binary RPM was
built from that source RPM. It is more than possible for two totaly
different source RPMs to get same cookie (for example two developers are
building packages in parallel on same host, and timestamps happen to be
the same). Also, cookie is trivial to forge. If binary RPM is not PGP
signed, anybody can change it (there's no readilly available tool to do
it, however I don't see why it wouldn't be possible to write it). If it
was PGP signed, you are still trusting the packager that he was not
mocking around with cookies when building the packages. Even a more
sophisticated methods, such as cryptographic checksum of input files
(source, patches, spec file itself) would not really work (if some
packager really wants to cheat he can just as easily substitute for
example "make" or any other command invoked by the scripts in spec file
to modify the build tree prior to compilation). Even with cookies it is
still "someone says they used the same sources at build time". If you
don't trust provider of binary RPM, you rebuild it from source. You
should completely ignore the cookie thing. Simple as that.
For example download all three files from
http://www.milivojevic.org/fake/. Note that cookie in both binary RPM
packages is the same as in source RPM. I've changed the filename on one
of binary packages after the build (obviously I can't have two files
with same name in single directory).
The fake-1.0-1.el4.i386.rpm was really built from provided SRPM. This
was the command line:
$ rpmbuild --rebuild fake-1.0-1.src.rpm
The fake-1.0-1.el4-fake.i386.rpm was also built from provided SRPM.
With a twist:
$ PATH=/tmp:$PATH rpmbuild --rebuild fake-1.0-1.src.rpm
There was a shell script called gcc in /tmp, that modified the source
and then invoked the real gcc. Both binary RPMs contain single
executable (/usr/bin/hello). The real one prints "Hello World!". The
fake one prints "Got You!". Took me about 5 minutes to create this test
case. If sombody is out there to get you, it will take him about the
same amount of time. If you don't trust me (and you shouldn't ;-) ),
you can simply extract the files and run strings command on the
executable. I haven't placed any exploit for strings command inthere,
scouts honor ;-)
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
