Hide Forgot
Created attachment 492658 [details] screenshot showing installer offering to upgrade from "Fedora 1" Description of problem: The installer accepts the contents of /etc/fedora-release without verifying it against the RPM database. This results in the installer offering to upgrade "Fedora 1" (attached screenshot). Version-Release number of selected component (if applicable): F15-Beta-Final How reproducible: Always. Steps to Reproduce: 1. Complete a clean, full-disk, minimal install from the DVD: $ qemu-kvm -m 1024 -cdrom Fedora-15-Beta-i386-DVD.iso -hda ../f15-test1.img -boot menu=on 2. Boot into the installed system and log in as root. 3. # vi /etc/fedora-release 4. Change the release to "Fedora 1". 5. Reboot from the DVD. Actual results: Installer offers to upgrade "Fedora 1". Expected results: Installer notices there's something going on: # rpm -V fedora-release Additional info: Bug 697047 - "Cannot Upgrade" message reinstalling onto VM disk image after cancelled install Bug 697193 - "Cannot Upgrade" message vague about "current installation"
Created attachment 492661 [details] this is what happens when you do not do your md5sums ... :-)
We have to trust something. Trusting the file on disk to be correct doesn't seem unreasonable. If you are hitting this problem via some normal activity, please include the details.
(In reply to comment #2) > We have to trust something. Trusting the file on disk to be correct doesn't > seem unreasonable. If you are hitting this problem via some normal activity, > please include the details. Applications that "trust" their input expose users to hackers. Buffer Overflow Attacks and Their Countermeasures http://www.linuxjournal.com/article/6701 SQL Injection http://msdn.microsoft.com/en-us/library/ms161953.aspx
(In reply to comment #3) > (In reply to comment #2) > > We have to trust something. Trusting the file on disk to be correct doesn't > > seem unreasonable. If you are hitting this problem via some normal activity, > > please include the details. > > Applications that "trust" their input expose users to hackers. > > Buffer Overflow Attacks and Their Countermeasures > http://www.linuxjournal.com/article/6701 > > SQL Injection > http://msdn.microsoft.com/en-us/library/ms161953.aspx Indeed, the installer should be checking digital signatures before trusting anything on a device of unknown provenance. RPM packages have digital signatures ...
(In reply to comment #2) > We have to trust something. Trusting the file on disk to be correct doesn't > seem unreasonable. If you are hitting this problem via some normal activity, > please include the details. "normal activity": Sysadmins sometimes make mistakes, e.g. by copying a file to the wrong place ... And sysadmins might neglect to run "rpm -Va '*'" periodically.