From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: Running up2date to download a large package over a slow (56k) link gets the following error in a dialog box ... "The package kdelibs-3.0.3-8.3 does not have a valid GPG signature. It has been tampered with or corrupted. Continue?" The error occurs during download after a portion of the package has been received. No other errors are apparent unless one starts up2date from a shell window .. # up2date error: rpmts_HdrFromFdno: MD5 digest: BAD Expected(f65fe4c6774d31896625bf3a5d4037b1) != (a79cc8f7fff7ca61d41cb2076279e81e) SSL exception (104, 'Connection reset by peer') SSL exception (-1, 'Unexpected EOF') error: rpmts_HdrFromFdno: V3 DSA signature: BAD, key ID db42a60e # Note that the first "rpmts_HdrFromFdno" error is printed immediately (before the download has started) while the other errors happen right before the "package xxx does not have a valid GPG signature" dialog box pops up. Version-Release number of selected component (if applicable): up2date-3.0.7-1 How reproducible: Sometimes Steps to Reproduce: 1.Run up2date from a shell window to download a large package over a slow (56k) link 2.The download fails with "package xxx does not have a valid GPG signature" 3.Note "Connection reset by peer" error in shell window. Actual Results: An incorrect error ("package xxx does not have a valid GPG signature") was reported and the package download was aborted. Expected Results: The correct error ("Connection reset by peer") is reported. The connection is reestablished and the download is resumed where it left off. Additional info: This bug causes confusion because unless up2date is started from the shell the real cause of the error is lost.
A couple of examples: The package iptables-1.2.9-1.0 does not have a valid GPG signature. It has been tampered with or corrupted. Continue? The package mc-4.6.0-8.4 does not have a valid GPG signature. It has been tampered with or corrupted. Continue? Option Yes is needed; otherwise the up2date procedure is completely cancelled
networking issues that cause package corruption should be better detected in current versions. Either way, up2date is doing the correct thing by warning.
The warning message is wrong. The package has NOT been tampered with or corrupted; rather, it has been truncated due to the server dropping the connection (the download can be finished successfully using wget). The correct behavior would be for up2date to check whether the file size is correct first, and if it's too short, it should say that the downloaded file is truncated and to use some other tool capable of resuming downloads to finish it. In any case, the problem still exists with FC2. Using mirrors (which is the only improvement since 8.0) is NOT a fix, it simply makes the bug less likely to manifest. (I still experience it now and then.) When up2date can resume an aborted download (or at least if it gives a correct warning message), then it'll be fixed. Please reopen this bug (and any related bug reports closed for the same reason, for example bug #85808 which was reported as closed in email, though the web page itself isn't updated yet).