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!)
--
GPG error with apt-get/aptitude/update-manager behind proxy (BADSIG
40976EAF437D05B5)
https://bugs.launchpad.net/bugs/24061
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
