Comment 58 for bug 24061

Ok, I had this [or at least something oh so similar].

first I tried the
    sudo aptitude -o Acquire::http::No-Cache=True -o Acquire::BrokenProxy=true update

    sudo apt-get update

work around, with no success.
then:
cd /var/lib/apt
sudo mv lists lists.old
sudo mkdir -p lists/partial
sudo apt-get update

which worked.
So then I thought, seeing as no-one seems to have a clue what's going on and the bug has been in apt-get or a dependency for a log time I'd spend a few minutes to find out what the problem really is.
(one of the files that failed for me was a release repository file so it's static SFAIK)
ls list
'file that failed'
ls lists/partial
'file that failed'
'file that failed'.gpg
delta lists/'file that failed' lists/partial/'file that failed'

deta says.
Bits before MD5Sum: in lists/partial file contain the HTML of my landing page.
Bits before MD5Sum: in lists contain HTTP like header (line separated key colon space value pares)

So this identifies a couple of potential problems on it's own, if not more.
1: even though the file fails the .gpg checksum or whatever it is test, no mention of any way to examine and then 'force' apt to fix the problem e.g. junk the file is apparently offered or given.
2: Two separate HTTP requests to two (or more) separate locations are made to build a composite file up, but validation is somewhat lacking (on either the date returned[thought that's what I think the .gpg is for?], or that the file serving up the files actually matches that which has been requested.

file in partial and in lists had same date.
So I assume the date of the landing page was compared against the date of the file in lists, but the date in one of the parts of the body or somewhere was used for the file date.
so
1: dates of the multiple parts of the file should match, and this is not being tested for.
2: (should be fixed by the above/possibly) the date that used to check to see if an update is needed comes from a different request than the date of the actual file itself.

it doesn't matter if the .gpg file is in partial or not, effect is still the same.
touch -m on the file in partial, with a date before the file date, causes a new file to be fetched.

So there seem to be quite a number of bugs in just the way this fault presented itself on my computer 'Ubuntu 10.04'

url/ip address validation and that kind of thing should possibly be looked at, or at-least allow the user to lock them. I have no idea why the file is in multiple parts, that should have the same date and I imagine be on the exact same server, but not validation is performed to that regard.

should files in partial be validated when update (or whatever) is called and the user asked if they want to junk old crappy ones before continuing?

I think the error should really give a bit more info, other errors tell you what to do, or work around (sometimes they don't actually fix the issue, but it's a start!)

anyhow, I'm going to pull some source down, and hope I don't have to shut my eye's too often whilst fixing this one.(soon hopefully)

Ok, that all took me about 50mins to find out after having a poke around.
I expect there are other bugs, so I'll do a good audit whilst I'm at this one.
5+ years is a long time with something like this still kicking around.in the package management system potentially blocking security updates and such (it did with me!)